Re: the canvas quest

[John Palmieri <johnp martianrock com>]

On Sat, 2003-03-29 at 14:06, Havoc Pennington wrote:
> On Sat, Mar 29, 2003 at 07:39:17AM +0100, Tim Janik wrote: 
> > i'm still in the need of a capable canvas implementation for beast
> > (http://beast.gtk.org) that basically supports:
> > - libart based anti-aliased rendering
> 
> At this point you may also want to look at Xr/Xc as the rendering
> engine, http://www.xfree86.org/pipermail/forum/2003-March/000032.html
> http://www.xsvg.org/
>  
> The main advantage over libart is that it abstracts things such that
> it can use hardware accel when available, and is being actively
> proposed as the new standard X vector API. Disadvantage is it's
> probably in more flux than libart and isn't *yet* standard in any way.
> 
> > - is there consensus about what the feature set of a future
> >   GNOME canvas platform will provide?
> 
> People mistakenly (and over some protests) were using pre-2.0 canvas
> as an implementation detail of other widgets, primarily for the
> no-flicker capability. However, with GTK now supporting no flicker and
> 32-bit coordinates natively, the canvas just adds overhead in that
> situation. Also, custom widgets are much more strongly discouraged
> these days as we have better standard widgets and custom widgets tend
> to hose accessibility and themes and keynav and so forth.
Educate me a bit on this? I am using the gnome-canvas for a couple of
custom widgets.  Basicly they are an Asset Manager, which works much
like a file manager except it keeps and catagorizes a collection of
files, and a Timeline which has a collection of frames and a head that
moves over each frame based on a time interval.  You can think of each
widget as similar to Macromedia's Cast and Score in Director (though
their scope is much bigger).   

I am at the start of the Asset Manager implementation and have
implemented the backend as a GtkTreeModel widget that can be displayed
using a GtkListView for debugging purposes but uses an Asset Manager
view which is based on the Gnome canvas.  I didn't take into account the
concerns you raised above and am now rethinking my design.  Would it be
better to create a custom Tree View? Basicly I am worried about the
layout which needs to pack rows based on how wide the widget is but
allow for columns to extend beyond the viewable region.  In other words
it should have the same behavior as Nautilus' icon view.

The other widget is a bit more complicated and I have not started it
yet.  It needs an almost infinite (read huge) number of cells and would
work mostly like a spreadsheet with a grid of rows and columns. The rows
would be the "channels" and columns the frames.  Again the backend will
implement the GtkTreeModel interface but I am not aware of any Gtk
widget that would be ideal for constructing the view.  The great thing
about the canvas and this widget is that all layout is done with
absolute coordinates since it never needs to reflow.  Frame 25, Channel
3 will always be in the same position based on the cell size which also
remains constant.

> So canvas has become much less important, and perhaps now needs to
> focus much more specifically on being useful for custom
> displays/editors of various kinds.
> 

If I should not use the canvas what would you suggest?  I want to keep
these widgets as light as possible and in line with the Gtk design.  I'm
still learning and it is slow going but I want to get things right.  

--
J5