[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