[Pipet Devel] GST, widgets & figure building

[J.W. Bizzaro]

"Alan J. Williams" wrote:
> 
> As an aside, I've done a fair amount of server side scripting with PHP.
> Great for just this thing!

Maybe after things pick up we can bring back the table of contents.  If you'd
like to help, that would be great!  BTW, I noticed you haven't logged into your
account yet.

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

Yes. Yes. Yes. Yes. Yes.  What were you thinking?  I guess we are on different
planes of quantum reality, but we'll hammer things out ;-)

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

That pretty much sums it up.  Except, Viewers are widgets+ that handle
ViewerItems, which are graphical objects, and Figure Builder is one "big" Viewer
running as a separate application.  The user can then copy/paste or drag/drop
multiple graphical objects (ViewerItems) onto the FB.  This allows the user to
choose only the Loci-generated figures they want for an illustration.  What were
you thinking of?  Is there anything wrong with this approach?

> 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 agree with you.  I'm not sure why you think I combined the Translator and
Viewer.  Maybe saying "ViewerTranslator" is confusing.  I only wanted to show
that the Translator is specifically for Viewers.  So, ViewerTranslator ==
Translator.  Sorry, I deleted the diagram.

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

You mean something like a composite widget?

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

Yep.  This whole "what format is best for object transfer?" problem is what
Justin and Humberto have been working on.  We'll have to come up with something
soon.

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

I like that.  I think we're on the right track.

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

I just thought this is how you are seeing things.  I guess not.

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

That sounds good.  (Technically though a gene prediction program would be a
"Modifier" that is linked to a Translator ;-)

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

Nothing directly to do with viewing.  So you have:

    Doc / Seq
        |
        |
        |
    Trans / Seq to GenePredict
        |
        |
        |
    Mod / GenePredict
        |
        |
        |
    Trans / GenePredict to AnnotatedSeq
        |
        |
        |
    Doc / AnnotatedSeq


(Translators sandwich everything.)  Now this has nothing to do with a Viewer,
but if the user wants to add a Viewer, they have to add these loci:


    Trans / AnnotatedSeq to ASViewerItem
        |
        |
        |
     Viewer / ASViewerItem

> 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 was thinking that the custom ViewerItems (canvas objects) would be
composite/derived GnomeCanvasItems.  So, you only need to say (a little PyGNOME
here):

    annotated_seq = canvas.group.add('ASViewerItem', <argument list>)

And the <argument list> specifies just how the annotated sequence will look. 
For example, this is a text item I added to a canvas group on the Workspace:

        locus.group.text = locus.group.add('text',
                                           text=locus.label,
                                           x=text_x,
                                           y=text_y,
                                           font=font,
                                           fill_color_gdk=self.color_fg,
                                           anchor=ANCHOR_NORTH)

We can make a whole set of arguments for an annotated sequence or any other
graphical bioinformatics object.  This information can be stored/passed in a
markup document.

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

Oh, okay.

> Some other questions:
> 
>     1) In your workspace, each line is a data pipe.  Will loci (the

Yes.

> program) be able to store that data and essentially restart the data pipe
> from that point?

That's a good question.  I thought about that while coding the Workspace, and it
seems I may need another XML to store an entire WorkFlow Diagram, in case it
needs to be restarted.  The Workspace can even be something the user can
New/Open/Save/Close as if it were a wordprocessing document.  I think this
should be tied into the whole "Electronic Notebook" idea, since the EN and the
Workspace will be managing the same information.  Interesting.  Any thoughts?

>     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, ...)

This may be related to the first question, but yes.  There will be lots and lots
to manage.  Perhaps Loci will make the most use of different XML's of all other
programs before it.  I think everything will be linked, even different XML's,
and this would be done by cross-referencing.  At the highest level we will have
the Workspace, and at the lowest level, maybe the biodata.  Loci will be a big
challange for some XML "X-perts".

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

Loci has evolved a great deal.  I started with some sketchy concepts about a
year ago, which are still present in the current model.  But the actual
implementation of the concepts was never put in stone.

Justin has been with the project for a while and set up the original mailing
list.  The archive is still up.  There's lots of design talk in those old
messages.  It's probably a good way to get the feel for where Loci is going.

    http://toaster.sped.ukans.edu/tulip-list/

But again, so much has changed.  We'll just have to see how it turns out in the
end :-)  Everytime I try to write something, it's incomplete because the
implementation is unclear, and then everything changes a week later after a few
messages have been passed.  And often just doing some coding takes us down a
different path, as with the Workspace.

Some people are very good at planning every move.  I hope that leaving a few
things up in the air will allow for some innovation and creativity.  For
example, I think you contributed a great deal to the design already :-)  Some of
what we've been talking about were not very clear to me before.


Cheers.
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro at bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--