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


Reply via email to