Thanks for writing, Jeff and Gary--I got lots o' questions/comments on this: Jeff wrote: >> >> > (1) Select processor ---> (1) Select container >> >> Lots o' questions on this: >> >> So a container holds 1. filesystems 2. databases and 3. all of the >> programs? > > Okay, ignoring databases for a while, think of a container as representing > any > one directory/folder in the filesystem. It's that simple. > > Then, 1 and 3 are the same, IF a container represents the directory / > > IF a container is set to represent /usr/bin, then it holds the programs in > /usr/bin and nothing else. I don't know about you, but if I look at my /usr/local/bin directory there are hundreds of programs there, all ordered in a non-useful alphabetical fashion. Jumbled in with the useful programs are a whole crapload of randomprogram-config programs which I never need to run, etc. I personally do not want to look through a list of all these programs just to run a program. Jeff wrote: >> Do you like the way things are divided up in modules now? Is this how >> you want things, or should there just be a big list of all the >> programs? > > Well, if containers are directories, then the user can sort loci however they > want. They just DnD a locus into a different container. EXACTLY like files > and folders in a Mac hard drive. I agree with this for files, but I don't see how this would work for programs, if we arejust finding them all in the /usr/bin directory. I would not expect users to add sub-directories to their /usr/bin, sort the programs by hand, and then adjust their PATH to move into all these directories. Or, would moving a program loci to a different container only create a link to that program in the filesystem, and it would look to loci like the program is actually in the new folder? Jeff wrote: > Now I see where you're getting confused. You're considering locus types > (processor, document, etc.) to be 'containers' of a sort, containing programs > of that type. But only loci of type 'container' are containers. The program > 'ls', for example, is a 'processor' type locus, but it doesn't _contain_ > anything. It _represents_ ls, and that's all. Okay, gotcha, only containers contain other loci! But then, why would you ever want to add a processor directly to the workspace, as opposed to dragging it out of a container? Should the default gui for a processor by a selection widget to choose the program it represents? Jeff wrote: > Okay, just think of it as pulling files and folders out of a Mac hard drive, > onto the Mac desktop. It's _exactly_ the same. EXACTLY. Yay, Mac! Jeff wrote: > So, now you're probably asking, 'What about the wrappers for seqManip? Where > do they go?' Well, my thoughts are that Loci will (1) identify the location > of the file, and (2) then check the 'wrappers' directory > (back.private.wrappers?) for a wrapper. (3) If no wrapper is found, then (4) > Loci uses a default wrapper based on file type (executables are processors, > etc.) or (5) tries to make its own (as you were doing with man file parsing > in middle.library.modules.wrap). Okay, so for 4, what would a default wrapper look like? Would it have flag options? Would it specify input and output files? I really think that the chances of being able to develop a "standard" wrapper that will work for many programs is very slim. For 5, please notice that I'm not automatically parsing man files, I made the one for ls by hand. I just don't want you to expect too much. Also, man files seem to be getting outdated, as more and more info on programs move to the web--it seems like this strategy will miss a lot of programs. What I am proposing is not to try and have a "catch all" mechanism to try and get every program, but instead to require an xml file for every program you want to run. If we are using Loci as an analogy to a web browser, I think of this xml files as analagous to an html page for the info you want to display. I don't really think that a gui interface to a program will work well at all without some information about a program. Otherwise, the gui interface is just as unintuitive as using the command line, and then, why use the gui interface? This is the way things work for appLab with their meta-data files. However, I think a big problem with AppLab is that there is no way to get one of these meta-data files for programs that have already been wrapped. To remedy this situtation, I think it would be relatively easy to have a repository of xml files written for programs available along with Loci, and some script that automatically installs them for the user. Then the user can download all of the xml files they want and automatically install them. Am I making any sense? Jeff wrote: >> > (4) Command is inside ---> (4) Command is on workspace >> > of composite >> >> So how do you envision the "constructing the command line" happening? >> Will this occur on the main workspace, or inside a separate workspace, >> like I've been doing? > > On the main workspace, simply by DnD-ing the needed loci onto the workspace, > and then connecting the dots/lines. Right, so instead of buttons, you would want the "control-panel" to have loci that can be drug onto the workspace? Or do you dislike the control panel idea? Also, I really think that when a new loci is added the lines should be automatically connected (the way it works in the current loci that I'm messing with). Most of the time the user will want them connected anyways, and it is a serious pain to connect them by hand because all of the lines are hidden under the gui. So you have to close the gui for both loci, connect the lines, and then re-open the gui. I'm really for automatic connecting. Jeff wrote: > First, a command-line would be represented on the workspace as a workflow > diagram (WFD). This means, of course, multiple loci connected via lines. > Now, this can be executed as it is (by running the main executable/processor > perhaps). This is just like what you have done _inside_ of a composite locus > windowlet, only it's on the _workspace_. Gary wrote: >1) Creating a new gui from a composited WFD. >Say you are constructing a command line with a switch that requires a >filename, regex, or some other field. How would you construct the WFD >such that the switch and the text-field become associated during the WFD >composition? Right on Gary, this was my first followup question--you must have read my mind. I spent a lot of time trying to figure out a way to try and do this if we construct the command line on the main workspace, and couldn't think of one. For instance, lets take Gary's example and make it even harder by adding an output file: loci>x-povray -I def.ini my_povray_file.pov the_output_file.txt And say that you wanted the two input files to come in from the previous loci, and the output file to be transferred to the next loci. I can't figure out a way to do this if everything is on the main workspace. That is why I was working inside an internal windowlet. If you look at the newest loci, I started to work on this by having a button in a file selection widget that is a link. The idea I was thinking about here is that the inputs and outputs into the main locus that holds the "internal" command line would be available in a selection type window when the user clicked on the "add locus link" button. When a particular input or output was associated with a segment of the command line, this information would be available in the little windowlet that will eventually be in each dot. This idea is one of the reasons why I went to an internal windowlet to build a command line. Jeff wrote: > But making a composite locus (single locus out of a WFD) is _not_ the same as > constructing the WFD. Making a composite means, for the workspace, making a > single locus out of a WFD, and that's all. Of course this also means the > GUI's become merged. Somehow, we'll just have the workspace 'zap' a whole > WFD and leave a single locus in its place. But what about 'zapping' just the command line for one program, instead of for the whole WFD. Or what if you want to "undo" a zapped program to make changes? It seems like this would be very programmatically difficult to do if everything is on the main workspace. Gary wrote: >2) What would one expect to see from the compostite locus when the >command line had been constructed? ----------------------------------------- - POVRAY 3.0 - ----------------------------------------- - o Config File _def.ini________________- - o Input File _my_povray_file.pov_____- - - ----------------------------------------- - Helpful message here - ----------------------------------------- What I was thinking about was just about what you showed, with the addition of a button/option to undo the construction. Thanks for writing--I am at the point where I can probably start implementing a lot of this stuff, so I'd like to make things in line with what you are thinking. Brad