GTK+ Meeting, 25 June 2006, GUADEC7
-----------------------------------

* 2.10 is basically done, we are aiming for a release next week.

* Tommi asks whether the GTK+ development/maintainer team is big enough.
  Matthias and Tim both answer that the team has been too small for the last
  few years, everybody else seems to agree.

* Planning 2.12, possible new features:
  - Canvas, and we need off-screen rendering for that.
     # At least 3 different candidate canvases around.
     # Some ideas from Soeren; immediate mode, callbacks.  He will write up
       his ideas and send it to the list for discussion.
     # Defining the feature set for a canvas is really difficult, though
       most people agreed that GnomeCanvas does cover most of the features
       needed by general applications.
     # Might want to look at the new canvas in Qt 4.1.
  - Introspection
  - GtkBuilder, the libglade integration into GTK+.
  - The new tooltips API.
  - Maemo.org patches
     # Menu patches,
     # Input method,
     # Tap and hold.
  - International calendar support
     # GLib patch is about ready,
     # After that the GTK+ widget (GtkCalendar) needs some fixing up.
  - Support for editable multi-line labels, probably by extending GtkEntry.
  - libsexy cherrypicking
     # Support having an icon in the entry.
     # Input masks.
  - Recent file code updates
     # GtkRecentAction.
     # GtkFileChooser integration.

* Matthias continues on Tommi's previous question on maintenance, mentioning
  the OS X backend.  Micke and Richard explain that the backend is mostly
  working, but does need some bug fixing.  It's marked as still experimental.

* The file chooser API does have some issues.  For example the backend API
  is private, and getting the model from the file chooser dialog is impossible.
  Also the code for supporting the pluggability of the UI does not work/has
  not been tested at all.

* We decided to target the GTK+ 2.12 release on January '07.  This should give
  us enough time to put all new features in.  If we decide to include a
  canvas with GTK+ 2.12, we might have to depend on a new release of Cairo.
  According to Carl Worth the next releases of Cairo are pretty much "open".
  They will probably focus on performance for the next release.  Making a new
  release for supporting some special canvas features should be feasible.

* We get interrupted by some guys of the board.  Jeff speaks about having the
  GTK+ project join the GNOME foundation.  The foundation can provide
  help to the GTK+ project with financial and administrative tasks.  It has
  been doing this for the GIMP project already, which has been working fine
  so far.  The foundation does not get any influence on the technical
  decisions made by the GTK+ team.  Also, the plan is to get a press release
  out on this.

* The board leaves and the core team pretty much decides that doing this
  is not bad at all, and the only thing that needs work is the wording in the
  press release.  Nobody appears to be against.

* The topic of GTK+ 3.0 was brought up after this.  3.0 would be an API and
  ABI breaking release.  The team decided that we would like to avoid breaking
  API since a lot of companies invested into GTK+ 2.x and expect that it'll
  be supported for some more years.

  Most of the team seems to agree that we want to get rid of the cruft in
  the 2.x series, some of which is still sticking around from the 1.x series.
  Matthias mentions that FC6 will not ship with GTK+ 1.x.  (People cheered
  and Tim complained about he won't be able to run xmms then).

  The idea of introducing compiling subsets was brought up.  We could set up
  a make system where the full library or only a subset is built, for example
  omitting all the old stuff and the printing support.  The people using
  GTK+ on embedded devices would be really happy if we implemented something
  like this.

  If we want the compiling subsets to work, we need to make sure that none
  of the internal code is using deprecated widgets.

  Breaking API is not really something we really want to do soon.  If we ever
  do it, we want to do it right so it can last for at least a couple of years.
  Also, we would prefer the development on 3.0 to happen in parallel with
  2.x development.  Alex brought up the idea of creating a bug which we can
  use to track all issues which require breaking the API, so we get a
  formalized list of stuff which needs API breakage.

  According to Tim breaking the ABI is not a real problem, since distributions
  and also for example the Maemo.org platform can just be recompiled.

* Tim also mentioned that Michael Meeks has been working on optimizing
  shared library loading optimization in OpenOffice.org.  We wondered if
  there's anything we can do to improve GTK+'s performance in this area.  As
  Michael was unable to attend Tim and/or Matthias will try to have a talk with
  Michael about this.

As there was nothing left discuss, we decided to close the meeting.