What does Achtung do with its canvas? I just saw it pass in the
Gnome-components mailing list archive. Is it worth looking at?
Should the Achtung folks make a wishlist too?
Arjan
> -----Original Message-----
> From: Alexander Larsson [mailto:[EMAIL PROTECTED]]
> Sent: woensdag 19 april 2000 20:11
> To: [EMAIL PROTECTED]
> Subject: Re: New canvas??
>
>
> On Wed, 19 Apr 2000, James Henstridge wrote:
>
> > On Tue, 18 Apr 2000, Alexander Larsson wrote:
> > > * GnomeCanvas supports a general affine transformation of
> all objects,
> > > should we have this? It can be very useful, but it also makes many
> > > item-implementations very difficult, and might not be
> used by very many
> > > applications.
> >
> > It would be nice to add support for this. Rotations in
> particular would
> > be nice to have.
> >
> > >
> > > * The libart micro-tile array structure might be a good
> way to handle
> > > handling of partial repaints. That code can be taken from
> libart if we
> > > don't want the libart dependency. It might be nice when
> intergrating
> > > with bonobo and GnomeCanvas which use this.
> >
> > It is probably a good idea to use libart from the beginning. The
> > instability in the AA GnomeCanvas is not due to libart in
> most cases, but
> > the GnomeCanvas code.
>
> Maybe, maybe not. GdkPixbuf was changed to remove the libart
> dependency
> because the Gtk+ people didn't want to add a new dependency. Maybe we
> should be wary of dependencies too.
>
> > > * Should we allow CanvasItems to be GtkWidgets? This would mean
> > > subclassing from GtkLayout with all its hocus-pocus
> mapping and unmapping
> > > for scrolling. It means that some stuff will be hard to
> implement too,
> > > like affine transformations (or just scaling, see below)
> of generic
> > > widgets, or rendering to non-gdk renderers. Another
> problematic thing here
> > > is that GtkWidgets generally cannot be displayed at the
> same time in
> > > different views.
> >
> > I don't know. We should at least aim to make it possible
> to add a Bonobo
> > Embeddable to the canvas. I don't know how much adding of
> other widgets
> > is used in the GnomeCanvas in cases where multiple views are used.
>
> Yeah, that would be good. Might be a bit hard though.
>
> > > * The renderer. Ahh, this is cool stuff. This is actually
> the best part of
> > > Dia in my opinion. It can be better though. First of all
> it should be a
> > > GtkObject, with ref-counting and all, in the name of
> Gtk-ization. If this
> > > is done well it could be used by other parts of Gtk too,
> as an abstract
> > > printer interface etc.
> > >
> > > It should support:
> > > Color specification
> > > Line attributes (dash, caps, joins)
> > > Fill styles
> > > Lines, polylines, polygons, rectangles
> > > Ellipses and arcs (axis-aligned, if you need general,
> use beziers)
> > > Bezier curves, (lines and filled)
> >
> > Do we handle these directly, or let an application cache a vpath
> > created from an ArtBPath and use the polyline/polygon
> rendering routines?
>
> That is up to the renderer:
> shape = renderer->create_bezier(renderer, ...);
> renderer->draw_shape(renderer, shape);
>
> The shape object here can contain the polygon or the bezier points,
> depending on if the render target can do real beziers (i.e.
> postscript)
>
> > > Image rendering (based on GdkPixbuf)
> > > Rotated text rendering, (pixmap rotation hack or whatever in Gdk)
> > > Text extents measuring
> >
> > Should the text extents depend on which renderer you
> choose? It is not
> > clear to me that this is useful.
> Well... Font extents are difficult stuff. You need the exact font
> metrics, which can differ for different renderers (Gdk vs. PS) because
> they don't use exactly the same font.
>
> > > All strings in UTF-8, font selection using Pango (A must
> for i18n)
> >
> > Having good font handling is a must. If Pango isn't yet
> ready, we can use
> > gnome-print's GnomeFont stuff in the mean time. It handles
> the variable
> > size fonts and metrics problems
>
> I haven't looked at gnome-print, i really should.
>
> > We definitely need some way to store some data for each
> canvas item keyed
> > to the view (eg. we probably want to save a scaled pixbuf
> for each view),
> > which can be thrown away when the view changes.
> Yeah, that would be nice.
>
> > We may as well start putting together a bit of code for the new
> > canvas. We should put it in a new module on CVS, in case non dia
> > developers want to help. I am not sure what to call the new canvas
> > objects though. Probably not GtkCanvas at the moment --
> use some other
> > name, and if it gets accepted into gtk+, change the name.
> This is what
> > Havoc did with the new text widget for gtk+-1.4 (I think it
> was going by
> > the name FrooTkxt).
>
> Yeah, someone come up with a name. Names tend to stick around
> though, so
> watch out. I'd love to work on the renderer stuff.
>
> I'm going away tomorrow, for a few days, and the next week I'm going
> skiing, so i can't help out right now.
>
> Btw. There was some discussion about model/view canvas stuff
> in the gnome
> components mailinglist, check it out.
>
> / Alex
>
>
