Re: GUADEC 2008 GTK+ Meeting Minutes
- From: "Colin Walters" <walters verbum org>
- To: "Tim Janik" <timj gtk org>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: GUADEC 2008 GTK+ Meeting Minutes
- Date: Wed, 23 Jul 2008 22:45:05 -0400
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. 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.
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.
2) Finish GObject introspection - People continue to write code in C, bindings authors continue to fall farther behind.
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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]