Re: GUADEC 2008 GTK+ Meeting Minutes

[Paul Davis <paul linuxaudiosystems com>]

On Wed, 2008-07-23 at 22:45 -0400, Colin Walters wrote:
> On Wed, Jul 23, 2008 at 11:55 AM, Tim Janik <timj gtk org> wrote:
>         
>         People wonder whether a GLib 3 is planned and whether the
>         entire library
>         stack must be parallel installable.  A GLib 3 is most probably
>         planned, as
>         there are things in GLib that might make sense to seal as
>         well.  This more
>         or less implies that the entire library stack will have to be
>         parallel
>         installable.  
> 
> GLib 3?  What conceivable changes to GLib are outstanding that would
> merit API/ABI breakage?
> 
> I just wanted to mention here again the alternate GTK+ 3.0 plan:
> 
> 1) Integrate a canvas.  

great idea.

> Here's an example of real world program almost certainly on your
> desktop that needs it:
> http://blogs.gnome.org/dcbw/2008/06/11/great-taste-less-filling/
> That mockup really needs a canvas that has features like painless
> GtkWidget embedding, powerful
> styling and layout.

That mockup absolutely does NOT need a canvas.

> We could take the approach of having app authors pick one on their own
> (I know I would suggest hippo-canvas to Dan just because Owen's been
> doing such good work on it), but it certainly would be a lot better if
> the canvas was being driven forward the GTK+ core team.

Not sure I agree with that. The core team seem to have a pretty great
grasp of what a canvas *should* do, but they also have a huge reluctance
to commit to anything that doesn't get really close to their ideal
vision. Out in app-devel land, most of us have used canvases (Gnome,
Goo, Hippo, ccc, Dia and more) that are not perfect but enable us to get
stuff done reasonably, even if not ideally.

> One possible approach with the canvas would be to have parts of GTK+
> that are not API/ABI stable - perhaps they require a Havoc-style 
> "#define GTK_I_WANT_A_CANVAS 1".  Once the canvas is stable we declare
> it GTK+ 3.0 from a marketing point of view (but don't change the
> soname), like what GNOME is doing with GNOME 3.

Not a bad idea, except that when an app is distributed that WANTS-A
canvas to a system where GTK was built with FORGET-A canvas, what
happens?

>