[Sugar-devel] Sugar and activities flag day

[Daniel Drake]

Just wanted to summarize an enlightening conversation that just
happened in #sugar:

1. GNOME 3 is expected to be released 6 months after GNOME-2.32. This
roughly lines up with the release date for Sugar-0.92.

2. GNOME 3 is expected to be based on GTK+-3, which breaks
compatibility with GTK2 (but can presumably be installed side-by-side
with GTK2, like GTK2 can coexist with GTK1)

3. Programs cant use GTK2 and GTK3 at the same time. One or the other.

4. PyGTK (used extensively by Sugar and activities) is not expected to
be ported for GNOME-3.

5. pygi ("gobject introspection") is the effective replacement for
PyGTK but requires a truckload of trivial changes to every
program/module that uses PyGTK (see
http://live.gnome.org/PyGObject/IntrospectionPorting)

6. We'll also see problems where (e.g.) evince moves to GTK3, meaning
that we lose the static Python bindings and are expected to switch to
gobject introspection. The Read activity would then have to start
using pygi+GTK3, but it can't do that because the Sugar GUI libraries
which it uses use GTK2, and we arrive at point #3.

7. It is likely that distributions that ship GNOME-3 will start
shipping pygi and stop shipping PyGTK (or ship a PyGTK with
substantially reduced API), meaning that sugar and all activities will
simply *stop working*



This obviously calls for Sugar switching to GTK3 and remaining in sync
with gnome, but will be a big headache w.r.t. activities.

Some ideas that were thrown around:

- Someone could write a compatibility layer that makes code written
for pygi work with PyGTK (therefore we port the whole of the sugar
world, but people can install the compat layer and keep it running
with GTK2)
 ... but this would be a huge amount of work, and the time would be
better spent on the work needed to bring sugar up-to-date

- When making the switch we could bump sugar's version number to 1.0
in order to make the change really obvious
 ... but there are concerns about false implications that people would
draw from such a number ("Sugar is mature!!")
 ... some people would want to use such a version jump to make
backwards-incompatible changes in the Sugar API and those people would
probably want more than 6 months in order to prepare for it

- or we could just bump it to sugar-0.100, but thats not such a strong
communication (under the current 6-month system we'd reach sugar-0.100
in 2.5 years time without breaking API)


Daniel