[Pipet Devel] composited GUI's revisted, part 1

J.W. Bizzaro bizzaro at geoserve.net
Wed Jan 19 00:29:57 EST 2000


(continuation)

Brad Chapman wrote:
> 
> 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

But why 2 loci?  Composition should give you _one_ locus: the composite locus,
which can switch its GUI between a workspace view and a composited Gtk+ GUI
view.  In the example you made, a composited Gtk+ GUI should appear in the
composite's windowlet.  Switching (via pull-down menu?) views shows the
workspace.

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

Okay, but there are 2 features you're not considering here:

  (1) LOCUSES/LOCI CAN BE COMPOSITED, LEAVING _ONE_ LOCUS THAT REPRESENTS MANY
LOCI.

  (2) A COMPOSITE LOCUS CAN BE STORED AS A COMPOSITE LOCUS, MEANING THE USER
WILL
      NEVER HAVE TO DEAL WITH THE LOCI THAT MAKE UP THE COMPOSITE LOCUS.

So, yes...

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

would be 7 loci, but once they are composited and stored, this line will
ALWAYS be _one_ locus.

And (recall 'constructing the command-line), if you leave one option unset...

  'pythondoc -i <flag> XML -d ./doc ./mypythonfile.py'

You have _one_ composite (made up of 6 set loci and 1 unset locus) with _one_
option to set: <flag>.

ONLY THE USER WHO MADE THE COMPOSITE HAD TO WORRY ABOUT HOW MANY LOCI IT WOULD
TAKE.  FROM THEN ON, IT IS _ONE_ LOCUS.

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

Yes, IF YOU COULD NOT STORE COMPOSITES, you would have to rebuild ls -l each
time, which would be more work than it is worth.  BUT WE CAN STORE
COMPOSITES!!! :-D  SO, THEN ls -l IS ONE BUTTON CLICK!!! :-D

> 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 really like the idea of info boxes.  Loci may be incredibly flexible and
powerful, but we want it to be intuitive and simple to learn.  There should be
a very simple motif to all of this: Take small components, connect the dots,
and make bigger components (sort of like UNIX).

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

I'm very impressed by how you could get that information from a man page. 
"The Loci Way" still does not prevent us from using this innovation.

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

I think if we have a 'flag locus' that has one flag per locus, the
user/developer can set the flag names and the number of flags to choose from. 
Sure, you might end up with 10-20 loci, BUT THEY CAN BE COMPOSITED AND
STORED!!!  FUTURE USERS WILL ONLY SEE _ONE_ SIMPLE INTERFACE!!! :-D

> >REMEMBER THE LOCI WAY:
> >
> >  (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...

Ahh, Young Grasshopper, you will soon know the ways of The Loci.  You must
keep in mind the 2 points I mentioned before:

  (1) LOCUSES/LOCI CAN BE COMPOSITED, LEAVING _ONE_ LOCUS THAT REPRESENTS MANY
LOCI.

  (2) A COMPOSITE LOCUS CAN BE STORED AS A COMPOSITE LOCUS, MEANING THE USER
WILL
      NEVER HAVE TO DEAL WITH THE LOCI THAT MAKE UP THE COMPOSITE LOCUS.

(Part 2: How to make a composited GUI)

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