Re: the canvas quest

[Andrew Sobala <aes gnome org>]

On Sat, 2003-03-29 at 06:39, Tim Janik wrote:
> hi all.
> 
> apologies for the mass mailing, i'm just trying to catch everyone
> (remotely ;) involved.
> 
> 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
> - bpath, rect-ellipse, polygon functionality
> - pixbufs
> - zoomable text items (doing pango-based UTF8 rendering)
> 
> 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
> * foocanvas (recent CVS):
>   - no aa rendering (probably not planned even)
>   - text aparently doesn't zoom with other objects
> * libgnomecanvas
>   - exposure problems with pixbufs (years old but still remain)
>   - text not zoomable
>   - gets little maintenance if at all
> * a wild variety of cut-n-paste versions of the above
>   implementations in third-party projects (eel, gnumeric, etc...)
> 
> there may well be other significant differences, these are the
> ones i focussed on for a start, because they are of interest to beast.
> but beyond my requirements for beast...
> 
> 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?
> - (assuming "no" to the above) what are peoples opinions on:
>   a) replacing lbgnomecanvas with say foocanvas
>   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)
>   c) implementing an aa renderer for dia-newcanvas, adding
>      pango support to it so it becomes a suitable replacement
>      for libgnomecanvas
> - are there any other efforts currently being persued to reduce
>   the rediculous cut-n-paste orgies of canvas code across
>   various projects?
> 
> comments, corrections etc. are aprechiated. after all there seems
> to be the need for a much larger problem to be solved than just
> finding a canvas implementation for beast.

libgnomecanvas is part of the GNOME platform and carries a guarantee of
API (/ABI?) stability until the end of GNOME 2.x. Although it may not be
the best canvas, it's here to stay...

-- 
Andrew Sobala <aes gnome org>

"If we eventually have the ubercool component system - based on Bonobo, or
something else - then great, we can then proxy it over IIOP, D-BUS, SOAP,
and morse code." -- hp