[Sugar-devel] sugar-toolkit-gtk3 plans

[Daniel Drake]

Hi,

We have started to implement GTK3 support in
sugar-toolkit/sugar-artwork and have been faced with some decisions
which have met a lot of discussion in the group. Some of this is
simply expanding on the plans so far, which did not dive down into the
gory details which we now face:
http://wiki.sugarlabs.org/go/Features/GTK3
and some is a slight modification to what is documented there.


Here's what we are thinking:
http://www.itevenworks.net/2011/10/sugar-gtk3-hackfest-prague-day-1/

sugar-toolkit git master will be ported to GTK3 directly, without
keeping the GTK2 version. The package name in configure.ac will be
changed from "sugar-toolkit" to "sugar-toolkit-gtk3", affecting the
name of the resultant tarball (the version number will stay as
0.95/0.96 however). This acts as an implicit recommendation to
distributions that sugar-toolkit-gtk3 is a separate package from
sugar-toolkit; we can back this up with an explicit packaging
recommendation in the release notes.

sugar-toolkit will still exist as a GTK2 version in the sucrose-0.94
branch. We are toying with the idea of freezing this immediately and
not making any changes going forward, so that all sugar-toolkit
development efforts are spent on the ever-important GTK3 port, and as
an incentive for activity developers to move to GTK3 sooner rather
than later. However, we aren't too sure about being able to completely
leave this alone - a compromise of only making very few changes may be
more appropriate (for now we won't be freezing - this is just a
thought).

In sugar-toolkit master, we will "git mv src/sugar src/sugar3" and
adjust the build machinery to install this module under the new
"sugar3" name. This means that sugar-toolkit-gtk3 will be installable
in parallel with sugar-toolkit, meaning that we have support for GTK2
and GTK3 activities.

The name "sugar3" is chosen with some reluctance - we couldn't find a
solution we really like for the problem of needing to somehow have two
different, incompatible sugar-toolkits installed (but we decided both
on this list and at this meeting that having separate namespaces is
better than somehow hacking both into the same "sugar" module name).
We decided that sugar3 is the best compromise as a name of the new
GTK3-based toolkit. The "3" indicates that it is based on GTK3, which
*is* an item of importance for sugar activity developers: they will
need to go to gtk.org or whatever and choose between GTK1/GTK2/GTK3
documentation, in this case the "3" will help guide them to the right
place. And it is somewhat future-proof, we can envision "sugar4" for
GTK4 and so on.

Distributions will then ship sugar-toolkit-0.94.x and
sugar-toolkit-gtk3-0.96.x, installing both at the same times on users
systems for a transition period of 1 year after the first official
sugar-toolkit-gtk3 stable release. After 1 year the recommendation to
drop sugar-toolkit will be made, leaving only GTK3 support.

sugar-base includes some stuff that gets installed in the "sugar"
module. This will be moved into sugar-toolkit-gtk3's sugar3 module.
The main bit here is the MIME type stuff; unfortunately gio doesn't
provide all that we need (such as the ability to get the default
extension of a mime type) - in the longer term we should look at
extending the gio API. It additionally installs a small logger class
(easy to move) and a "dispatch" mechanism, also easy to move, and we
could consider moving to equivalent glib functionality in the longer
term. When distros drop sugar-toolkit-0.94 to remove gtk2 support,
they can also drop sugar-base.

The next problem is that of /usr/bin/sugar-activity. Right now, this
imports from the sugar (GTK2) module (specifically activity/main.py).
We are planning to refactor this so that /usr/bin/sugar-activity is
made independent of the sugar/sugar3 module. The GTK-specific stuff
that happens in main.main() will be moved into the activity class (for
both gtk2 and gtk3), and the rest will be moved into
/usr/bin/sugar-activity. The final thing is invoking gtk.main or
Gtk.main - this will be done by adding a run_main_loop method to the
activity classes, called by sugar-activity once the activity instance
has been instantiated.


If we get things into good shape, we are planning to commit all this
to master tomorrow evening. We have already made lots of progress
including a somewhat functional theme and a major palette-related
headache solved. Code and plans will be carefully reviewed and
developed in collaboration by the Sugar superstars we are fortunate to
have in the room this weekend (as has already been happening). We'll
be happy to respond to comments that come in this weekend or
afterwards in further commits. Sascha, would this be OK with you?

While things are still a little 'raw' we will be working in branches
today and tomorrow morning, they will be detailed here:
http://wiki.sugarlabs.org/go/Features/GTK3/Development

Thanks,
Daniel