[Pipet Devel] excerpt from CHANGES

J.W. Bizzaro bizzaro at geoserve.net
Sun Jan 30 22:45:07 EST 2000


Brad Chapman wrote:
> 
> >  (1) Select processor        --->  (1) Select container
> 
> Lots o' questions on this:
> 
> So a container holds 1. filesystems 2. databases and 3. all of the
> programs?

Okay, ignoring databases for a while, think of a container as representing any
one directory/folder in the filesystem.  It's that simple.

Then, 1 and 3 are the same, IF a container represents the directory /

IF a container is set to represent /usr/bin, then it holds the programs in
/usr/bin and nothing else.

> When you create a new container, what kind of gui widget should
> appear?

Ignoring databases, the workspace should have 2 default containers:

    * one for loci/back/private/container/
    * and one for loci/back/public/container/

So, the GUI should be a directory listing.  Remember, container = directory
(ignoring databases).

Does a user then actually 'create a new container'?  Well, he/she can only
_open_ directories (equals containers) that already exist in the filesystem. 
Creating a brand new container would mean creating a new directory on the
filesystem, which is something we can do.

> So, if you don't select "processing" programs from a processor loci,
> and "converting" programs from a converter loci, when are these loci
> used?

Now I see where you're getting confused.  You're considering locus types
(processor, document, etc.) to be 'containers' of a sort, containing programs
of that type.  But only loci of type 'container' are containers.  The program
'ls', for example, is a 'processor' type locus, but it doesn't _contain_
anything.  It _represents_ ls, and that's all.

Loci types _identify_ _file_ types.

Any directory can then be interpreted as being a container locus full of other
loci.  For example:

    private/
        babel*
        blast*
        pol3.pdb
        rasmol*
        stuff/
            seqManip*
        yeast.genbank

Is seen by Loci as

    private/           (container)
        babel*             (processor)
        blast*             (processor)
        pol3.pdb           (document)
        rasmol*            (viewer^)
        stuff/             (container)
            seqManip*          (processor)
        yeast.genbank      (document)

    (^ note that identifying rasmol as a viewer requires a wrapper for rasmol)

So, how do I select seqManip?

    (1) Open 'private' container
    (2) DnD 'stuff' container onto workspace (if using non-tree view)
    (3) Open 'stuff' container
    (4) DnD 'seqManip' processor onto workspace

Again, processor is a locus _type_, just like a file type.  It is NOT a
container.

Okay, just think of it as pulling files and folders out of a Mac hard drive,
onto the Mac desktop.  It's _exactly_ the same.  EXACTLY.

So, now you're probably asking, 'What about the wrappers for seqManip?  Where
do they go?'  Well, my thoughts are that Loci will (1) identify the location
of the file, and (2) then check the 'wrappers' directory
(back.private.wrappers?) for a wrapper.  (3) If no wrapper is found, then (4)
Loci uses a default wrapper based on file type (executables are processors,
etc.) or (5) tries to make its own (as you were doing with man file parsing in
middle.library.modules.wrap).

> >  (2) Open processor and      --->  (2) Open container
> >      find command                      and find command
> 
> Do you like the way things are divided up in modules now? Is this how
> you want things, or should there just be a big list of all the
> programs?

Well, if containers are directories, then the user can sort loci however they
want.  They just DnD a locus into a different container.  EXACTLY like files
and folders in a Mac hard drive.

> >  (3) Choose command and      --->  (3) Choose command by dragging
> >      processor becomes                 it onto the workspace
> >      composite
> 
> Right, drag and drop. This will take a bit of learning, but I'll start
> thinking about this.

We're using classic 1984 Macintosh paradigms all over the place.  I want to
_start_ off that way anyhow.  We can get fancier with trees, etc. later on.

> >  (4) Command is inside       --->  (4) Command is on workspace
> >      of composite
> 
> So how do you envision the "constructing the command line" happening?
> Will this occur on the main workspace, or inside a separate workspace,
> like I've been doing?

On the main workspace, simply by DnD-ing the needed loci onto the workspace,
and then connecting the dots/lines.

> My thought was that you could construct the
> command line inside of the composite, and then click on the main locus
> holding the composite workspace, and choose an option like "construct
> command line." This would change the GUI of the locus to display the
> chosen command line only. Then this could be reversed if the user
> decides to change the current command line. How would constructing the
> command line work if everything was done on the main workspace?

First, a command-line would be represented on the workspace as a workflow
diagram (WFD).  This means, of course, multiple loci connected via lines. 
Now, this can be executed as it is (by running the main executable/processor
perhaps).  This is just like what you have done _inside_ of a composite locus
windowlet, only it's on the _workspace_.

But making a composite locus (single locus out of a WFD) is _not_ the same as
constructing the WFD.  Making a composite means, for the workspace, making a
single locus out of a WFD, and that's all.  Of course this also means the
GUI's become merged.  Somehow, we'll just have the workspace 'zap' a whole WFD
and leave a single locus in its place.

How does all this sound?  You know, I think it's a little less complex than
what you had in mind.

Cheers.
Jeff
-- 
                      +----------------------------------+
                      |           J.W. Bizzaro           |
                      |                                  |
                      | http://bioinformatics.org/~jeff/ |
                      |                                  |
                      |           THE OPEN LAB           |
                      |    Open Source Bioinformatics    |
                      |                                  |
                      |    http://bioinformatics.org/    |
                      +----------------------------------+




More information about the Pipet-Devel mailing list