On Tue, 18 Apr 2000, Alexander Larsson wrote:
> Good idea.
>
> As I said, I've been doing some thinking about this some time ago (but
> then I got distracted hacking gradients into libart...). I have some ideas
> and stuff scribbled on a piece of paper here. I thought i might type it in
> to generate some ideas.
>
> Stuff to think about when (re)designing the Dia canvas.
>
> * Model/View separation. The gnome-canvas does this in a totaly different
> way, there each Gnome-canvas widget is a view of an app-internal
> model. I'd like both the model and view to be supported by the Canvas
> widget.
>
> * It should be much closer to Gtk+ than the Dia canvas is, meaning all
> Canvas items are derived from GtkObject, using signals instead of
> function-pointers etc. The idea here is to create GtkCanvas,
> GtkCanvasItem, GtkRenderer etc that can go into Gtk+ in 1.4 or later.
That was one of the plans. It should simplify the code substantially.
>
> * Hierarchial grouping of objects must be a core feature.
>
> * Direct support for undo/redo shouldn't be in the canvas, but it *must*
> be possible to add support for state change saving or suchlike so that
> undo can be implemented by the application. Basically, we must
> think about it in the design.
Performing a lot of manipulation through the GtkArg system makes this
pretty easy (similar to the current dia properties code).
>
> * 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.
>
> * 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.
>
> * The Canvas must handle the pixel to world coordinate mapping. This means
> that each view can have different zoom levels etc. This obviously trips up
> embedded GtkWidgets...
>
> * 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?
> 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.
> 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
>
> The current libart renderer in Dia is horribly ineffective. This is due to
> the current renderer interface. For each primitive rendering operation the
> renderer must calculate a lot of data, which it then throws away, beacause
> there is no way to store it for the next time. This would be solved by
> using an API which lets you create "shapes" that can then be drawn by the
> renderer. (Interested parties can glance some at the Java 2D spec for
> inspiration.) Basically this means that you do something like:
>
> shape = renderer->create_bezier(renderer, ...);
> renderer->draw_shape(renderer, shape);
>
> The shape object here is specific to the renderer it was created in, and
> internally it contains shape-data and pointers to rendering-functions that
> draw_shape calls. Using this the libart renderer can cache SVP:s, leading
> to much better performance in the aa renderer.
>
> There are of course helper-functions for drawing stuff once, but they
> should not be used in time-critical code which can cache the shapes
> between repaints.
>
> Ugh, enough of my ravings. What do you think?
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.
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).
>
> / Alex
>
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
