Hi, On Fri, Jun 6, 2008 at 5:34 PM, Paul Davis <[EMAIL PROTECTED]> wrote: > Moreover, I think its worth noting (again) that while Clutter and the > sketch of "scene graph central to GTK" are both very cool (with Clutter > being here and now, and the scene graph stuff merely imagined), canvas > widgets do not need to aspire to this level of <adjective> to be useful > in a wide variety of applications. Although GTK with a Clutter-like (or > even just Clutter) API at its core would be awesome, GTK with a > supported canvas widget would suit me and many other developers for > quite a while yet. >
I agree that these are separate goals, and in fact while I wrote that scene graph manifesto slide deck, I (with Owen and others) also wrote one of the currently-in-use adequate/useful canvases (HippoCanvas) because we needed it to get stuff done. I think there are at least some issues with the "short-term adequate canvas plus long-term scene graph separately" solution, though. Here are some of thoughts about 'doing both': 1) there aren't really any volunteers to do either one ;-) 2) there isn't a reason that the adequate/useful canvas needs to be in gtk, except for the wish for "supported," which basically means "get existing gtk maintainers to review and make sane the API, and fix bugs in it," but those guys really don't have extra bandwidth... some other bugs would suffer, or the canvas would. I'd be much more sold on canvas in gtk if it came with a maintainer who was prepared to join the gtk team for the long haul. 3) the "scene graph" concept really does need to be in gtk, it's basically a gtk refactoring/enhancement - "make gtk itself do what people want a canvas to do" - the idea is that a canvas is an alternate widget system with distinct pros and cons vs. GtkWidget, so the really great solution is to do one widget system with best of both worlds 4) the "adequate/useful short-term canvas" has serious problems with defining its scope and purpose, which have been apparent in every thread about a canvas, and are apparent if you look at the different takes on canvases out there (gnomecanvas, clutter, goocanvas, hippocanvas, html widgets, pigment, etc.). They are not "the same thing" in the way all text entry widgets are "the same thing." It isn't clear which of several purposes a canvas has - use hardware accel, support specialized graphics, be a less-limited / more-freeform widget system, be a convenient way to draw manipulable diagrams, I don't know (past threads tried to sort these out or create taxonomies, don't remember them all). 5) the consequence of 4) is that the canvas tends to have serious scope creep and seriously overlap with stuff the GTK core (GtkWidget widget system) already does (or should do), which makes the maintenance problem in 2) much worse, and also makes it very hard to get consensus on which canvas to include or start from, and how to review the API, and evolve it from there. Anyway, to me my (relatively recent) theory is that the only clear and crisp way to "put a canvas in GTK" is to just fix the GTK core so you don't need a canvas as a workaround for its limitations. That's the essence of the "scene graph" theory. Otherwise, I just can't figure out what the line between the canvas and GtkWidget _is_, and it seems to me they would gradually converge until you pretty much had two widget systems in one library. Which would be unmaintainable and hard for people to learn and just generally sucky. I'm kind of a believer that the right path for an adequate/useful standalone canvas is in its own library, but with a decent maintainer and a stable ABI. And if there's no maintainer, or the ABI isn't ready to freeze... _that_ is the true problem, not inclusion in GTK or not. I also get the sense that there's genuine demand for some of the different takes on a standalone canvas, I mean, Clutter and HippoCanvas for example are very different in many ways. Which to include? Finding people who can maintain an API at a high level of quality is very hard; even when there's a talented developer, it takes quite some time hacking on something like GTK to absorb the knowledge and experience that goes into making GTK as stable and well-designed as it generally has been. I bet if someone did show up with a well-maintained canvas that app developers seemed to be using because it met real needs, with a crisp and clear purpose that defined its scope, there might be willingness to incorporate that in GTK if the maintainer wanted to work on writing it up, discussing with gtk maintainers, and addressing review comments... but I also think there wouldn't be all that much demand to incorporate it in GTK, if it were truly well-maintained already. I don't know, it's a complex problem. But on the other hand it's probably only one very dedicated and productive developer away from a solution or solutions. Havoc _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list