>> as a history, GtkCanvas is essentially the same as the Gtk+-1.2 >> GnomeCanvas, but available in a separate package and with functions >> renamed accordingly. GnomeCanvas used to be available only as a >> part of the Gnome libraries. >> >> the Gtk+-2.0 version of GnomeCanvas is available as a separate >> package, which does not depend on anything but Gtk+-2.0 and libart >> (which is one of the canvas backends in 2.0 as well). So, I know >> why paul pushes GtkCanvas, but people looking for a maintained >> package and don't mind Gtk+-2.0 (which is very stable) should take >> a look at the GnomeCanvas instead. > >Aaargh! This is exactly what I don't like about these sort of >solutions. > >Why is the "Canvas API" part of either a toolkit or a desktop >environment? Why do they have different (even if only slightly so) >APIs?
1) GtkCanvas is a "backport" of the GnomeCanvas so that it was free of the "desktop-isms" of GnomeCanvas. However, since the Gnome crew realized the error of their ways, they removed all such references to the rest of Gnome themselves. The result is still considered to be part of Gnome rather than GTK, mostly for political reasons. But from a technical point of view, it has the exact same dependencies as GTK+ itself, so its usable as a standalone library without any part of Gnome not already used by GTK+ (ATK, Pango, glib). 2) its part of a GUI toolkit because thats what it is. Unless you create an entire toolkit around the idea of a Canvas-like object, the Canvas-like object is just another widget in the toolkit. it was never really part of a desktop environment. it started life in Gnome because of politics rather than technicalities. --p
