Re: the canvas quest

[Jody Goldberg <jody gnome org>]

On Sat, Mar 29, 2003 at 07:39:17AM +0100, Tim Janik wrote:
> an evaluation of available canvas implementations revealed:
> * dia-newcanvas (v0.6.10):
>   - aa renderer not implemented
>   - text not zoomable
>   - doesn't use pango to render text
Last I looked it also had a model view split which is a nice
feature.

> * foocanvas (recent CVS):
>   - no aa rendering (probably not planned even)
not that I know of.  Although the rect-ellipse does have some RENDER
extension magic to do alpha blending of content.

>   - text aparently doesn't zoom with other objects
A good point.  This behavior would be a nice extension, but it would
need to be optional.

> * libgnomecanvas
>   - gets little maintenance if at all
It gets maintenance ??

> * a wild variety of cut-n-paste versions of the above
>   implementations in third-party projects (eel, gnumeric, etc...)
eelcanvas == foocanvas
and gnumeric derives from foocanvas to add a few utilities for
grabs.

> i see a fundamental problem here in terms of effort duplication,
> maintenance, and development platform consistency (i doubt i'm the
> only person unsure about what to pick). so i'd like to see the
> following issues being adressed:
> - is there consensus about what the feature set of a future
>   GNOME canvas platform will provide?

Hard to say.  I don't see AA as a requirement but I suspect you
would.  It always seemed kludgy to have the aa and non-AA code share
implementation when the rendering mechanisms were so different.

> - (assuming "no" to the above) what are peoples opinions on:
>   a) replacing lbgnomecanvas with say foocanvas
http://bugzilla.gnome.org/show_bug.cgi?id=79286

I'd be happy to see foocanvas become GtkCanvas.  At this point it is
a delicate balance working on the canvas, whether to do the work in
the core or just tack on the extensions in gnumeric's derivation.

>   b) merging foocanvas code/fixes back into libgnomecanvas
>      (kinda defeats the idea of foocanvas being "leaner"
>      than gnomecanvas in the first place, though that may
>      be a questionable design goal in itself)

The main benefit of foocanvas was not 'leaner' so much as better
integration with the gtk2 rendering framework.  The gnome2 port of
the canvas was a performance beast.  The issues seemed to stem from
using AA representations for the non-AA mode.

>   c) implementing an aa renderer for dia-newcanvas, adding
>      pango support to it so it becomes a suitable replacement
>      for libgnomecanvas

The diacanvas does have some nice features.  Chief among them being
the model view split.  For office apps, like gnumeric, having a nice
library of drawing objects _with_ pref dialogs.   Would be a huge
win.  I have not done any serious work to do such a port though.
Having a libdia or libsodipodi would be quite nice for alot of
applications.

> - are there any other efforts currently being persued to reduce
>   the rediculous cut-n-paste orgies of canvas code across
>   various projects?

sodipodi.
I've corrected lauris' email on the cc list.

None of us appear to be ready to step up to the plate and drive the
work forward.  I've been too selfish for years and just fall back on
Gnumeric work.