[Pipet Devel] Re: [Pipet Devel] Re: overflow<->loci translation and 3 basic gui objects

[Gary Van Domselaar]

> 
> jarl van katwijk wrote:
> > 
> > >   (1) Network normal view: Nodes and relations are visible at
> > >       full size (icons and subwindows shown)
> > >   (2) Network world view: Nodes and relations are visible and
> > >       fit entirely in the window (icons and subwindows not shown)
> > >   (3) GUI view: Gtk widgets from all nodes are visible
> > 
> > The "GTk widget" from a node?
> > A node has a gtk-widget or is a gtk-widget 'created' by the gui to visualise it?
> 
> Each node has user-settable parameters (see what pops up when you double-click
> on an Overflow node).  As I mentioned before, these parameters are
> 'represented by XML' tags and translated into Gtk widgets so that the
> parameters can be set.  This XML makes up the 'XML representation of a GUI'.
> 
> The XML can then be arranged according to the arrangement of nodes in a
> network.  The result is a 'composite' GUI.
> 
> This seems to be difficult for everyone to grasp.  I'm not sure anyone on the
> Loci list understood me either, except maybe Gary.  Gary, can you explain this
> differently?

Sure.  There are three basic 'interface' concepts here.  The first concept deals with
dynamically obtaining and generating an interface from 'back-end' application or object. This
interface is for supplying the user definable options to the back end during execution.
The interface is supplied (from Overflow) as a high-level XML document to the client/user
interface. Of course, the XML contains extra information that may not be seen or manipulated
by the user, but is important in describing the application or object. But I digress. 
Assuming a Gtk/GNOME-based client, the 'application' would appear as an icon. Double-clicking
the icon reveals its interface for adjusting options. The client communicates this information
to the DL, which updates that application's XML representation, and stores it in a database.

The second concept concerns the connections/links made from one application/node/icon to
another.  The user creates a 'network' by connecting the applications together. The XML
representations get updated by the DL to reflect their relationships. In the end you have a
number of small XML files, one per application. The connectivity information is included a)in
the XML files, or b) in a 'parent' file (also XML).  I prefer b) because it aids in nesting
networks, as described below.

The third concept concerns nesting of 'networks'.  This is what Jeff refers to as a 'composite
locus'.  Essentially the idea is that once a network is created, it would be nice to treat the
network as a 'node', considering that once the options have been set, so it is essentially
'static' at this point: it need only have its input and output defined.  The 'network' can be
encapsulated, and treated like an elementary node. The user can create place this (sub)network
into a new new network. The icon that represents this network can be double clicked to reveal
the subnetwork.  If we used strategy b) to store our node relationships, then the XML that
represents this network would be contained in this parent file. Incidentally X,Y coordinates
for the icons/nodes could also be stored in this parent file, thus preserving the original
layout of the network. It would be faster, too, because you wouldn't have to query the XML
file associated with each node in the network for connectivity information.

In this fashion, networks can be infinitely nested, and the XML representation of the network
would be fast, manageable, and easy to parse by the DL for execution.



At least, that's how I understand it. Jeff?


I understand that these concepts are heavily user-and-XML-representation-oriented, and may not
jive exactly with the architectures of Overflow or GMS. But I hope it clarifies a bit the
Loci 'grand scheme'. 

Regards,

g.
--
                              Gary Van Domselaar
                           gary at bioinformatics.org
                      http://www.bioinformatics.org/~gary
            ----------------------------------------------------              
                       bioinformatics.org: The Open Lab
                        http://www.bioinformatics.org/