[Pipet Devel] excerpt from CHANGES

[Brad Chapman]

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