Re: GTK+ canvas?
- From: Damon Chaplin <damon karuna uklinux net>
- To: gtk-devel-list gnome org
- Subject: Re: GTK+ canvas?
- Date: Tue, 19 Sep 2006 13:07:02 +0100
So how are we going to decide on a list of requirements for a canvas?
I think there seem to be two main use cases:
A) DTP/Graphics apps that want a canvas for the main document.
(A model/view split, device-independent layout, zooming & printing
are important here.)
B) Flashy user interfaces.
(Support for embedded widgets is useful here.)
Can we even agree on 2 fundamental requirements:
1) Should the canvas & items have a model/view split?
- It is very useful for (A) above but makes (B) awkward.
2) Should it support embedded widgets?
- Useful for (B) but will probably always have limitations
(either you can't stack items like in GnomeCanvas, or you can't
zoom or transform widgets, or you can't print widgets).
It is also difficult to fit into a model/view architecture.
If there was a definitive list of required features for a GTK+ canvas
I'd try to support them in GooCanvas if possible. But it still all seems
a bit hazy to me.
PS. Here's a list of the current GooCanvas features:
o Model/view split.
o Uses interfaces for items & views.
o Basic items - rect/ellipse/polyline/text/image/group.
o Path item, using SVG path specification strings.
o Layers/stacking order with raise/lower functions.
o Styles - line width/cap style/join style/dashes/colors/fill patterns.
o Affine transformations for items (& views) - rotations/scales/skews.
o Event handling - button/motion events, "pointer-events" like SVG.
o Grabs - support for pointer & keyboard grabs.
o Keyboard focus traversal.
o Accessibility (title & description properties and hierarchy stuff).
o Printing (output to a given cairo_t).
o Item visibility setting - on/off/above zoom threshold.
o Simple animation.
o Scalable - support for thousands of items over a large canvas area.
o Support for different units - pixels/points/inches/millimeters.
o API docs.
] [Thread Prev