Re: GTK+ canvas?

[Havoc Pennington <hp redhat com>]

Soeren Sandmann wrote:
> I think retained mode is interesting when the objects have two
> properties:
>
>   - Does the object contain state that the application doesn't *care*
>     about. 
>
>   - Is the object generic enough that many applications would need it

That amounts to saying "does the object do more than just draw?" doesn't 
it? I mean, if a canvas item adds any value or prebuilt functionality, 
then it will be an abstraction (hide state or at least code that the app 
doesn't care about) and it will be of general enough interest to be 
worth having in a library.

> So I'd be careful about only having a retained mode 'canvas'; you risk
> ending up having to write tons and tons of special purpose 'canvas
> items', not matter how flexible you make the canvas. 

Since I'm claiming a canvas is just an extra-nifty GUI toolkit, this 
isn't surprising ;-) I'd expect a canvas to have essentially all useful 
widgets found in GTK. The simplest way to accomplish that is to allow 
embedding a GtkWidget as a canvas item.

If someone were starting a toolkit from scratch, of course they wouldn't 
want this canvas items vs. widgets distinction, but in the real world it 
may be very practical to evolve GTK by building a canvas "around it" and 
thus avoid having to rewrite entire apps and avoid getting bogged down 
writing the difficult widgets such as window, entry, treeview, textview, 
file selector, etc.

The canvas could have "native" versions of the simplest building blocks 
of a custom display (text, images) instead of using GtkLabel, GtkImage; 
but doesn't need to replicate the interactive widgets as long as it can 
just use the existing ones.

Widget embedding could be done in two ways, probably moving from one to 
the other over time:
 1) a CanvasWidget canvas item, that can embed any widget, possibly with
    certain limitations or quirks
 2) implementing the CanvasItem interface in the widget itself, allowing
    the widget to be fully "canvas enabled" if it wants

2) can be done widget-by-widget as it's useful, I would think.

Going over the list of widgets, I'd say Label, Image, and the layout 
widgets are just about the only ones worth having as native canvas items.

A premise of all this is that building flash/html-like custom UI is a 
reasonable thing to do; I happen to think it is in lots of cases:
 - games
 - sufficiently consumer-ish applications where fun trumps consistency
   (think about Konfabulator/Dashboard for example)
 - non-desktop platforms (set-top box, handheld device, kiosk, OLPC)

Again I think it's sort of interesting to think about the canvas as 
alongside GDK in the dependency graph instead of above it; that is, 
think of the canvas as a way to abstractly define a scene graph and 
interactions with it, and think of GdkWindow as one "input/output 
device" - so GDK is responsible for the idea of multiple windows and a 
desktop environment or window system surrounding said multiple windows, 
the canvas is responsible for defining the scene graph that goes in a 
window, and GTK is responsible for a collection of items (aka widgets) 
typical of "standard desktop applications"

There are definitely some practical annoyances here (e.g. the list of 
keysyms lives in GDK while in this model it's needed by the canvas 
also), but it could be the right way to think about things, even if it 
isn't quite a good idea in practice.

Havoc