Re: GTK+ canvas?

[Havoc Pennington <hp redhat com>]

Hi,

Damon Chaplin wrote:
> 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.)

My basic feeling is that a) should be a separate lib and b) should be in 
gtk, but both are potentially useful. a) might or could be a little 
different api as Soeren was talking about, I don't know. b) is the one I 
have the most experience with.

> 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.

For b) I don't think it's very important.

>  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.

I think it's essential for b). The limitations there are pretty possible 
to overcome; there are patches like Alex's to allow redirecting the 
drawing of legacy widgets, which is already enough to transform and 
print them (essentially, as bitmaps).

But also if the CanvasItem is an interface, widgets can implement it. 
For widgets that do, you don't have to use a CanvasWidget adapter item, 
you can just dump the widget itself into the canvas.

> 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.

You know how open source is ;-) what are the chances of getting anything 
definitive! At best someone can keep summarizing the conversation and 
try to clarify the options as you did here with a) and b).

> PS. Here's a list of the current GooCanvas features:

My .02 on the important, nice, could-live-without, and missing here, 
assuming canvas type b).

important:
>  o Uses interfaces for items & views.
>  o Layers/stacking order with raise/lower functions.
>  o Affine transformations for items (& views)
>  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 Basic items - text/image/group.
>  o Scrolling.
>  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 API docs.

nice:
>  o Path item, using SVG path specification strings.
>  o Styles - line width/cap style/join style/dashes/colors/fill
>  o Zooming.
>  o Support for different units - pixels/points/inches/millimeters.

could live without:
>  o Model/view split.
>  o Basic items - rect/ellipse/polyline

missing (from your list anyway), some important, some nice:
o Widget embedding
o Layout
o Does not include gtkwidget.h in the canvas item interface, only in 
canvas widget and canvas widget item, i.e. canvas item tree can go 
'alongside' gtk conceptually and be used to paint to a non-gtkwidget
o Fix gtk's container-itis with the layout (e.g. HippoCanvas now has 
padding-{left,right,top-bottom}, border-{left,right,top-bottom}, xalign, 
yalign, border-color, background-color for all items)
o Inheritance of certain properties from parent items (e.g. font), i.e. 
cascading styles
o Behaviors (draggable, raisable)

Havoc