[Sugar-devel] Window handling for non-Python activities

[Daniel Drake]

Hi,

There are a number of popular apps which have had a minimal Sugar
launcher built around them so that they can be launched from Sugar.
Examples include GCompris, Tux Paint and Tux Math.

In recent versions of sugar (tested 0.96 and 0.98) the way these are
launched is no longer working smoothly. The problem is that after
using the apps, you see a "failed to start" pulsing launching screen
error. This is causing confusion at schools in Nicaragua where
Sugar-0.96 is currently being depoyed.

This didn't happen on older versions of Sugar (haven't checked why,
maybe the "failed to start" screen didn't exist before?)

These launchers work as follows:
They implement an Activity class, but they don't really do anything
activity-like there. In __init__ they call os.system(foo), where foo
is the app in question, which produces its own full-screen window.
Then it calls self.close().

Note that os.system() is synchronous, so this Python launcher keeps
running until the app is actually closed, then it reaches the next
line of code (self.close()), then it returns from __init__.

foo creates its own windows which are picked up by Sugar, however
since they don't have any of the X properties set, Sugar isn't sure
which activity they belong to.

90 seconds later, since the Python launcher has failed to create an
identifiable window of any kind, Sugar decides that launch has failed.

Then, when the user later finishes using the app, they close it, and
then they see the confusing "Tux Paint has failed to start" message.


This can be quickly reproduced on latest OLPC builds with Sugar-0.98:

1. yum install tuxpaint
2. Install this launcher: http://dev.laptop.org/~gonzalo/nicaragua/TuxPaint-6.xo
3. Run the Tux Paint "activity"
4. Let tux paint run for at least 90 seconds
5. Exit tux paint
6. Observe confusing "failed to start" screen.


How can we solve this issue? Do we need to modify all of these activities?

Or can we improve Sugar here? If Sugar can determine the PID of the
new window, I guess it could observe that it is a child process of the
python launcher (which it is tracking) and behave better here. That
does sound a bit ugly though, maybe fixing the activities is nicer?

Whatever we decide we should produce a quick wiki doc to explain how
these launchers should/shouldn't work.

Thanks
Daniel