[Pipet Devel] composited GUI's revisted, part 2 (was: excerpt from CHANGES)

[J.W. Bizzaro]

Thanks for reminding me that I didn't get to part 2.

Gary Van Domselaar wrote:
> 
> > 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.
> 
> I have 2 questions about the 'zapping' part:
> 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? Say, like, take for example a standard POVRAY command-line:
> 
> loci>x-povray -Idef.ini  my_povray_file.pov
> 
> For the unitiated:      -I requires the name of the povray config file
> def.ini

Should there be a space in there?   -Idef.ini  or  -I def.ini

>                         my_povray_file.pov is the input filename.

Are you asking, 'How would -I be associated with def.ini?'

> Using Jeff's method, would you create a WFD like this?

(I'm shortening your table a little cuz it wraps after 80 cols.)

Header    Conn  Option    Conn  Field         Conn  Field
-----------------------------------------------------------
URI path  +     FLAG=-I   ->    ENTRY=def.ini +     my_pov...pov
LOCUS_ID        DESC="Config File"                  DESC="Input File"
LOCUS_NAME
LOCUS DESCRIPTION
Etc.

> Using the concatenator symbol '+' to represent the concatenation of
> 'unassociated' flags

...because it doesn't matter the order in which unassociated items are
written?  Okay.

> and the 'association'
> symbol (->) to associate the Flags with their required fields (note:
> these symbols are are mine and in no way reflect the symbols of my
> employer ;-)

Hmmm.

> or would you  instead use a 'concatenation connector (+)'
> for all the connections, and use composite loci to associate the flags
> with their required field?

It is THE ORDER IN WHICH THINGS ARE CONNECTED that determines the order of the
command-line fields.  Simple as that.  I'm expecting the user/developer would
put things in the right order.

So, your povray command line...

    x-povray -I def.ini my_povray_file.pov

Would be 4 loci connected like so:


 +-----------+      +------+      +----------+      +----------+
 | processor | ---> | flag | ---> | filename | ---> | filename |
 +-----------+      +------+      +----------+   +--+----------+------+
 |   povray  |      |  -I  |      |  def.ini |   | my_povray_file.pov |
 +-----------+      +------+      +----------+   +--------------------+

Notice the loci types used here:

  (1) processor
  (2) flag
  (3) filename

and that I haven't put types flag and filename in Loci yet.  We'll have to
make them.  THERE ARE MANY MORE TYPES TO BE DEFINED THAN WHAT I HAVE ALREADY
DEFINED.

So, Brad, maybe type 'option' can be split up into flag, filename, and...what
else can go on the command-line?  Regex?

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

Okay, note that the underscore ____ used to surround option names means that
there is an edit box there, or a way to make a selection.

Now, *IF* all options were changeable, you'd have something like this:

(COMPOSITE GUI!!!)

+---------------------------------------+
| PROCESSOR                             |  (processor name supercedes others)
+---------------------------------------+
|                                       |
| o Executable  _x-povray______________ |
| o Flag        _-I____________________ |
| o Filename    _def.ini_______________ |
| o Filename    _my_povray_file.pov____ |
| o Message     _Povray is cool________ |
|                                       |
|              [Execute]                |
+---------------------------------------+

But, *IF* none of the options were changeable, you'd have something like this

(COMPOSITE GUI!!!)

+---------------------------------------+
| x-povray                              |  (name is now set)
+---------------------------------------+
|                                       |
| o Executable   x-povray               |
| o Flag         -I                     |
| o Filename     def.ini                |
| o Filename     my_povray_file.pov     |
|                                       |
|              [Execute]                |
+---------------------------------------+
|            Povray is cool             |  (message is now set)
+---------------------------------------+

Notice the edit boxes are gone.  The names of options are now simply text
labels.

But I think we should also be able to hide the labels, for simplicity:

(COMPOSITE GUI!!!)

+-------------------+
| x-povray          |
+-------------------+
|     [Execute]     |
+-------------------+
|   Povray is cool  |
+-------------------+

Cheers.
Jeff
-- 
                      +----------------------------------+
                      |           J.W. Bizzaro           |
                      |                                  |
                      | http://bioinformatics.org/~jeff/ |
                      |                                  |
                      |           THE OPEN LAB           |
                      |    Open Source Bioinformatics    |
                      |                                  |
                      |    http://bioinformatics.org/    |
                      +----------------------------------+