Hi all,
As most of you already know, we have presented our vision of a GTK+ 3.0 at
the hackfest in Berlin last March. In the weeks that followed we have
received and seen a lot of positive reactions and we feel that the
community mainly agrees with our plans and goals. We won't repeat the
original plan in this e-mail, please refer to Tim's mail[1] from last
March.
While we have been pretty quiet after the hackfest we have definitely not
been idle and have already started work on this in order to try it out and
see that it works in practice. With this e-mail, we want to let you know
how we are going ahead and get as many people involved as possible. In the
remainder of this e-mail we will line out which steps we need to take to
get to GTK+ 3.0 and how to execute those. As said, we have already done
some work and will report on our progress and where to find it.
Steps to take
-------------
These first steps are all things that are preparative and can be done in
the current 2.x branch.
1. Seal all public structure fields using the GSEAL() macro. If necessary,
provide new accessor functions to these fields. Also "priv" fields that
point at structures containing private object data are sealed. We have
already mostly completed this task in our GTK+ repository (please look at
the "Our repository" section below for more information). Before this is
committed in the upstream repository we have to make sure that tools that
parse headers, like gtk-doc, binding generation tools, etc, still work and
can thus handle the insertion of the GSEAL() macro.
2. Implement class private data. This is very similar to what we already
have for creating the private object data. It involves changing the GType
code and fortunately Tim is going to take care of this for us :)
3. As a logical continuation, we should deprecate public class data through
GSEAL(). Later on these fields can be moved into private class data on
demand.
4. We will completely lose all means to simply access fields by just
dereferencing the structure. Instead, we will start to use GObject
properties to access this data much more often. Using g_object_[sg]et()
can become a little tedious. Therefore we should introduce a couple of
convenience accessors for GObject properties such as g_object_get_int(),
*double(), *string(), etc.
5. There are a couple of "macro accessors", like GTK_WIDGET_GET_FLAGS()
that have always been troublesome (see bug #69872). We should provide
normal accessors (functions) for these instead and then get rid of the
macro accessors.
6. Without question, GtkStyle is most definitely the hardest thing to
properly seal. In addition, a lot of people agree that there are some
parts to fix here before we release 3.0, since there is a good chance that
otherwise we will not be able to fix this in 3.2 onwards like we can do
with the other components. This will need to be investigated and reported
on.
7. In our original plans we have been talking about a diagnostic mode. One
of the main ideas was that this can be enabled during run-time to check
whether an application is easily portable to a newer GTK+ version, ie. it
does not do things that are not covered by ABI/API guarantees. Such things
include the poking inside widget hierarchies, calling deprecated functions,
etc. When an application does such things, a runtime warning could be
printed on standard output. What exactly the diagnostic mode should
include and be able to do is not at all clear yet. This should be
investigated and a proposal be written and discussed.
8. We should start to enforce the usage of single header includes and not
make this optional. Mitch has been working on this and most is already in
place in SVN trunk.
At this stage all steps have been done to prepare the current 2.x branch
for "conversion" into 3.0. The next steps deal with taking the results of
this work and then creating a development line for 3.0.
9. Remove all code that has been deprecated in the 2.x series. This
includes all widgets and functions that have been marked as such. To make
it clear, we will not mark any code as newly deprecated in the 3.0 release.
10. Remove all structure fields from the public API. There are two ways
this can be done:
a) Move object structures to private headers.
b) Move object structures to the local C file, the rest of GTK+ will then
also have to use accessors.
If we pick option b), this step will include adapting all GTK+ source files
to use accessors instead of direct field accesses. For a) we can also
choose to have only bigger widgets (such as GtkTreeView) share the private
headers with the structures and then the other parts of GTK+ that do not
include these headers will again have to use accessors.
11. Change the compile flags to disable deprecated functions by default.
Now, we have a 3.0 branch that is ready to be released. As discussed in
the original paper and presentation[1], we will wait with introducing new
features and deprecating more code until 3.2. All applications that have
been compiled against the last 2.x release with the GSEAL and disable
deprecated compile flags enabled will compile cleanly against this 3.0
release.
Our repository
--------------
We have a git repository at git.imendio.com:
git://git.imendio.com/projects/gtk+.git
In this repository, the master branch tracks upstream. The sealing happens
in the GSEAL branch. This repository is also accessible via the
web-interface:
http://git.imendio.com/?p=projects/gtk%2B.git;a=shortlog;h=refs/heads/GSEAL
We intend to move our work to upstream as soon as possible to simplify the
involvement of the community members.
Tracking progress
-----------------
Moving the GTK+ 3.0 using the steps above is a big undertaking and we
therefore need to carefully track the progress. The best way to do this is
by using a wiki-page at live.gnome.org that everybody can monitor and
update. The page will contain the steps as outlined above and a
description of where we are with regard to its progress.
The new development policy
--------------------------
Another large part of the plan presented in the paper[1] was the adoption
of a very clear development policy. We already have a couple of ideas for
this and will send out a draft to the list for discussion soon. It is
important to have this policy in place before 3.0.0 is released.
We hope to work together on achieving this all. If there are any
questions, suggestions, etc; we would be delighted to hear about those!
regards,
-kris.
--
1. http://mail.gnome.org/archives/gtk-devel-list/2008-March/msg00046.html
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
