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 ************************************************************************