[Pipet Devel] Re: window sill

J.W. Bizzaro bizzaro at geoserve.net
Fri Apr 7 20:36:58 EDT 2000

Brad Chapman wrote:
> > No, I was suggesting to you that the 'view we have now' (the
> > workspace normal view) replace the GtkCTree view for taking
> > listings of directories.  The composite GUI will look like a
> > regular Gtk interface.
>     Okay...how can you then distinguish between moving a locus from
> one workspace to another via dnd, and copying a locus unto a new
> workspace via dnd (ie. if you are copying a saved locus onto to the
> workspace to use, or if you are dragging a directory out of a
> representation of a local filesystem)?

Just as you would do any DnD between objects.  The workspaces are all
Gtk/Gnome objects.

> Will the workspace need to keep
> track of what kind of information it is holding?

The middleware (the 3 layers) will need to keep track of what node is where. 
The front will do it in a more ephemeral way (using temporary GUI objects).

> Similary, a
> composite representing a save directory or local filesystem will need
> to react different to loci that are dragged into them then a "regular"
> workspace would.

Why?  How will they act differently?

> I guess we would probably need to define two
> different workspace types in the code.

Maybe, if there really is a difference between a 'storage node' and a 'working
node'.  I say there is no difference.  And, since we're making our own
distributed pseudo-filesystem, it won't be such a stretch of the imagination
as it would be with a Unix filesystem: We can MAKE IT so that there is no

>     Also, how will a workspace be populated with gui representations
> of loci if you, for instance, open up a save container full of loci?
> Just stick them with equal spacing throughout the workspace, like
> opening a directory on a mac?

Yep.  I'd hide the links/connectors by default, so it would look EXACTLY like
a Mac folder in 'large icon' view.

Hiding links would serve another purpose I recently realized.  Recall how
non-connected links mean the I/O is from/to the parent node, and if you want a
true dataflow 'dead-end', you'd need to cap it off somehow.  I would make
hidden links mean dataflow dead-ends.

Going back to the workspace as a 'storage node', it would be important to hide
the links of stored nodes.  One may store dozens or hundreds of nodes in such
a place, and we wouldn't want all of those non-connected links to end up on
the parent node ;-)

                      |           J.W. Bizzaro           |
                      |                                  |
                      | http://bioinformatics.org/~jeff/ |
                      |                                  |
                      |        BIOINFORMATICS.ORG        |
                      |           The Open Lab           |
                      |                                  |
                      |    http://bioinformatics.org/    |

More information about the Pipet-Devel mailing list