GUADEC 2008 GTK+ Meeting Minutes

[Tim Janik <timj gtk org>]

Hey All.

Kris took meetings during the GTK+ developers meeting at this
years GUADEC. It took some time to transform them into a proper
writeup, and Kris had to leave for a vacation flight before
he could finish them off.

So here are the minutes from Kris with a few finishing touchups
from me. Please keep in mind that these minutes are from our
meeting 2 weeks ago, and thus don't reflect on recent community
discussions and new tweaks to the 3.0 plans.

For an update on our latest plans, please have a look at the
summary of yesterdays IRC meeting:
  http://mail.gnome.org/archives/gtk-devel-list/2008-July/msg00187.html




GTK+ Meeting, 8 July 2008, GUADEC 2008
--------------------------------------

Final agenda:

1. Opening
2. 2.14 release overview
3. Planning GTK+ 2.16
   - Features
   - Schedule
4. 3.0
   - Current status
   - Schedule
5. Technical discussions
   - 3.0 policy
   - Sealing GtkRcStyle
   - Offscreen rendering event processing
   - New GDK backend that renders into image buffers
6. Closing


Notes:

1. The meeting was opened at 12:10.

2. Last year we have promised to get GTK+ 2.14 out of the door around GUADEC
2008.  We are closely approaching this date and we seem to be mostly
feature complete.  The testing framework bits have landed in GTK+, as well
has the first part of the offscreen rendering work.  Furthermore, a lot of
small API improvements, bug fixes and clean ups have been done.  The
remainder of the offscreen rendering work deals with event processing and
is hard to get right (more on this later in the meeting).  If we wait for
this to land we will most definitely not make the GUADEC 2008 release date.
Therefore the current plan amongst the core developers is to delay the
second part of the offscreen rendering work to the next release and get
GTK+ 2.14 released in its current shape.

After asking whether people have more pending features that could make it
into 2.14, nobody has something ready that could go in at this point.
Mitch still wants to get new adjustment API (accessors for it) in 2.14 if
possible.

During the next IRC meeting the team would like to propose to API freeze
the next development release and release the stable 2.14 after a few weeks
of stabilization.


3. It was mentioned that Behdad has requested us to consider renaming to
"GTK+ toolkit" and change the license to GPL3.  The renaming to "GTK+
toolkit" issue has already been handled in bug #540529 and will not be
done.  Changing the license to GPL3 (in GTK+'s case LGPL3) is a long
process and is not planned to be carried out immediately.  In any case
we do not want to block a possible GTK+ 3.0 on a license change. A
recent discussion on the mailing list left the impression that some
implications in mixing LGPL3 code with LGPL2 code still have to be
figured out.

Apart from offscreen rendering part 2, the following items are on the
agenda for GTK+ 2.16:
 * Mathias Hasselmann's extended layout work.  Plans are to start API
   review soon.
 * Mathias Hasselmann's tool palette.  The tool palette is a "tool box"
   as found in for example the Glade UI builder and GIMP.  It will undergo
   some more real world testing as it will be tried to replace Glade's
   toolbox with the tool palette.  After that remaining kinks in the API
   will be ironed out and a proposal send to the mailing list for
   discussion.
 * Libsexy integration.  This is something that has been on the list for
   a couple of years now.  Libsexy certainly contains some nice features
   and there are no objections if these get merged at some point.  The
   problem is that so far nobody has stepped up to actually cherry pick
   features from libsexy and get them in such a form so that inclusion in
   GTK+ can be considered.  Lately Cody Russell has been working on getting
   an "icon entry" going for GTK+.  If his work continues we hope to get
   a few libsexy improvements in GTK+ 2.16.
 * Simpler API to create a simple ListView, a wrapper around GtkTreeView
   to make simple list creation without MVC split easy.  Kris has been
   discussing such an API with Johan Dahlin and Emmanuele Bassi as they are
   familiar with the Python and Perl variants of simple lists APIs
   respectively.  The Python and Perl APIs seem nice and similar, we want
   to attempt to come up with something similar for C.

Further ideas that were raised:
 * Add a new signal to GtkTreeModel that inserts a given number of rows
   in one go.  Kris argues that this is only part of a bigger problem: we
   want to have a proper batch/transaction API in GtkTreeModel.  We
   shouldn't just add this single signal for now, but sit down and properly
   design this transaction based API and try to get it right for most
   use cases.
 * How to do extend the print dialog?  Tim advises to file patches
   implementing these extensions in bugzilla.
 * What is happening on the "GLib foundation library" front?  This
   foundation library is supposed to become a general desktop support
   abstraction library.  It would support things like screen saver/power
   management/configuration API.  As with all larger projects; if somebody
   steps up with an API and implementation, we can consider this.  Ryan
   Lortie says he is working on the configuration API part using GVariant.
 * GVariant status.  All of the GVariant code is currently in git and it
   is working well.  An application is needed to try this code out.  In
   general, it seems to be ready for API review.
 * Introspection in 2.16?  For introspection it will take at least a few
   more months before it is usable.  One of the issues is source code
   annotation; there is a format for such annotation already, but no
   consensus has been reached on the final format for this.

Schedule.  The GTK+ team feels that the last few release cycles to try to
aim for a release around GUADEC have been working out well.  Therefore, and
also seeing the list of suggested features, we want to try to aim to
release GTK+ 2.16 around GUADEC 2009.  This is probably also good for
GNOME; they need a stable release a few months before theirs to be sure
that GTK+ will actually be released on time.

GtkTasks.  Tim briefly describes the GtkTasks[1] page and goes over all
slots.  It appears that two slots are already filled by some of the
attendees of the meeting, but not marked as such in the wiki.  [As far as
I know, the wiki has been updated now. ed.].  Of course we will continue
adding items to the GtkTasks page as new, isolated tasks show up.  One of
the transient tasks was moderating the canvas evaluation thread on
gtk-devel-list.  This has been done by Carlos Garnacho; briefly summarized
there is no clear consensus on where to go with the canvas.  A new
transient task is the migration of the remaining parts of the API
documentation from the SGML templates to the source code.  This is being
done by Stefan Kost and has been very well received.


4. The basic plan that was proposed for 3.0:
  - Add features in 3.2 and 3.4, ship 3.0 without new features and without
    new deprecation so porting from 2.x is easy.
  - Put a new development policy into place for 3.x which allows clearly
    defined future removal of deprecated API (ABI break), to enable
    incremental and more community driven development of the toolkit.
  - Seal all public structure fields and provide accessor functions.

The sealing work that started in an independent Git branch after the
Hackfest has already been merged into SVN trunk 2 weeks before GUADEC.
Mitch mentions that GDK has not been sealed yet; this is something that
can be done in 2.16.  He also wonders if we can deprecate and remove the
non-multihead API in 3.0.  These functions are already marked as
non-multihead-safe.  This could be looked into for 2.16.

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.  Alternatives are:
 - Another toolkit: this gives you even more port trouble than between
   major GTK+ revisions.
 - Change the prefix (for example to gt3) and link against both: this won't
   really work, you end up with 2 main loops, 2 thread systems,
   2 X11 connections, etc, etc.

Another question is how people plan to fix API in GTK+.  Two examples are
raised:
 - Scrolling should be handled in an interface.
 - Tree model columns should be indicated by a string instead of a number.
The basics of fixing API is by introducing a new function and deprecating
the old.  This could lead to "API fragmentation", as it becomes hard to
find a good function name (though this is already so in 2.x).  Though
eventually deprecated functions will now be removed.

GTK+ 2.16 is planned to be released in roughly a year.  When do we expect a
release of 3.0?  Tim walks through the 3.0 tasks page[2] where things that
need to be accomplished for the release are described.  Tim also walks
through the steps that have to be done for releasing 3.0, which are
basically removing all deprecated code and move public structure fields to
private headers.  In addition to that also change compiler flags to
disabled deprecated functions by default and enforcing single header
includes.  We settled on expecting 3.0 1-2 months after 2.16.

More discussion is held:
 - Can we make GDK backends dynamically loadable?  A possible use case for
   this is to be able to have a GTK+ with both the X11 and Quartz backends
   on OS X.  This is probably technically possible, but will take several
   months of work to achieve.  Also, you'll also hit several pieces of
   backend specific code in GTK+ instead of GDK.
 - What happens with applications that dynamically load two versions of
   GTK+ due to ELF dependencies, in particular 2.x and 3.x?
   As an example, XMMS is brought up which uses GTK+ 1.2 and could dynamically
   load a plugin that pulls in GTK+ 2.x and bad things happen.
   People argue that if the plugin would load Qt or something else you
   end up with the same problem.
   For distributors these are issue that are very hard to debug.  There
   are several ideas to improve this situation.  One is looking into the
   linker-mechanism to catch such problems.  Eventually we can try to
   have GModule to walk the ELF dependency chain of the module to load to
   catch any issues before actually loading the module.
   It might also be possible to check for conflicting ELF symbols and
   provide explanatory error messages in functions like gtk_init.
 - How do other projects handle breaking ABI?
   Deprecation schemes only scale well if deprecated APIs are really removed
   from a code base at some point. Technically, this is an ABI break which is
   why GLib/Gtk+ have not been doing this since 2.0.  However, lots of other
   vendors do this, e.g. Qt does break ABI between major releases, Python 3.0
   will be incompatible with 2.5, Apple does remove long deprecated APIs in
   newer releases of Mac OS X, Symbian, Microsoft, and the list goes on...


-- A break is held from 13:50 to 14:20.

5. For the remaining hour, a couple of technical discussions were planned.

- 3.0 policy.  Most of the 3.0 policy ideas have already been raised in the
meeting.  This involves breaking ABI/ABI with a mostly fixed interval,
removing deprecated functions after a defined period of time, etc.  The
plan is to start a writeup and review phase of the policy on gtk-devel-list
at some point to reach general agreement amongst the core developers.
Another item that'll be useful to discuss is integrating the commit policy
to the development policy document.  The commit policy probably doesn't
need to be much different than it is now, but writing it down will help
current and future contributors:
 - Code must compile before you can commit.
 - Test suite must be run before commit.
 - Revert if a commit breaks the build.

The idea of also using svn hooks for this is raised.  We do not know off
head, this would have to be checked with Olav Vitters.  Also getting up
dedicated build machines will help here if they run the full test suite
after completing the build and provide notifications or reports.

- GtkRcStyle sealing.  We have been wondering whether or not to seal
GtkRcStyle as we are not fully sure yet where we want to go with theming in
3.x.  It is a hard object to seal, because a lot of fields are exposed
here.  There are voices to actually replace this object with a Cairo-based
variant.  Also, last year's theming BoF didn't really go anywhere [this
years was much better, see the notes on gtk-devel-list. ed.].  However,
according to Carlos sealing this and using accessors might be quite
straightforward; he has not tried how hard it is to port an application to
this and whether there is a possibility this could be done automatically.

Are there plans to replace theming in 3.2?  This is not clear yet, as there
are no concrete ideas for its replacement at this point.  We do know that
during all of 3.x GtkStyle should continue to work, whether or not it is
replaced.  Basically this means that we have to seal it; the accessors can
later be reworked to provide compatibility code.

- Offscreen rendering event processing.  For the second part of the
offscreen rendering work, a lot of the event processing code in Gdk is
duplicated in non-X11 backends and partly the offscreen code.
We are looking at ways to constrain the events that are sent, some are
very X11 specific.  The suggestions are to:
  - drop the detail from GdkEventCrossing (it is only theoretically useful
    in the presence of subwindows, and cannot be relied on for non-X11
    backends or offscreen windows anyway);
  - Confine motions to motion events, synthesize Enter/Leave events.
    Deliver new pointer motion information in motion events only. This may
    result in occasional reports of 0-distance motions, but is easy to
    program with, since motion logic does not need to be replicated across
    handlers of multiple event types.
    All other event types just repeat the last motion event coordinates.
    Synthesize 0-distance motions upon widget state changes to generate
    Enter/Leave events as needed (e.g. when a widget becomes insensitive
    or is hidden).

We are wondering if anybody is using the X11 specific aspects of the events
and has problems with the proposed suggestions.

Other things that were brought up and still need polishing in the patch:
 - Implicit grabs; which are a separate issue from the event handling
   problems listed above.
 - Event coordinates transformation does not work for everybody.  It looks
   like this depends on the version of cairo that is used.

The plan is to get this second part of offscreen rendering finished during
the Fall.  Hopefully it will land in GTK+ around November.

Another suggestion was to look into abstracting out the code that handles
event processing.  Then the same code engine could be re-used in GDK,
several back-ends and for offscreen rendering.

- New GDK backend.  Hans Petter Jansson has recently been working on a new
GDK backend that is not tied to any display system and is fully offscreen.
Each window gets an image surface in which its contents are rendered.  Then
an application can do with that image surface what it wants.  This is meant
to be used in for example games, where you render the UI in a surface and
then reuse this surface in for example an SDL application.  It has event
synthesis for mouse and keyboard events.  This backend has been based on
the linux-fb code.

Hans would like to have this in a branch in subversion to continue
development and eventually get this included in GTK+.  As a conclusion, he
showed an impressive demo of his work so far.


6. Closing.  The meeting was closed around 15:30 as we have to leave the
room to make space for another meeting.



[1] http://live.gnome.org/GtkTasks
[2] http://live.gnome.org/GTK+/3.0/Tasks


---
ciaoTJ