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