Re: GTK+ canvas?

Soeren Sandmann wrote:

I think retained mode is interesting when the objects have two

  - Does the object contain state that the application doesn't *care*
  - 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.


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