Re: GTK+ canvas?

[Havoc Pennington <hp redhat com>]

Gustavo J. A. M. Carneiro wrote:
>   It seems this HippoCanvas has no model-view split, yet I remember you
> designed GtkTextBuffer/View with model/view.  Do you consider model-view
> unimportant, or simply just got "prioritized away"?

I'm not sure, I'd have to look at GooCanvas or experiment myself. It's 
certainly not required for Mugshot so I didn't think about it too much.
I can definitely imagine it complicates things. On the other hand, 
conceptually for e.g. HippoCanvas it just means passing the 
HippoCanvasContext to the size and paint methods, instead of having 
set_context(), and probably moving the allocation to be 
context_get_allocation() instead of storing it in the item.

For textview the reason we did it is to support e.g. split buffers in a 
programming editor (like emacs C-x 2 or whatever)

A possible use-case for it with a canvas is something like a magnifier 
item that is a view of another part of the canvas. But, how often do you 
really need stuff like that.

> > - Along the same lines you can also think of a canvas as an alternative 
> > to Flash or HTML/CSS, two systems many programmers will be familiar with.
>
>   Don't agree so much.  I would say that an HTML widget could be built
> on top of a canvas, but a canvas IMHO should be something lower level
> than HTML (can't comment about Flash).

A full HTML implementation certainly shouldn't be in a base canvas, but 
there's large overlap in when you might use a canvas or an HTML widget I 
would say. (Well, I know it's true for us - we were using an embedded IE 
on Windows and will now use a canvas thingy.) HTML also has some of the 
same advantages over gtkwidget/gtkcontainer that a canvas would have, 
it's easier for doing custom displays.

If nothing else, a baseline metric of canvas quality is "would it be 
easier to do the same apps in HTML" - if yes, then the canvas would seem 
kind of lame to me. It's not like CSS is all that good.

> > , so having a markup language 
> > as an integral part of a canvas design is of interest.
>
>   Markup in the text item sounds fine.  Anything else sounds like
> reinventing HTML.

Is Glade reinventing HTML? ;-)

I don't think there's a problem with being HTML-like because there is no 
reasonable way to use HTML in many of the contexts where you want to use 
the canvas. In fact, if using HTML was practical for Mugshot we would 
have used it, but unfortunately there is no plausible way to use it 
that's cross-platform and lightweight enough to use in something like a 
tray icon.

To me an HTML widget basically _is_ a canvas, and canvas heavily 
overlaps HTML/Flash, except that the canvas works well in a desktop app 
and HTML/Flash work well inside a browser.

GtkHTML was used for lots of custom display / canvas like purposes back 
in the day IIRC.

>   IMHO a canvas in gtk+ should not go too far.  I'm not saying an HTML
> widget would not be good to have in gtk+, but HTML/CSS and canvas are
> two separate things; HTML/CSS can be built on top of a canvas, in
> principle.

There's a lot of stuff in HTML that a canvas doesn't need, but the basic 
"tree of graphical nodes" and "layout model" and "styles" aspects of 
HTML are shared with any useful canvas...

Havoc