>Ooops: > >------------------------- > 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 >requirement. 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 >to. 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 clicks. >'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 'loci-file/infofiles/unixutils/ls.xml'). 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! >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... Thanks much for everyone's comments, etc! Brad