Re: GTK+ canvas?

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

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]