[Pipet Devel] GST, widgets & figure building

Alan J. Williams Alan at TheWilliamsFamily.org
Mon Jun 21 14:04:03 EDT 1999


On Mon, 21 Jun 1999, J.W. Bizzaro wrote:
 > GstMultiSeq and the editor can be implemented.  One unique feature of Loci is
 > (or will be) that data are displayed as vector graphics (or at least raster
 > images) so that the user can create a figure for publication directly from
 > Loci. 
Certainly inorder to be useful we must be able to output the data in a
presentation quality manner.  Given all the work on the gnome canvas (esp
with anti-aliasing on text and the proposed gnome printing archetecture)
that would be the place to start for building a presentation/output
widget.  This does tie you down to the gnome archetecture as opposed to
just gtk+. Part of the problem comes in that sometimes we work with the
data in a manner different from how we present it on paper.  Multiple
sequence data is a good example -- It is easier to work with the data for
each sequence on a single line, but on paper we need to break the
alignment into chunks.  If I remeber correctly, the Loci way of doing data
presentation is to have separate locus for analyzing data, editing datam,
and presenting data; likewise I think we should have different widgets for
each (only when necessary however). 

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 ... This
is all stuff that the gnome canvas based figure builder would do.  But
from a user perspective, it would be nice to be able to add all that stuff
in the sequence editor.  An added benifit is that the seqence widget can
handle moving extra objects around as sequence data is added or deleted,
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! So the best approach seems to be to implement as
many position depended drawing functions into the editor as possible, and
then write a companion widget that can take that data and display it on a
gnome canvas.  

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.

As for my current implementation of GstMultiSeq (or more specifically
GstMonoText) it is a GtkDrawingArea (no gnome stuff).  The widget uses two
off screen pixmaps (one with the data rendered, and another to do reverse
drawing for showing selections). An advantage to this approach is that
only the part of the sequence being looked at is rendered (so if we have a
huge genomic fragment, we don't allocate a bunch of memory or waste time
rendering all of it). The speed of this approach seems pretty good.  

So one basic approach for writing interactive widgets:

    Interactive Widget --> derive from whatever you want
                           does whatever you want
                           outputs XML data
    Figure Display Widget --> Derive from gnome-canvas-item widget 
                              Takes the XML data and displays it
                              Allows for appropriate modification of the
                                 data

So with a sequence editor example:

    Sequence Editor Widget:
      * Implements display and editing of sequences
      * Allows for cut and paste
      * Allows for sequence position depended markup
          - Color and Font Changes
          - Boxes and Shading of certain residues
          - Arrows or textual notes to certain residues
          - Allow for calls to other loci programs to further alter the
            data           
      * Allow setting of display characteristics (which are stored in the
        sequences XML data

    Sequence Display Widget:
      * Will display seqence data on a gnome canvas
      * Will allow alteration of display settings
          - Number resudues per line
          - Ruler Display
          - Sequence Labels
          - Clipping of data (Only show residues 456 to 1043)

With this approach, all changes under the sequence editor would be
automattically reflected when the figure is refreshed.

Now if you can implement your interactive widget as a gnome canvas item,
then you only need to implement one main widget (display widget) as well
as a wrapper widget which just has a gnome-canvas and displays the gnome
cnavas item widget.  This way the user can work with the data under its
own display (with the wrapper) or under the figure builder.  The plus with
this approach is that the user gets the same interface under either
environment.

Well, not that I am a GUI expert or anything, just my ramblings on the
topic.

 > The first widgets I planed on making for Loci were going to literally draw onto
 > a (gnome) canvas widget.  Since the drawing program to accompany Loci will use
 > the same canvas, copying data will be trivial.  However, more interactive
 > widgets, such as GstMultiSeq, probably won't use the same canvas...I don't
 > know.  What are you using for your widgets?  Any thoughts?
 > 
 > 
 > :-)
 > Jeff
 > -- 
 > J.W. Bizzaro                  mailto:bizzaro at bc.edu
 > Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
 > --
 > 
 > _______________________________________________
 > pipet-devel maillist  -  pipet-devel at bioinformatics.org
 > http://bioinformatics.org/mailman/listinfo/pipet-devel
 > 

************************************************************************  
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
------------------------------------------------------------------------  
  "But as for me and my house, we will serve the Lord."  Joshua 24:15
************************************************************************





More information about the Pipet-Devel mailing list