Fascinating thread: GtkCanvas requirements

A discussion has been taking place on gtk-devel-list this month as a number of GNOME hackers discuss the requirements that a future GtkCanvas widget might have.

A canvas widget is all about drawing; while many requirements for customized user interface don’t need such a thing (because you can always pack together various other widgets into a new composite widget that achieves the effect you’re aiming for), in the more general case you need to start drawing lines and shapes — and this is where people usually run into trouble. For one thing, drawing of any kind is generally fairly complicated, but most of the pain comes as a result of drawing things at bitmap (pixel by pixel) level — later on, anything that needs to scale (zoom in, zoom out) the resultant pixmaps is bound to look terrible.

That, of course, is what vector graphics are all about, and so the obvious thing is to use such mechanisms to do the low level drawing. For a while now, we’ve had an outstanding vector drawing library in freedesktop land, and that’s Cairo. And while Cairo is already used for quite a number of things in GTK, and while there are various higher level Canvas widgets floating around, the most interesting part of the whole thread to me was when it was pointed out that if a new GtkCanvas (in the form of a slightly lower level artifact) was used to render all the [standard] Widgets provided by GTK, then suddenly the zooming, resizing, and other warping that accessibility tools need would all be fait accompli in the toolkit itself. And it’s not just accessibility: someone pointed out that if we made it this far, then at last we’d have high resolution screen shots to paper which would make printed documentation look stunning.

Fascinating thread.

AfC