[Pipet Devel] GST, widgets & figure building
J.W. Bizzaro
bizzaro at bc.edu
Tue Jun 22 18:49:17 EDT 1999
"Alan J. Williams" wrote:
>
> < The table of contents on the right side of the web pages is gone.
> Anybody know the URL to get to the Terminology Page. >
Sorry about that. I was getting some complaints that the links on the right
were broken, which they were because there was too much that needed to be
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
link. I didn't put it on the updated Loci page because some of the terminology
is getting out of date. So, I caution you that some things have changed.
http://bioinformatics.org/loci/documentation/gloss.html
>
> 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)
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
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.
>
> 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
> +----------+
By George, I think he's got it! :-)
Of course these aren't the only locus types/classes. We'll find a few more,
like "Translator" should be one. About the nomenclature, loci are named as
things that perform an action upon a document: a Modifier modifies a document, a
Viewer views a document, etc.
> 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 would consider the ViewerItem to be a subtype of the Viewer. Yes, it probably
would be a component, with its own box on the workspace.
The scheme I have worked up now is that the major type of a locus (such as a
Viewer) is represented by a certain box shape in the workspace. The minor type
(such as a ViewerItem) is represented by an icon in the major type's box shape.
So, for example, a Document is represented by a rectangular box, and a Sequence
is represented by an icon that is a picture of a sequence inside of a
rectangular box. The screenshot on the homepage doesn't show different box
shapes, but you can see how icons are shown inside of boxes.
> 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 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.
> 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.
I guess what you're calling a "Wrapper" is a combination of my Translator +
ViewerItem.
>
> 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
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?
>
> > 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.
Yes, any presentation data. Are you mixing presentation and biology in the same
XML flat file? I guess you answer that below.
>
> > 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.
Oh, so the example above is contrived by mixing biodata with the Viewer items.
So, methinks the workflow diagram may include another Document:
Document / Sequence
|
|
|
Translator / Seq To Motif
|
|
|
Document / Motif
|
|
|
Viewer / Motif ViewerItem
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 just think it would be easier to represent loci on the workspace by keeping
the ViewerItem as a minor class of Viewers.
> 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.
I agree. Loci should have a consolidated core and act like a single
application, rather than be a loose collection of Gnome tools. However,
import/export should work in Loci like it would in any other Gnome app. But
that's a long way off.
:-)
Jeff
--
J.W. Bizzaro mailto:bizzaro at bc.edu
Boston College Chemistry http://www.uml.edu/Dept/Chem/Bizzaro/
--
More information about the Pipet-Devel
mailing list