[Sugar-devel] [PATCH] sugar-activity: make independent of sugar-toolkit GTK versions

[Sascha Silbe]

Excerpts from Daniel Drake's message of 2011-12-09 22:25:28 +0100:

> As we move to adding support for a second UI toolkit (GTK+ 3.x),
> the sugar-activity binary used by all activities must become
> backend-toolkit-independent.

Given that sugar-activity is the only thing in sugar that Python-based
activities (i.e. those based on the sugar-toolkit Activity framework)
need to run and that non-Python activities don't have a use for it, it
would be cleaner to move sugar-activity to sugar-toolkit.

The only reason this isn't straightforward is that some activity authors
will want their activities to run on both GTK2 and GTK3 based systems,
so hard-coding sugar-activity (GTK2) or sugar-activity-gtk3 in
activity.info isn't going to work.


One way to achieve this is by shipping a small wrapper script with each
activity capable of running on both GTK2 and GTK3 based systems that
will use sugar-activity-gtk3 from sugar-toolkit-gtk3 if available and
fall back to sugar-activity from sugar (on pre-GTK3 systems). We already
ship a stub setup.py with all activities, so a small wrapper file for
some activities doesn't really make things worse. This is the most
simple solution (KISS), so the way to go IMO.


If we'd want to avoid the wrapper script, the way we invoke
sugar-activity would need to be backwards compatible with pre-0.96 Sugar
systems, so the only variable we can tweak is how to invoke the GTK3
based sugar-activity on systems with GTK3 for activities supporting
GTK3. Since sugar-activity chokes on unknown parameters, we can't even
pass an additional flag to indicate the activity supports GTK3 (as it
would break on pre-GTK3 systems).

A potential solution avoiding wrapper scripts would be:

1. Move sugar-activity from sugar to both sugar-toolkit and
   sugar-toolkit-gtk3. Name it sugar-activity-gtk2 in sugar-toolkit and
   sugar-activity in sugar-toolkit-gtk3.

2. Modify sugar-activity in sugar-toolkit-gtk3 to check an X-Sugar-GTK3
   field in activity.info that needs to be set to true for activities
   supporting GTK3. Fall back to exec'ing sugar-activity-gtk2 (from
   sugar-toolkit) if X-Sugar-GTK3 is unset or false.

There are three different paths:

1. On pre-GTK3 systems, sugar-activity from sugar gets invoked and uses
   sugar-toolkit (GTK2).

2. On GTK3 systems, for a GTK3 activity sugar-activity
   (sugar-toolkit-gtk3) gets called and uses sugar-toolkit-gtk3.

3. On GTK3 systems, for a non-GTK3 activity sugar-activity
   (sugar-toolkit-gtk3) gets called and invokes sugar-activity-gtk2
   (sugar-toolkit) which in turn uses sugar-toolkit (GTK2).

Not really more comfortable for activity authors than shipping the
wrapper script, but much more complex.


A simpler approach would be using an additional X-Sugar-Exec-GTK3 key to
invoke sugar-activity-gtk3 (for GTK3 activities) on systems supporting
GTK3. This would move some of the logic into sugar, but doesn't tie
directly into sugar-toolkit (so non-Python activities could use it as
well, e.g. to call a binary linked against GTK3) and still avoids the
wrapper script. It would also align well with the plans to make
activity.info a plain desktop entry file [1], as we'd probably need to
rename the "exec" key to X-Sugar-Exec anyway (activities supporting
running outside of Sugar would additionally use the "Exec" key).

Sascha

[1] https://bugs.sugarlabs.org/ticket/2435
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20111213/3f80c180/attachment-0001.pgp>