[Pipet Devel] [Fwd: Sodipodi and Loci]

J.W. Bizzaro bizzaro at geoserve.net
Fri Jan 14 00:02:31 EST 2000


Brad Chapman wrote:
> 
> What is the current gameplan for attempting to implement this XML -> GUI
> parsing?
[...]
> c. Define our own XML and write our own parsers to generate user interfaces.

Something like this one.  To start, the middleware will tell the frontend that
some parameter needs to be set or that some elemental component from the
library is needed.

So, if a locus needs a certain parameter set, say a flag, the middleware would
pass an XML object like this:

    <parameter type=list value="-a,
                                -b,
                                -c,
                                -d,
                                -e,
                                -f">

The frontend would then choose the most appropriate element from its library. 
For example, the Workspace might choose a pulldown menu that has already been
made as a composite widget.

Brad, your filesystem widget (that goes in the container locus) is an example
of what the Workspace can choose from its library.  In this case, the
middleware might send a request to select a locus/file:

    <parameter type=choosefile>

The Workspace would then just plop your widget into the windowlet.

REMEMBER: We're talking about high level representations of GUI components
here.  The main reason for this: so that we can use different frontends (e.g.,
Web interface) with the middleware.  Another reason: so that when loci are
composited, the middleware doesn't have to mess around with the subtleties of
Gtk+ design.

On the other hand, the way for us to have non-Python GUI widgets would be to
use an XML description.  We could go with Glade or something else in this
case, but make the _Workspace_ handle this, not the middleware.

IOW, I'm proposing that we have at least one XML definition:

    * A very very high level request by the _middleware_ for a parameter or
library component

And the other is possible:

    * A description of the Gtk+ GUI to be read only by the _Workspace_

> Since I am starting to mess around with developing widgets and everything,
> this is a pretty interesting subject to me, as I rather be making them in
> XML. I would be really interested to hear everyone's ideas/suggestions
> about this subject!

What is now coded in Python:

    document.py
    processor.py
    container.py
    ...

could be done in XML, as I wrote above.  But remember, this would only be
handled by the Workspace and not by the middleware.

Please take a look at libglade, which comes with gnome-python and will become
a big part of Gnome.  This page should be helpful:

    http://www.baypiggies.org/10mintig.html

>         I also have another random idea that might be possible _instead_ of
> using an XML-> gui converter. We could only have two GUI interfaces--the
> current Gtk/Gnome one, and a Java one. If we used JPython to script the
> java interfaces, we could make use of these GUI interfaces. I can think of
> some advantages to this approach:

Gasp!  Are you suggesting we rewrite the Workspace in Java?  :-O  I think most
of the great and mighty Locians would disapprove ;-)

Of course, we should keep multiple development languages in mind here: Perl
and Java are favs of bioinformaticists.  C/C++, Tcl/Tk, FORTRAN and Pascal are
considerations too.

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