GTK+ 3.0 tasks

On this wiki page the tasks required to be done for GTK+ 3.0 are listed, together with their progress. The page layout is similar to that of the GtkTasks page, please scroll down for more elaborate descriptions of the task and its current status. The original mail outlining the steps to GTK+ 3.0 can be found here: http://mail.gnome.org/archives/gtk-devel-list/2008-June/msg00014.html.

The tasks have been split up in a set of tasks that can be done in the current development line to prepare the 2.x branch and a set of tasks that should be done once we have branched for a 3.0 development line. Note that not all tasks are fully explained in detail yet -- a lot will still have to be hashed out on the mailing list.

Preparative tasks

2.9 development branch tasks

#P1

Description

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.

Need 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.

Progress

About 95% done, merged in current upstream trunk. See PendingSealings for a more elaborate status report.

#P2

Description

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 :)

Progress

Not yet started.

#P3

Description

We should deprecate public class data through GSEAL(). Later on these fields can be moved into private class data on demand.

Progress

Depends on #P2. Not yet started.

#P4

Description

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.

See bug #541569

Progress

In progress.

#P5

Description

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.

Progress

In progress.

#P6

Description

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 2.9, since there is a good chance that otherwise we will not be able to fix this in 3.0 onwards like we can do with the other components. This will need to be investigated and reported on. See #541136.

Progress

Not yet started. There will also be looked into this during the GTK+ BOF at GUADEC.

#P7

Description

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.

Progress

Not yet started.

#P8

Description

We should start to enforce the usage of single header includes and not make this optional.

Progress

Done, committed in upstream trunk.

#P9

Description

We should investigate what things in GLib we want to seal, if any. If we do decide to seal things in GLib, the GSEAL macro definition will have to be moved to GLib from GTK+. Then we can remove the extraneous gdkconfig.h includes from the GTK+ header files where needed (we had to add these includes to for example gtktreemodel.h to get the GSEAL macro defined).

Progress

Not yet started. Progress should be logged in PendingSealings

#P10 - Sealing Gdk

Description

Publically exposed strcutures in Gdk should be sealed just like in Gtk. Some judgement is needed to not seal value structures such as GdkWindowAttr.

Progress

GDK has been looked into. First try at a patch is there. Progress should be logged in PendingSealings Also see bug #592580

#P11 - Deprecate non-multihead API in Gdk and Gtk

Description

Gdk and Gtk contain some backwards compatibility API from before it was multihead safe. Deprecating this for 2.16 wil enable us to get rid of it for 3.x.

Progress

In progress.

#P12 - Investigate using -Bsymbolic

Description

GLib and GTK+ currently use a somewhat cumbersome method of avoiding PLT overhead for internal calls to public functions (using hidden aliases, see makegtkalias). It may be possible to achieve the same effect but passing -Bsymbolic to the linker. That would be a considerable simplification of the code and the build process.

Complications: the symbol lists that are used for the current method are also used to create .def files for win32 and to check the ABI for accidental exports.

Progress

Not yet started.

#P13 - Investigate using attribute((deprecated)) for deprecation

Description

GLib and GTK+ currently use a cpp-based method of deprecation. Switching to the attribute-based method would have the benefit that it can give warnings, instead of just breaking the build (as the current method) and the warnings can point exactly to the source location of deprecated api usage.

Also, if we hide the attribute behind a macro, we may be able to do add some more magic to e.g. move deprecated functions to its own text segment, reducing their runtime overhead.

The downside of switching to the attribute-based method is that gtk-doc supports the current method, so it would have to be enhanced to handle both.

Progress

Not yet started.

#Q0

Description

Development towards 2.90/ 3.0 is happening on a branch, in parallel to the GTK+ 2.20 development on master. The branch is rebased regularly.

Progress

Done. The branch is gtk-2.90, and it is rebased regularly on master.

#Q1

Description

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

There has been discussion about moving deprecated widgets to a separate library, libgtk3deprecated or similar, instead of removing them altogether. See e.g. http://mail.gnome.org/archives/gtk-devel-list/2008-July/msg00151.html

Progress

Depends on opening of 3.x development line, not started yet.

#Q2

Description

Remove all structure fields from the public API. There are two ways this can be done:

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.

Progress

Depends on opening of 3.x development line, not started yet.

#Q3

Description

Change the compile flags to disable deprecated functions by default.

Progress

Depends on opening of 3.x development line, not started yet.

#Q4

Description

Remove G_ and GTK_DISABLE_SINGLE_INCLUDES and enforce including glib.h and gtk.h only.

Progress

Depends on opening of 3.x development line, not started yet.

#Q5

Description

It must be possible to install GTK+ 2.x and GTK+ 3.x in parallel, and build applications against each of them by choosing the right pkgconfig files. It is not required that one can use both versions in the same process.

Progress

Depends on opening of 3.x development line, not started yet.

GTK+/3.0/Tasks (last edited 2009-11-14 21:50:25 by JavierJardon)