[Pipet Devel] excerpt from CHANGES

J.W. Bizzaro bizzaro at geoserve.net
Mon Jan 31 12:13:25 EST 2000


(continuation)

> > 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?

*gasp* :-)  ONLY CONTAINERS CONTAIN LOCI ;-)

> Or do you dislike the control panel idea?

I like the idea of having some tutorial/help mechanism for teaching
inexperienced users/wannabe-developers how to construct the command-line, which
is what I see your control panel as being.  But I think it may be a year before
we should worry about it.

> Also, I really think that when a new loci is added

Added == dropped onto the workspace?

> 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.

But this idea is based on your earlier plan for having every program be well
defined about the required options.  It's a different plan from my own, as I
have been saying.  I would argue that the effort needed to define a locus your
way is equivalent to just going ahead and connecting all the critters.  So,
yeah, why bother with user-specified connections at all???  Or using more than
one locus??? But I'm saying that the user is/can be the developer who (XML)
defines a locus, ON THE WORKSPACE.  The workspace is an IDE! :-)

> >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.

Again, per my reply to Gary, the experienced user/developer determines the order
of command-line options via the order of command-line locus connections.

> 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.

Well, there is some confusion about the difference between 'pipe connectors' and
'string adding connectors'.  To clear up this confusion, the user/developer
might want to composite the command-line based on 'string adding' connectors':

*** NOW LET'S RE-INTRODUCE THE FILENAME TYPE LOCUS (sorry about that)

(Because my drawing space is limited, and because it may get a little hard to
read, I won't produce the example with an output file.)

                     ---->(1)+----------+
                     ---->(2)| x-povray |
+------------------------------------------------------------------+
|                                        |                  |      |
|        (workspace)                    \|/                \|/     |
|                                       (1)                (2)     |
|+-----------+      +------+        +---------+        +---------+ |
|| processor | ---> | flag | -----> | infile  | -----> | infile  | |
|+-----------+      +------+        +---------+        +---------+ |
|| x-povray  |      |  -I  |                                       |
|+-----------+      +------+                                       |
+------------------------------------------------------------------+

Each 'infile' type locus has 2 connectors: one is 'string adding' (unlabeled)
and the other is piping (labeled 1 and 2).

Both piping (1 and 2) connectors are disconnected.  So, they appear on the
composite locus:

                                 +----------+
                         ---->(1)| x-povray |
                         ---->(2)+----------+

                              (windowlet closed)

Now, connect the documents to the respectively numbered input connector, and
Da-ta-ta-da!!!


 +------------+         +-----------+
 |  document  | ---->(1)| x-povray  |
 +------------+     >(2)+-----------+
 |  def.ini   |    / 
 +------------+   /
                 / 
     +------------+
     |  document  |
 +---+------------+---+
 | my_povray_file.pov |
 +--------------------+

Oooo, that's so nice!!!

This would tell Loci to take the contents of the documents, put them into
temporary files, then construct the command-line as follows:

    x-povray -I /path/to/temp.def.ini /path/to/temp.my_povray_file.pov

> 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.

Okay, so you may want to use a composite, as I show above.  But, there is no
reason why you can't make connections (1) and (2) directly.

> 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.

Hmmm.  I think I know what you're talking about, but I'm not sure.

> > 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.

I meant the WFD for the command-line; a small WFD with just the command-line
loci, like above.

> 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.

I just need to make a couple routines for adding and deleting icons with their
windowlets.  'Unzapping' (or uncompositing or decomposing) a composite should
just require the WFD _inside_ the composite's windowlet (workspace in a
workspace) be copied to the main workspace.

> -----------------------------------------
> - 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.

I think a compose/decompose option could be put in the locus's pop-up menu.

>     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.

Thank you, Brad, for being so understanding and patient.  You can blame me for
not explaining things well enough.

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