Re: GTK+ canvas?

[Soeren Sandmann <sandmann daimi au dk>]

Havoc Pennington <hp redhat com> writes:

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

I don't think a Tetris or an Inkscape or an Abiword widget is
generally useful.  Things like that always end up being specific to
the application. On the other hand a button or a label is clearly
generic enough to be useful in almost all applications.

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

What I am claiming is that GnomeCanvas failed on at least two counts:
(1) it didn't really have the required features to do interesting
UI's, and (2) its retained mode requirement is a huge impedance
mismatch for applications that need to keep a complex and dynamic
display in sync with an application data structure.

Note that GTK+ itself is _also_ a failure wrt. to (2). Interesting
applications invariably draw their main display themselves; they don't
build it out of GTK+ widgets. This means there is hard and boring
code, such as scrolling and mouse input and drag and drop, that gets
reimplemented in every application.

So what I am saying is that any new extra-nifty GUI toolkit should at
least consider whether insisting on retained mode for all elements is
necessarily the right model. And also whether the traditional
model/view split where the model is forced to implement a special
interface, is really a good match for applications.

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

My point is that flash/html-like custom UI is simply not convenient to
do in _any_ toolkit, extra-nifty or not, and that adding more and more
niftyness is really just a workaround for the fact that the
application can't just draw - it is constrained to set properties on
widgets.

Note that I am not against implementing an extra-nifty toolkit inside
a GTK+, and also not against looking at a canvas as a parallel layer
to GDK. There is tons of stuff in GDK that is basically obsolete by
now. I just don't think "niftier widgets" is the answer to "how do we
make more dynamic and interesting UI easier to create". But it may
well be the answer to "GTK+ is getting long in the tooth".

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

Another thing that is worth considering is whether composite is really
all that great. A lot of the features of composite could be
implemented on the client side without any (or much simpler) X server
changes.

Instead of creating a toplevel window, application could simply create
a pixmap, then notify the window manager whenever that pixmap was
ready to be published. The benefits here are

- no X extension with unclear semantics needed

- applications are explicitly aware that they are drawing to an
  offscreen area which means they can do things like scrolling without
  worrying about intermediate steps.

To do tear-free compositing, the X server may need to provide a
copy-on-write copy mechanism for pixmaps, but that is both simpler and
semantically much more well-defined than Composite/Damage.

I should say that the idea of simply drawing to pixmaps on the client
side was Adam Jackson's, not mine.


Soren