[Pipet Devel] Attempt at Constructing the Command Line

J.W. Bizzaro bizzaro at geoserve.net
Mon Jan 17 21:42:40 EST 2000

Okay, I got it working.  Brad, YOU THE MAN!  Very nice!

Brad Chapman wrote:
> 3. Right click and add a "composite" widget to the workspace

I was wondering why the composite locus was needed, but then I realized that
you were planning on executing the composite as a whole.

Of course, scripts/WFD's should be executable without first being composited. 
Is that what the 'execute script' option is for?

Scripts/WFD's should be compositable at any point: The first step need not be
to make a composite.

But I know this is just the beginning and it was only a test :-)

> to it. This is kind of tricky--you have to look at the composite locus and
> be sure it is currently selected (has a blue box around it). Otherwise you
> can accidentally add the processor to the main workspace. If this happens,
> no big deal, just keep trying until you add a processor to the "inner"
> workspace.

I need to fix this: Clicking in a windowlet should select the locus it belongs

> 6. Double click on the processor locus. This will open up a chooser type

'Processor', 'converter', 'viewer', etc. are only locus _class_ names.  I was
thinking that one processor would be the 'ls' command, another kind would be
'grep', and so on.

Also, many of these can be saved _preset_ and then be pulled out of a
container for use.  So, you would get a list from a container of loci like so:

           |       |
           |       |
         [  /usr/bin ]
    |  ls                 |
    |  grep               |

In each case, the class would be 'processor', so the symbol and default icon
that appears for the command would be for a processor.  But the name that
appears below the symbol would be the command name: 'ls', 'grep', etc.

Of course, there should be a way to make new processors (or wrap programs to
run under Loci), which is what you've demonstrated.  But can
unwrapped/non-Loci programs be wrapped automatically?  How about using the
container locus to select unwrapped programs:

           |       |
           |       |
         [  /usr/bin ]
    |  rpm                |
    |  ps                 |

which would eliminate the need for the selection tree widget you have under
'processor': The container would do the selection for you.  A user could DnD a
program onto the workspace, and Loci would automagically try to make a wrapper
for it.  But what does Loci need to know to make a wrapper?  What did you have
to do to make one for 'ls'?

> widget allowing you to pick a program. The programs are grouped within a
> tree, with the programs inside "modules" that describe the program. In this
> case you will see a "unixutils" folder. Click on the plus to open it up and
> you'll see the programs.

Again, this works just like a container (tree widget and all), so wrapped and
unwrapped processors should be selectable via container.

> 7. Clicking on the programs shows a little description at the bottom of the
> window. So far, only ls really works, so select it and press choose.

I like this: It's like a statusbar with more room!  Brad, should this be coded
into the windowlet or the widget?

> 8. A new locus will pop up somewhere random within the "inner" workspace.
> This loci is a chooser for selecting flags to go along with ls. To check it
> out, double click on the "processor" locus to close its window, and center
> the "converter"/flag selector locus.

Well, the locus class 'converter' was meant for data format conversion, but I
get the point.  Should there be an 'option' class of loci?

So, there should be container listings for wrapped and unwrapped processors,
plus 'options', and so on.

> 9. The flag selector locus has a pull down box with the flags available for
> the ls program. In this case, I only have a few flags set up, although it

I was thinking that we would have one 'option locus' per flag.  You have it so
that you could set multiple flags, which may be more convenient but sort of
bypasses the simple building block plan I had.  I was thinking that _multiple_
flags (and other options) meant connecting _multiple_ option loci togther.

> Anyways, you
> can select through the flags and click on Add to add them. If you
> accidentally add one you don't want, click on it in the list below and
> press the remove button.

You see, 'add' and 'remove' are exactly what the _Workspace_ lets you do.  So,
why not use the Workspace?  We want to be sure we're reinventing the wheel:
Make _everything_ work "The Loci Way" (take elemental loci, set parameters,
and then plug them together to make composite loci).  We can add and remove
flags if they are separate loci on the Workspace.

> 12. Connect everything up: Arrow/out from processor to input of converter,

I wasn't sure which out arrow to use from the processor.  If we have multiple
arrows with different mime types, it should matter.  I need to work on this:
make connector windowlets and all.

> 13. Right click on the composite locus holding this whole mess to pull up a
> little menu. Select "Construct Command Line." Yay! You just ran the ls
> program!

Or maybe 'Run Command Line' :-)  'Construction' was already done by the user

> 14. The viewer will pop up a text box displaying the results your list
> command. Very beautiful.

The viewer is very nice indeed, exactly what I was thinking of.

> Well, if you managed to get through all of that, I hope that it managed to
> work out! I would really like to hear everyone's thoughts on it! I will
> work to add some more programs and make it possible to generate more
> complex command lines (with pipes and everything!), and also to make things
> a little prettier (ie. not so many random windows popping up all over the
> place!). As I said, suggestions are very welcome!

You asked for suggestions, well you got them :-)

One other thing: About random windows popping up: It should be up to the user
to select what goes next.  I know ls has certain options, and it is obvious to
you that the user needs to select one.  But I think we should allow more
flexibility for the user, and give ourselves less work.

The ls processor does not need to know there are options to be set: It only
handles outputting the string 'ls' to the command line.

And the flag option locus does not need to know what flags are legal for ls. 
All flags should be choosable since this flag option locus is a _generic_
locus (it can be used with commands other than ls).  Maybe to narrow the list
of flags down, we could have a filter attached that can catch illegal flags.


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

More information about the Pipet-Devel mailing list