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/ | +----------------------------------+