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