[Pipet Devel] GST, widgets & figure building
Alan J. Williams
Alan at TheWilliamsFamily.org
Tue Jun 22 12:48:41 EDT 1999
< The table of contents on the right side of the web pages is gone.
Anybody know the URL to get to the Terminology Page. >
On Mon, 21 Jun 1999, J.W. Bizzaro wrote:
> It defines new high-level (predrawn) bioinformatics items.
> The items are derived from the standard GnomeCanvas items.
> The items are 1D nucleotide sequence, chromosome map, protein motif, etc.
> (the items are what you're calling "rendering widget"?)
Actually, I was thinking of two different types of derived canvas items
(although the distinction is probably artificial):
1) Ones which are not connected to data (other than the rendering data
such as position and size)
2) Ones which are connected to data (ie sequence data, plasmid map data)
> BTW, "traditionally", anything that displays publication-quality images from
> data is of the class "viewer". Anything that alters data is of the class
> "modifier". And data are of the class "document" or maybe just "data". I think
> we can also define subclasses for each of these (like your "rendering widget" is
> a subclass of "Figure Builder"?). "Figure Builder" referred to an actual
> drawing program (like Adobe Illustrator ;-) that also uses a viewer widget.
So we have:
+---------+
| Viewer: | Data Display
+---------+
|
+--> General Purpose Viewer (GnomeCanvas)
|
+--> Canvas Item Wrappers
(This would contain general info on the item such as what to
display in the pop up menu, is the item dragable, editable,
... The idea is that the General Purpose Viewer would be
able to get all the info and function calls it needs to work
with an arbitrary item from this info.)
|
+--> Items Provided by GnomeCanvas
| (Item, Group, Line, Polygon, Rectangle, Ellipse, Text,
| Image, Widget)
|
+--> Items We Provide which Are Not associated with data
| (Arrows, ???)
|
+--> Items We Provide which are associated with data
|
+--> Sequence(s) [individual residue/graphical]
|
+--> Plasmid Map
|
+--> Linkage Map
|
+--> Gel
|
+--> ....
+----------+
| Modifier | Data Conversion/Manipulation
+----------+
+----------+
| Document | Data Storage
+----------+
> I think the viewer should be a rather dumb widget that only draws what it is
> told to (draw a circle, for example). There should be a component(s) in-between
> the modifier and viewer ("translators" maybe) that will translate biodata into
> canvas items. It just makes things smaller, more modular, flexible and
> extensible (following the Loci paradigm).
So would you consider a derived item widget and it's wrapper as I've laid
out above to be a "component"?
BioData >-------\
\
>----> ViewerItemWidget --> Display on Canvas
/
Markup Data >---/
> I believe a translator would be part of what you are calling "Figure Builder".
> Translators in general take the XML/DOM objects and call Gtk and derived Loci
> widgets. They are typically sandwiched between data and viewers/modifiers
> (loci).
Yes! This is exactly what I am thinking: So for a given figure or view,
there is an associated xml data file with all the information the viewer
needs to build the figure. The Viewer parses the file and for each
element it creates the appropriate CanvasItemWrapper passing it the
data contained in the XML element. This way the general purpose viewer
doesn't need to know anything about the item it is constructing, only the
wrapper does. The wrapper will process the data and create the
appropriate canvas item with the appropriate parameters.
Viewer Data File (XML):
+---------------------------------------------------+
| </line x=23 y=34 width=3 length=10 angle=45> |
| </label x=23 y=34 angle=45 string="Hello World"> |
| </sequence id=db://foo.mo.hu/maize/12543ux> |
+---------+-----------------------------------------+
|
|
<SAX Interface>
|
|
V
Viewer
^\
/ \\_________________________________________
_________/ \___________________________ \
/ \ |
/ \ |
| | |
V | |
</line x=23 y=34 width=3 length=10 angle=45> | |
| | |
| V |
| </label x=23 y=34 angle=45 string="Hello World"> |
| | |
| | V
| | </sequence id=db://foo.mo.hu/maize/12543ux>
| | |
| | |
V V V
LineItemWrap LabelItemWrap SeqItemWrap
| | |
| | V
V V 1. Get sequence data
Create Gnome Create Loci 2. Create Loci Canvas
Canvas Line Canvas Label Item
Item Item
> Will we then be directly mixing graphical markup with biodata markup?
What do you mean by graphical? Graphical representation of sequences,
pictures, random vector drawings? All of the above I would hope.
> How will the graphical feature be marked in the sequence XML?
> <feature>
> </feature>
So things are a little complicated in that data for a particular item on
the figure may be spread across several xml files. So inorder to display
a conserved motif on a sequence we have in the Viewer XML Data file an
element for a Sequence Item with information needed by the Sequence Canvas
Item on how to display it. With that information there may be a directive
(an xml element) directing the display of a given feature. Probably a Bad
Example:
<VIEW>
<LABEL>
A Conserved Sequence Motif
</LABEL>
<SEQUENCE xlink="genbank://u456739" style textual>
<FEATURE xpointer="#4EBP Binding Domain" style=block>
<RECTANGLE>
... GnomeCanvasItem Rectangle Info ...
</RECTANGLE>
</FEATURE>
</SEQUENCE>
</VIEW>
So from this example, the Sequence Item would be derived from the gnome
canvas group and it would minimally include a text item to display the
sequence and a rectagle item to draw the box. The General Viewer would
pass all the info between and including the sequence tags when creating
the Sequence Item (through the sequence item wrapper). The Sequence Item
Wrapper would request the sequence information form the given location
and would then create a text item using that info. It would also create
a gnome canvas rectange item passing everything between the rectangle to
the rectangle item wrapper. It would set the location and size of the
rectangle based on the sequence position for the feature from the data in
the sequence file before passing the data on to create the rectangle.
> I'm a little foggy on how the viewer ("figure builder") will create a viewer
> item ("rendering widget") it knows nothing about.
All it needs to know is that the <SEQUENCE> element goes with the
LociCanvasSequenceWrapper class.
> It has something to do with "Bonobo", which may be an object model.
I think so, and the world DOMination white paper as well (i think). I
believe they are using a DOM approach to handling embedding.
> 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.)
The ability to at least imbed loci stuff into the gnome office package
(once it exists) would be awesome, but we would probably be better off to
focus on loci as a stand alone package for now.
************************************************************************
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
************************************************************************
More information about the Pipet-Devel
mailing list