Minutes of the GTK+ meeting at GUADEC

[Kristian Rietveld <kris gtk org>]

Hi all,

We continued the trend of having GTK+ meetings in person at major
conferences and I continued the trend of writing up notes ;)  Please
find below the notes I took during the GTK+ meeting at GUADEC in
Birmingham.  Corrections are most welcome, as always.

My apologies for sending out these minutes so late, being on vacation
right after GUADEC didn't really help :)


regards,

-kris.


----------


GTK+ Meeting, 16 July 2007, GUADEC 2007
---------------------------------------

Final agenda:

1. Opening
2. Agenda
3. Current state of 2.12
4. 2.14 features and schedule
5. 2.x situation, 3.x road map
6. GNOME Foundation funding
7. Ruleset for compatibility issues
8. Question round
9. Closing


Notes:

1. The meeting was opened at 10:32.


2. During the meeting point 6, "GNOME Foundation funding", was added to the
agenda.


3. We've tried to get an API frozen release out on the Friday before
GUADEC, unfortunately this didn't work out.  We will release an API
frozen 2.11.6 once the network at GUADEC will start working.

When finalizing the release schedule a few weeks ago, we promised to
release 2.12.0 during GUADEC or the week after.  Since the last API bits
only went in last week, we don't think it's a very good idea to put
out 2.12.0 next week.  Obviously it is good to have a few weeks of bug
fixing between the first API frozen release and the final .0 release.

The upcoming GNOME release is entering API freeze on August 30.  We think
that an API frozen release this week and a guaranteed final .0 release
before August 30 should not be a problem for GNOME.  Right now we will be
targeting mid-August.  The time between now and mid-August will be used for
testing, more bug fixing and finishing the documentation for the new
features.

GLib 2.13 is basically feature complete and ready at this point, we decided
to release GLib 2.14 as soon as possible, so earlier than GTK+ 2.14.  Pango
will be following the GNOME release schedule.


4.  We asked the developers in the room to come up with possible features
for 2.14, with the requirement that these features will be finalized and
ready in the coming months.

 - GVFS, the API is there, Alex is not fully confident in the API yet and
   wants more testing and review first.  If we start with this on time,
   this shouldn't be a problem to get into the 2.14 release.
 - XRandr SoC, work is being done on GTK+ support for the new version
   of the XRandr extension which allows for dynamic changes (like appearing
   and disappearing monitors, and changing their geometry).
 - Tap-n-hold, the patch is mostly ready but depends on the cursor animation
   API/API for creating animated X cursors.
 - Offscreen rendering.
 - Height-for-width, natural width and baseline sizing.  There is code
   already, it just needs to be finalized.
 - Being able to implement file chooser dialogs outside GTK+, so
   basically making the GtkFileChooserIface public.  The consensus was that
   a proposal will have to be sent out to the list saying which parts of
   the interface should be made public.
 - File type selector, for the "save" version of the file chooser.

GUnique was brought up as a possible feature for 2.14, a small discussion
about its usefulness as "stand-alone" feature emerged.  It doesn't make all
that much sense without an application window class, subsequently an
application window class doesn't make much sense without session
management.  Basically, you start questioning whether you want to introduce
a document based window/application model (like Cocoa has) -- getting this
done requires a good amount of work and discussion because it possibly
takes over a lot.  In the end we concluded that all of this would be more
useful as a higher level library including all these pieces.


With regard to release schedules, we seem to have fallen into some kind of
pattern.  We start planning at GUADEC try to aim for January, and then slip
until we get our act together for GUADEC ;).  It seems reasonable to try to
release 2.14.0 around the next GUADEC (however, we do not exactly know when
that will take place).  This is a period of about one major release every
12 months, which falls together nicely with one major GTK+ release every 2
major GNOME releases.  Though we want to freeze the API a little earlier in
the process and look at the GNOME release schedules to make this fit in
nicely.


5. Up next was a discussion about the current state of 2.x and an attempt
to come up why exactly we need 3.x.  It has been said that GTK+ 2.x as it
stands right now is a nice and capable toolkit, but continuing this way is
a "dead-end".

Which parts are exactly a "dead-end"?  Which are not?  What can we actually
still integrate into the 2.x branch without breaking compatibility?

Right now the complexity of the core is very high.  If you keep on
extending and replacing subsystems with another (eg. like we replaced
GtkTooltips with GtkTooltip), it is not always going to make the toolkit
easier to both use and maintain.  GTK+ could end up looking like Motif: old
and very big.

It was noted that Qt breaks compatibility during every major release;
though most of their customers ship the Qt libraries with their
applications and they try to simplify the migration between two major
releases with some compatibility layer.

So, at some point, you basically want to more or less start over, maybe
redefine the target (only target the desktop, or only target specific
use cases on the desktop, etc).  One approach to this might be to have a
"prototype" application with new technologies, which would end up driving
development of a "new GTK+".  It doesn't even have to use GTK+, but can use
the core libraries.  At some point a kind of stack will be built on
existing libraries, like GObject, Pango, etc; this stack could be a
starting point for a new GTK+.  This process can happen completely in
parallel with the current development on the 2.x series, but does need a
good organizational effort.

What do people actually want to experiment with for a new GTK+?
 - No subwindows in GDK.
 - No C structures exposed in the interface.
 - Why do we have a distinction between canvases and widgets?  Could we
   "merge" this?  What will be possible if we do?
 - Start by looking at the tools to create applications, design the
   framework of the toolkit after that.
 - Start looking from an application perspective; how do we want to control
   our application and how should it appear/behave?  Look into supporting
   things like multitouch, nicely animated user interfaces.  Think about for
   example "what will evolution want to do in 5 years from now?".

People who are interesting in new things like this will experiment and try
it out.

It is clear that there are enough ideas and enough people who would love to do
some experimenting.  Now, how do we get serious?
 - Get people to experiment, don't feel threatened by "other" people doing
   these new things.
 - Don't point at a GTK+ 3 branch and say that this is going to become to
   "next big thing".  Because experiments can fail, the entire branch could
   turn out to be some failed experiment.
 - Hopefully those experiments will end up being libraries being used
   throughout the stack by applications that need it.  At some point the
   GTK+ team can start "picking" such libraries and design to start
   maintaining and releasing it next to the GTK+ 2.x releases.
 - As said earlier, pick an application to "drive" these developments, use
   all new technologies, make it form an example of "future applications".

6. The GNOME Foundation has offered to raise awareness of the current
maintenance problems among companies.  Multiple companies seem to be
interested and would probably contribute money.  How could GTK+ use
this money?

 - Have the foundation hire a core hacker -- but hard because all core
   hackers are already employed by companies.
 - Pour money into a GTK+ supporting company.
 - Use the money to setup a small meeting like GIMPCon.  This could
   possibly be a hack week or weekend where just the core hackers come
   together to discuss problems, work on new API, fix bugs, in general get
   things done.  Apparently weeks like this have proved to be very useful for
   the GIMP.
 - Put money into people developing these "new and cool" technologies.
   This probably not a good idea, since it will most probably make people
   doing the "boring" maintenance job quit.  See Debian for related
   experience.
 - Sponsoring conference travel for people who can't afford themselves.

7. Right now we are really hitting the limits as to what we can change
without breaking compatibility.  The rules on what kind of changes are
acceptable and which are not with regards to compatibility are not very
clear, would it be good to set up an official "ruleset"  for this?

An issue with this is, if you do the change which is allowed by the rules
and some application (doing valid things) breaks, is this okay?  People
agreed that such breaks would still have to be fixed and defining a proper
ruleset will be hard.

Most decisions are currently being made by looking at impact, valid
use cases for the code, experience, etc.  It makes sense to publish some
kind of "contract" which clarifies what kind of measures we are currently
using the make these decisions.

8. Question round

There was a informal meeting on theming yesterday.  What was the outcome?
Apparently there are really two points of view:

  - The artistic point of view: lots of ideas, don't know whether things
    are possible at all.  Some of those ideas are indeed not possible
    with the current GTK+.
  - Core developers point of view: we don't know the full wish lists of the
    theme developers.

The solution here is to improve communication between both camps.
Yesterday a start was made on working on a wish list, this will be
published as a GtkTask and there are several people who want to work on
this already.  Hopefully this will result in a wiki page with the wish
list.


Has there been any progress on the OpenGL integration?

Somebody has brought GtkGLDrawingArea back to life, but the consensus
among the core developers is that a "cairo-like" approach using contexts
would be better.  There hasn't been any (visible) progress on the latter.


How is Webkit doing?

There are a few people working on the GTK+ WebKit port.  It was suggested
to maybe bringing the versioning and release schedule of this port and GTK+
inline, and "bless" the WebKit port as GTK+'s official HTML widget.


9. The meeting was closed at 12:17.


9. Closing