canvases in 3.0 [was Re: Steps to get to GTK+ 3.0]

["Havoc Pennington" <hp pobox com>]

Hi,

On Fri, Jun 6, 2008 at 5:34 PM, Paul Davis <paul linuxaudiosystems com> 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