[Pipet Devel] GST, widgets & figure building

[Humberto Ortiz Zuazaga]

> > I like your point which reinforces the idea that the editor should simply
> > be used to define features, not how they are displayed.
> 
> Me too.

Good, now just keap repeating after me "the data is separate from the markup, 
the data is separate from the markup, the data is separate from the markup, 
..."

> Will we then be directly mixing graphical markup with biodata markup?

Not if I can help it.

> > Another way (with the rendering widget idea) is that each rendering widget
> > can register whether or not it can handle dependent markup.

> > The rendering widget will store the characteristics of
> > the arrow in the markup object.  The rendering widget will also create a
> > new feature in the sequence data object using the position and id info in
> > addition it will prompt the user for a label as well as a residue to
> > anchor the arrow to.

Yes, this is right. And the only widget that can do this is the rendering 
widget. It has to understand the data (a multiseq object) and the markup (a 
markup object) and be able to combine them.

> How will the graphical feature be marked in the sequence XML?

It won't, it'll be stored in a separate markup XML (remember: "the data is 
separate from the markup, the data is separate from the markup, the data is 
separate from the markup, ...")

> > Now when an old Markup Data Object is to be rendered (or a Figure Builder
> > Data Object), figure builder will go through the list of markup rendering
> > each one.  When it gets to an unknown item type, it will create the
> > appropriate rendoring widget to handle the display.
> 
> I'm a little foggy on how the viewer ("figure builder") will create a viewer
> item ("rendering widget") it knows nothing about.

It can ask the locid who registered as being able to render multiseq objects. 
It actually can be simpler than this though. I've been beating myself up 
trying to figure out how to get the figure builder to be able to produce a 
multisequence figure without duplicating the multisequence editor.

This is exactly what the koffice and gnome office suites do, for a quick 
overview, see:

http://www.mieterra.com/article/koffice.html
http://www.gnome.org/white-papers/Components/Components/

Forget office suites, and think: kpresenter is the figure builder, 
kspreadsheet is the multisequence editor, kdiagram is a multisequence renderer.

So you can think of editing a multisequence in a small app, then dropping the 
multisequence onto a blank figbuilder canvas. clicking on the multisequence 
figure in the figbuilder will allow us to use the multisequence editor menus 
to manipulate the figure.

This is how embedding charts and figures into MS-Word works, and is doable 
with the corba-based tools in KOffice and in the gnome toolset (I'm not 
suggesting we move to KDE, the same facilities are available in gnome, so it's 
just a matter of getting the python bindings set up). By the way, pygnome 
already links to the ORBit libraries, are there bindings available to access 
any of this?

> There is A LOT of new functionality coming to Gnome and even Mozilla (SVG for
> example) that is very much like what we need for Loci.  A point though that I
> would like to make is that these features are so general-purpose, it would be as
> difficult using them to embed a component into Loci, as making a new stand-alone
> program (a reason for not using Loci).  In addition, they are made with C/C++,
> which would have to be wrapped in Python.  It would be much simpler using only
> Python.  (The same argument though can be used against CORBA and in favor of
> PAOS.)

But corba buys us much of the hard parts of the loci model: embeding active 
figures in a figure builder, and exporting a program's functions to a remote 
site. We'll get this for free, by just setting up python bindings to the 
already available tools, plus we get a whole pile of developers working on the 
ugly issues and lets us get back to what we do best, bioinformatics 
programming.

A good set of python bindings to ORBit would allow us to build a locus by just 
subclassing from LocusComponent and adding some bindings for our application 
specific functions.
-- 
Humberto Ortiz Zuazaga
Bioinformatics Specialist
Institute of Neurobiology
hortiz at neurobio.upr.clu.edu