Notes and thoughts on the GTK+ meeting at GUADEC

[Kristian Rietveld <kris gtk org>]

Hi All,

First my apologies for being so late writing you this e-mail.  I had
some very high priority tasks related to my studies to take care of
first.  At GUADEC early July this year (roughly a month ago), we did
not schedule for a GTK+ meeting in person like we did in the preceding
years.  When talking with Vincent at one of the parties, we figured
that it would be a pretty good idea to actually get some people
together and talk about GTK+ 3, since GNOME really wants to move
forward with the platform clean-up in GNOME 3.0.  In this e-mail, I
will briefly outline what was discussed in this meeting, as well as
pour in a couple of ideas from me personally.  I have not really taken
notes like I normally do and we also did not have an agenda for this
meeting, so I am not able to provide the structural and factual form
that you might be used to.  Even though this summary is influenced by
my own ideas, I hope it will serve as a good basis for further
discussions.

We ought to have a release of a GTK+ 2.90 in parallel with GTK+ 2.18,
in time for GNOME 2.28.  This means a release before the end of
September.  The work to complete the sealing of the API is far, but
not fully complete.  Several people have tried to bring this to
completeness, in particular Cody Russell.  Due to lack of feedback (I
am to blame here as well), this work could not be fully finished yet.
What is left to do here (basically acquired from re-evaluating [1]):

- A couple of files are still pending sealing.  Bugs have been filed
for most of these, see
http://live.gnome.org/GTK%2B/3.0/PendingSealings.

- Implement class private data, bug 521707 has been filed for this and
contains a patch.  I will give this a review and if the patch seems
right get Tim to review it as well.

- Deprecate public class data using GSEAL.  I think there has actually
been a discussion on whether this is necessary and whether we should
keep slots in classes.  I hope Mitch can fill me in on this.

- Introduce GObject convenience accessors.  Bug 541569 has a patch
that is partly reviewed.  I will review this as well.

- Deprecate widget flags and introduce proper API as replacements.
See also bug 69872.  Mitch has been working on this recently.  Mitch,
could you give a status update here?

- Seal GtkStyle.  This really has to be done together with
investigating the plans for theming, see below.

- Investigate whether there is stuff to seal in GDK, GLib.  I think
for now there won't be a GLib 3 (but please correct me if I am wrong),
so I would say to leave out GLib for now.  GDK certainly has to be
done.  I can look into this and write up a proposal later on.

- Make up our minds whether or not to deprecate non-multihead-safe
function calls (bug 547920).  People are pretty divided on this, I
don't have a strong opinion on this yet.

The wiki page also lists investigating a "diagnostic mode" that I
think we can skip for now.  Investigations for using -Bsymbolic and
using attribute-based deprecation might still be useful to do, but can
happen after the sealing is done.

When done, we can move on with the "2.9 development branch tasks" as
listed on [1].  These tasks should be pretty straightforward.


So, what should happen next?  For the current plan, we need to sit
down and determine a feature set for GTK+ 3.0.  There are a lot of
ideas on features and a draft roadmap has been posted earlier this
year[2].  The roadmap is fairly large and we have not really received
many comments on this.  Some people at GUADEC told me this is because
"everybody agrees".  I think one of the other problems is that the
items are not very elaborate.  Furthermore, we should at least check
if we have gotten the priorities right in the draft roadmap and see if
we are missing something obvious.  I doubt that much will come from
this roadmap in its current form.

During the meeting it has also been mentioned that when we put out a
GTK+ 3.0 and start working on features (for example in the incremental
manner as was described in the original ideas[3]) and we notice that
an ABI break is needed then we won't be able to get such features in
until GTK+ 4.0.  It is not clear to me personally if a GTK+ 4 (with an
accompanying ABI break) will happen at all in the near future, but
even if it happens at least this means a wait of 3 to 4 years.  When
this is the case for new features such as theming system improvements,
etc, I agree that another 3 to 4 year wait is unacceptable.

A different way to start working on the new features is to decide on a
feature set first, research the features and (if required) make
required changes *before* an ABI frozen GTK+ 3.0 is put out.  This
brings up the next question: what features to research first?  For
this, I think we need to talk with our prime users: GNOME, GIMP,
Mono/MonoDevelop, XFCE, etc, etc (this list is of course fully up for
discussion).  Make them aware of the existence of the roadmap and ask
them what features are most important to them and which they feel are
missing.  Talk with the most active people involved in theming and art
(there really is much going on in there right now) to come to
consensus on a feature set with regards to theming; this is important
because it will tell us what GtkStyle should be "migrated" to.  Also
look at outstanding patches adding new features in Bugzilla.  This is
an information gathering phase that can be turned into a GtkTask[4].
If people agree with this approach, we can turn this into a more
formal and clear description of the work.

After the information gathering period, we have a list of features
that are really wished for.  Using this list, hard decisions should be
made.  Which features will be implemented?  And in which order?  These
questions should be discussed in the IRC meetings that are being
re-started soon (Emmanuele will take care of this and also Alberto
Ruiz has offered help here) and possibly in a phone conference.  Then
we need to research the features: what should be supported and what
will the API look like?  I am fully aware that we cannot get such API
right at the first try or see all pitfalls.  Even some prototyping
might be in order.  The goal is to get a sense of the basics of the
new API so that we are able to deduce whether an ABI break is needed.
The API used for this test is most probably not the final API (again
for the simple reason that you cannot get API right at the first try),
but I think that it can at least help us to contemplate whether an ABI
break is needed or not.  During the implementation phase, it can also
help us to set up of a list of milestones for implementing this
specific feature.  These milestones can be used to split up the work.

The end result will be a roadmap that reflects what our users prefer
to see first.  And also is more descriptive, helping us to see whether
an ABI break is needed to implement a feature and helping us to split
up the work to get the feature implemented.

The roadmap is important for making the decisions about breaking ABI
before GTK+ 3.0 is released.  It is also important for the GNOME 3.0
process.  GNOME 3.0 does not have to depend on GTK+ 3.0, it can also
depend on GTK+ 2.90 to start with.  GTK+ 3.0 can be put in at a later
point.  GNOME is willing to put in a GTK+ 3.0 when it is 6 months
delayed.  Before they can justify such a decision they need to know
what GTK+ 3.0 will bring them -- ergo, a more elaborate roadmap is
needed.

Of course, the roadmap needs a deadline.  I think that especially the
feature research phase after the information gathering is quite a bit
of work and something that we haven't done in the GTK+ project before.
 My early estimate is that we need at least 3 months to get this work
done.  (But I am pretty bad at doing estimates).  Opinions here?


I want to conclude this e-mail with some general ideas on helping
current and new contributors.  Again, during the last GUADEC I have
sensed that there are many, many people interested in GTK+ and also in
helping out.  However, most people have studies and jobs and cannot
really put in more than a couple or a dozen of hours per week.  It is
then hard to implement invasive features from scratch.  If we have a
roadmap that more or less spells out how a feature should/could be
implemented (like we have discussed above), we can split that up in
steps that take, say, one or two dozen hours to implement.  This
requires the "basic API" of the feature to be an agreed upon design.
We can put these steps on a wiki page listing "short-term
tasks/goals".  People that want to contribute can sign up for such a
step, get the work done, get it reviewed and commit it.  This wiki
page would also list bugs that need reviewal work, we have in the past
had lists of selected bugs mailed to gtk-devel-list, these should
probably be put on this wiki page instead.

The GtkTask for patch testing already notes that our bug/patch testers
(Cody and Mathias) can do basic review of patches.  Would it be a good
idea to follow practices seen in other projects that use the notion of
"review" and "super review"?  When a patch has been tested and passes
review of coding style and basic functionality then "review" can be
awarded.  Core maintainers will mainly look at patches with "review"
and award "super review" when they can be committed.  I am pretty
confident we already have a good amount of people that could help out
with this process and can become reviewers.  Do people feel this will
help patch review efficiency?

At last I would personally really love to extend the section on the
GTK+ website about contributing.  The current web page lists three
things, GtkTasks, GtkLove and the mailing lists, and that's it.  I
will devote another mail about this later on and will gladly volunteer
to help with content for these new pages.


That's mainly it.  Please discuss.


regards,

-kris.


(Apologies for the long e-mail ;) ).


[1] http://live.gnome.org/GTK+/3.0/Tasks
[2] http://mail.gnome.org/archives/gtk-devel-list/2009-April/msg00048.html
[3] Document linked from
http://mail.gnome.org/archives/gtk-devel-list/2008-March/msg00046.html
[4] http://live.gnome.org/GtkTasks