[Pipet Devel] GST, widgets & figure building

[Humberto Ortiz Zuazaga]

> My plan for GstMultiSeq is to have a widget that allows one to work with
> and edit multiple sequence data, add markup (ie change fonts, colors, add
> boxes).  The problem comes with redundancy: should the MultSequence widget
> also handle/allow for drawing arrows, adding arbitrary text, etc ...

I vote no. The multi sequence widget should allow you to edit the alignment 
and define features. The fig builder should decide how to display the 
features, (mark feature A with a yellow box, put a red arrow under feature B, 
...).

> the figure builder presumably has no notion of sequence data, so if I
> deleted a chunk of sequence data, all my arrows in the figure builder
> would then be screwed up!

Not anymore. We could also allow the fig builder to call back to the multiseq 
editor, so if we click on a base and add an arrow in the fig builder, the 
multiseq editor gets called to add a new feature to the multisequence, this is 
harder, but the right way to do it.

> At any rate, this is a good example of where the markup for a figure is
> really part of the data as well, so the line between figure and data is
> yet again blured.

Now the data is a multiseq object, with a list of features, and the markup is 
a list of visual attributes to apply to the data and the features.

Another option is that the figbuilder simply calls the multiseq editor with a 
pointer to the canvas region where it should draw its output. The multiseq 
editor will own that piece of the canvas, and register callbacks for the 
canvas items it draws. All of the multiseq editor's display (draft and final 
mode) can be done to the gnome canvas.

How do the gnome and KDE office suites handle embedding objects into other 
documents (like a graph in a paper)? This seems to be exactly the same kind of 
situation.
-- 
Humberto Ortiz Zuazaga
Bioinformatics Specialist
Institute of Neurobiology
hortiz at neurobio.upr.clu.edu