[Pipet Devel] GST, widgets & figure building

[Alan J. Williams]

On Tue, 22 Jun 1999, J.W. Bizzaro wrote:
 > posted, and every page had to be changed when a link changed.  It might have
 > made sense to use an HTML preprocessor to give every page the same table on the
 > right, but I just settled on the old fashioned approach.  Anyway, here is the

As an aside, I've done a fair amount of server side scripting with PHP.
Great for just this thing!

 > The ones that are not connected to data, are they added by the user?  I was
 > thinking, to keep things simpler, the viewers that are part of the workspace or
 > workflow diagram don't act as fully functional drawing programs.  IOW, the
I think this is where I am confused. So your thinking with loci is flow
centric where the view I am working with is data centric. So what type of
data flows do you envision Loci supporting. One-to-one, one-to-many,
many-to-one?

 > workspace viewers can't get new items attached (like arrows) by the user.  I
 > think that the figure produced in the workspace should be exported to the Figure
 > Builder (the actual drawing program) for that purpose.  Of course the figure
 > would still maintain its links to the biodata while in the Figure Builder; it's
 > just that the FB would give the user more space and tools, and would allow
 > multiple viewer items to be combined.
Now I am confused! So, from a loci perspective, there is the figure
builder which builds a figures from output. Separately there are viewers
which are essentially objects which translate biodata into a 2-d visual
presentation.  The viewers can appear in the workspace data flow as well
as in the figure builder, however the figure builder is NOT part of the
workspace data flow?

 > By George, I think he's got it! :-)
Don't be so sure! :oP

 > This is what I'm thinking:
 > 
 >                                           Major Class / Minor Class
 >                                           =========================
 > 
 >                                  ---+
 >         XML data                    |     Document / Plasmid Sequence
 >            |                     ---+
 >            |
 >            |
 >      ViewerTranslator            ---+
 >      calls XML parser               |
 >      to get data objects            |
 >            |                        |
 >            |                        |     Translator / Plasmid to Restriction
 >            |                        |                     Map View
 >       ViewerTranslator              |
 >       calls Viewer to               |
 >    draw a "restriction map"      ---+
 >            | 
 >            |
 >            |                      ---+
 >   Viewer calls RestMapViewerItem     |
 >      to do its job                   |
 >            |                         |
 >            |                         |        Viewer / Restriction Map
 >            |                         |
 >      RestMapViewerItem               |
 >     draws restriction map            |
 >                                   ---+
 > 
 > Do you really want to combine the Translator and the Viewer?  In the above
 > example, the translator connects a plasmid to a restriction map view.  If the
 > biodata were a bacterial genome (also circular), we could just swap Translators
 > and keep the same Viewer.
ABSOLUTELY NOT! But you actually are combining them in the above example.
The restriction map data would be generated by a program/translator and
the viewer would simmply be responsible for presenting the data, not
generating data as in the example above.

 > I guess what you're calling a "Wrapper" is a combination of my Translator +
 > ViewerItem.
Wrapper is a bad term here. Sorry.  By wrapper I am just meaning an object 
wrapper around the appropriate gnome canvas item widgets.

 > Nice diagram!  I think we're just switching a couple things around.  When SAX
 > passes the data to the Viewer in this diagram, are the data in a Python object?
Uh, SURE! Well, maybe. The simplest would be for an object to be generated
from the xml.  The disadvantage of this approach is if we are processing a
huge sequence (or better yet a database!). These are better (memory wise)
handled as streams to my thinking.  So if data objects in loci can take
xml input for construction and dump xml, we can just pipe/pass the xml.

 > Yes, any presentation data.  Are you mixing presentation and biology in the same
 > XML flat file?  I guess you answer that below.
No. But in some sense the data to generate a figure is "biodata" in and of
it's own right from a program perspective with references to other types
of "biodata".

So there might be a: Sequence Document
                     Restriction Map Document
                     Restriction Map Figure Document
 

 > How do you think this fits in with what you're saying?  Again, I think we're
 > just switching thinks around.  So, I guess this is the way you see it:
 > 
 >            Document / Sequence
 >                     |
 >                  Viewer
 >                     |
 >          Translator / Seq To Motif
 >                     |
 >             Document / Motif
 >                     |
 >              Motif ViewerItem
 > 
I am not sure I understand where the translator and motif doc come from.
What I am thinking is that sequence is not just a simple sequence, but an
annotated sequence with features.  Alternatively we might have a sequence
document and a separate features document generated by a translator (lets
say a gene prediction program). Both these documents and the translator
have nothing to do with viewing the data and shouldn't be part of the
viewer. The viewer simply takes the sequence document and lets say an
optional separate features document and displays it.  No there are a lot
of different ways to display features: draw a box around the actual
sequences, draw the sequence as a box with features in different colors,
draw filled in boxes under the sequence, etc... So once a user decides
what features he wants displayed and how, we need to be able to store that
info so we can rebuild the figure. I think your confusing what you are
calling the motif document with what I was calling the markup document.
The markup document would not have any motif/feature data. It would only
contain the information that the figure builder would need to reconstruct
the figure. 

Well, not sure this helps at all.

Some other questions:

    1) In your workspace, each line is a data pipe.  Will loci (the
program) be able to store that data and essentially restart the data pipe
from that point?

    2) Do you envision loci managing other data besides strict biodata
(ie data on how to reconstruct the data flows, data on how to build
displays/figures, ...)

    3) Is there are good post/document/whatever that outlines the
philosophy/architecture for loci?

************************************************************************  
Alan Williams           
------------------------------------------------------------------------  
University of California, Riverside   "Where observation is concerned,
Dept. of Botany and Plant Sciences     chance favors the prepared mind."  
Alan at TheWilliamsFamily.org                         -- Louis Pasteur
************************************************************************