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
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
