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/
signature.asc
Description: PGP signature
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel