[Pipet Devel] Attempt at Constructing the Command Line

Brad Chapman chapmanb at arches.uga.edu
Tue Jan 18 07:23:05 EST 2000

>  File "./program/programFactory.py", line 10, in ?
>    from os.path import *
>ImportError: No module named path
>Okay, why don't I just upgrade to Python 1.5.2, and we'll list that as a

Egads! I can't believe I used so many 1.5.2 specific commands. This is
really weird, though, because according to the lib docs os.path has
supposedly been around for a while, and shouldn't be 1.5.2 specific. I
don't understand this error at all! But I guess it got fixed by upgrading
to 1.5.2...
	Maybe we should think about "tester" machines for Loci, especially
in light of what David was mentioning about differences between how things
run on Linux vs. IRIX. It would be nice to have at least "simple to fix"
bugs ironed out before random people start downloading Loci and getting
cheesed about a million bugs, especially since we have so many testers
available on the mailing list!
	I think once we get the new loci module set up it will make it
easier for people to stay updated and test new features on their machines.
But I think the quicker we can catch problems, the easier the will be to
fix. This is especially true for inexperienced programmers like me, since I
don't really know what kind of errors to expect and avoid.

>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 :-)

Righto! I really don't think it should be necessary to have to do
everything inside a separate composite, especially since you might want to
execute/construct the command line for the main workspace! I think,
ideally, that there should be an option inside the pop-up menu bar
(labelled something like "Action") and then sub-menus within this labelled
"Execute" and "Construct" or whatever. What do you think about this?

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

Well, what I was thinking is to have two options. A "Construction" type
option and an "execute" type option. Actually, what I had working in
loci-file was more of the "execute" option (oops! I guess I used the wrong
selection!). Basically, my idea was this:

1. Construction: This will take the workspace and clean it up by condensing
all of the loci on a command line (ie. the program ls loci and the flag
option loci in this case) into a single loci showing the command to be
executed. I couldn't do this yet because I don't have enough access to loci
and their windows to change GUIs and delete loci. So in the little "ls"
example, after construction you would be left with two loci, one labelled
"ls" showing the entire command line selected, and the viewer loci

2. Execute: This will be the actual execution of the workspace. This is
more of what I was demonstrating in the example--actually running the
program and seeing the output in the viewer locus.

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

Yeah, I don't really understand why the widgets don't hold the focus very
well. Even with a container locus, if you click a bit with the right mouse
button you can get the pop-up menu to show up, resulting in a loss of focus
on the container widget. I was trying to think of a solution for this.
Maybe if when a windowlet is open, all clicks within the region of the
windowlet are ignored by the main window holding the windowlet. This might
get rid of the competition between the main window and the windowlet for

>'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.
>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.

Right! Again, renaming seemed like something that was pretty difficult to
do under the current Locus/Workspace class structure. My ultimate vision
for how things would work is this:

When a user chooses a program from the processor list of choices, say ls,
the processor loci will "morph" into an 'ls' loci. My idea for how this
would look is that it will be labelled 'ls' under the name, and the
GUI/widget for the locus will consist of a description of the program and
how it is used, along with buttons to press to set flags, etc. So then if
the user would like to set ls flags, the would hit a "set flags" button or
something and the new loci would pop up for them with all of the possible
flags for ls (much as it pops up automagically in the little test thing).

That is the first thing I'll work on to improve.

>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:
[...snip of pretty picture...]

This is a really good idea! It would be quite nice to save either
frequently used programs, or frequently used "command lines" in a container
locus that you could call up. This could kind of be like a history you
could set yourself. I like it very much!

>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:>
>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'?

That would be *very* nice, but I think it will take a lot of thinking to
get this working. Okay, here is what I did to get ls working:

1. I grabbed the man page for ls and XMLified part of it for the example
(You can take a look at the ls.xml file in

2. I added to the xml file some things, like a request for a "flag_select"
widget, to display the possible flags for ls.

That's it. This should work for any program which runs from the command
line *and* all the info you want to get back from it is what it would
normally spit out to standard out. So, to wrap things automatically we
would need:

1. A way to get the man page for a particular command (we could probably
just "man command" to get this).
2. Find/write a program which will convert man pages to xml.
3. Write a program to add the correct "loci specific" markup to the xml page.

Of course, this won't work if you want to do something more complicated.
For instance, lets say you were on a mission to get rid of all .rpm'ed
files in the whole world. Then you might want a workpath that un-rpm's
files and then sends the directories to tar/gzip to zip up. This wouldn't
be easy to do with the simple wrapping that I used for ls.

>> 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?

I think it should stick with the widget because not all widgets will want
an "info" bar (like a viewer for instance). Then if widgets don't need
them, they will have to go through the extra step of removing the "info"
bar from the windowlet.

>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.
>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.

Okay, these were two things I started off doing, but then changed my mind
during coding. Let me give my thoughts:

1. On the one loci per flag idea. I started off with just this, but think
about how messy the workspace would get if you wanted to run a command like:

'pythondoc -i -f XML -d ./doc ./mypythonfile.py'

This would require 3 loci for option flags plus the one for the program,
plus the one of the file to choose. Now, right now I have my computer set
up with an old Matrox 100 series graphics card and a crappy Compaq monitor
I got for free from my friend who was throwing it away. With my screen
resolution, 5 loci would barely fit in the screen, much less leave room for
selecting options/connecting them to other loci.
	In addition, I was thinking that getting a command out should be as
fast as possible so that it is a viable alternative to actually just typing
things in on the command line. I think that the multiple flags in one locus
makes it much quicker then opening up multiple loci.

2. For the "program specific" flags versus "generic/all flags" issue. My
thought here was that Loci is supposed to be a way to hide the UNIX command
line from the user, or at the very least make the command line easier to
use. If you already know what all of the flags for ls are, and what they
do, why not just type in your ls -l command on the command line. However, I
thought that the info boxes, and the choices of possible flags, makes it a
bit easier to learn what flags do what, and to avoid making mistakes.
	I think this is also a way to make the information that is already
available for a program (ie, the man pages) more easily read and explored,
even for experienced programmers/UNIX users. How many times have you read
questions on newsgroups where the reply is "look at the man page?" I doubt
if very many people have all of the millions of options for all of the UNIX
programs memorized.
	In addition, I think it is pretty impossible to generate a list of
all possible flags for all programs. For instance, omniORB had command line
options like the following: '-BOAiiop name port' Should a user have to look
through all kinds of crazy options like this just to find their -l option
for a list.

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

That's a great name! (I hadn't been able to come up with one--I must have
some kind of mental issue or something!). I know 'converter' was
inappropriate, but I couldn't really pick a good option.

>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.

Okay, two really stupid questions:

1. How does a mime type relate to the arrows? (I said the questions were
really stupid!)
2. Why should the different connections matter, especially for constructing
a UNIX command line? I thought we were just Rube Goldberging it and
stepping through the workpath, running programs and passing the data on to
the next program (if applicable). Does it really matter then which arrow
the data goes down?

(Cleary, I need some hand holding in explaining your ideas here!)

>You're right, that is more OO than my code, which was kind of hack to begin
>with.  It certainly would be the next step in windowlet development to make
>those the changes.  Be my guest :-)

Thanks much. That will be a big help and will likely get things running a
lot prettier. I certainly wouldn't call the current code a hack though,
I've been very impressed with how thought out the code is, especially in
regards to the windowlets/internal widgets. This is in contrast to my
coding, when I often have difficulty forseeing the very next class!

>  (1) Break a new feature up into the smallest possible elements.
>  (2) Any new elements that need to be made are added to the library.
>  (3) Connect the elements using the appropriate heirarchy.
>  (4) Set any parameters that you need or want to.
>  (5) Transform the connected elements into a composite.

Okay, I haven't been sleeping much, but this whole thing just blew my mind.
It will take a bit of time for this "student of the Loci" to digest this
new teaching...
	Thanks much for everyone's comments, etc!


More information about the Pipet-Devel mailing list