> -----Original Message-----
> From: Arjan J. Molenaar [mailto:[EMAIL PROTECTED]]
> Sent: donderdag 20 april 2000 9:29
> To: '[EMAIL PROTECTED]'
> Subject: RE: New canvas??
>
>
> 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?
... never mind...
> 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
> >
> >
>
