[Olpc-france] TR: Window handling for non-Python activities

Lionel Laské lionel.laske at gmail.com
Lun 25 Fév 15:19:38 EST 2013


Une intéressante discussion sur la liste sugar-devel qui explique pourquoi
certaines activités ne fonctionnent pas sur Sugar 0.96.
Discussion à suivre pour nos tests à venir !

	Lionel.


-----Message d'origine-----
De : sugar-devel-bounces at lists.sugarlabs.org
[mailto:sugar-devel-bounces at lists.sugarlabs.org] De la part de
sugar-devel-request at lists.sugarlabs.org
Envoyé : lundi 25 février 2013 19:35
À : sugar-devel at lists.sugarlabs.org
Objet : Sugar-devel Digest, Vol 52, Issue 56

Send Sugar-devel mailing list submissions to
	sugar-devel at lists.sugarlabs.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.sugarlabs.org/listinfo/sugar-devel
or, via email, send a message with subject or body 'help' to
	sugar-devel-request at lists.sugarlabs.org

You can reach the person managing the list at
	sugar-devel-owner at lists.sugarlabs.org

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Sugar-devel digest..."


Today's Topics:

   1. Window handling for non-Python activities (Daniel Drake)
   2. Re: Window handling for non-Python activities (Daniel Drake)
   3. Re: Window handling for non-Python activities (Daniel Narvaez)
   4. Re: Window handling for non-Python activities (Daniel Narvaez)
   5. [write v2 PATCH] sl#4442: Now,	Copy-to-Clipboard works fine,
      after the recipient clicks on the thumbnail,	and the
      complete-data isfetched. (Ajay Garg)
   6. [record v3 PATCH] sl#4442: Now,	Copy-to-Clipboard works fine,
      after the recipient clicks on the thumbnail,	and the
      complete-data isfetched. (Ajay Garg)
   7. Re: [record PATCH] sl#4442: Now, Copy-to-Clipboard works
      fine, after the recipient clicks on the thumbnail, and the
      complete-data is fetched. (Ajay Garg)


----------------------------------------------------------------------

Message: 1
Date: Mon, 25 Feb 2013 11:22:49 -0600
From: Daniel Drake <dsd at laptop.org>
To: Sugar Devel <sugar-devel at lists.sugarlabs.org>,	Gonzalo Odiard
	<gonzalo at laptop.org>
Subject: [Sugar-devel] Window handling for non-Python activities
Message-ID:
	<CAMLZHHTMGtNXHd4aDTS8eaSx0Mgt=eQ5C6u8PzS_RKKTheF-Ug at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

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


------------------------------

Message: 2
Date: Mon, 25 Feb 2013 11:45:40 -0600
From: Daniel Drake <dsd at laptop.org>
To: Sugar Devel <sugar-devel at lists.sugarlabs.org>,	Gonzalo Odiard
	<gonzalo at laptop.org>
Subject: Re: [Sugar-devel] Window handling for non-Python activities
Message-ID:
	<CAMLZHHSbN2u59i2yz11VO=7E-4mWkE_5uukma4mKPm8u7nMmGg at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 25, 2013 at 11:22 AM, Daniel Drake <dsd at laptop.org> wrote:
> 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.

Without modifying Sugar, here's how I got such activities to behave (took a
few tries to find a working solution).

TuxPaintLauncher __init__ uses subprocess.Popen to launch TuxPaint, and then
schedules a GTK+ exit to happen only after the launcher's window
registration has happened.

        subprocess.Popen(options)
        gobject.idle_add(gtk.main_quit)

Daniel


------------------------------

Message: 3
Date: Mon, 25 Feb 2013 18:46:44 +0100
From: Daniel Narvaez <dwnarvaez at gmail.com>
To: Daniel Drake <dsd at laptop.org>
Cc: Gonzalo Odiard <gonzalo at laptop.org>,	Sugar Devel
	<sugar-devel at lists.sugarlabs.org>
Subject: Re: [Sugar-devel] Window handling for non-Python activities
Message-ID:
	<CANTHhva1bcu24f0QuLpJQ54Hr8qJ78heDk3Qj9SwL7mLOVxXpA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 25 February 2013 18:22, Daniel Drake <dsd at laptop.org> wrote:
> How can we solve this issue? Do we need to modify all of these activities?

The way these activities are written seems sort of crazy but maybe I'm
missing something. I'm not sure why they are using a python activity at all.

> 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?

Did you see my "Fallback to _NET_WM_PID to map windows to activities"
patch? I sent it a while ago so I don't remember for sure, but it might be
possible to make it work with child processes. If it's possible cleanly, I
think it would be a good addition, it would make easier for people to write
non python activities.

Alternatively you could still use that patch, but modify the activities to
pass the main executable to the activity.info directly.
Or for a smaller change I suppose os.execv might also work (?).


------------------------------

Message: 4
Date: Mon, 25 Feb 2013 18:50:36 +0100
From: Daniel Narvaez <dwnarvaez at gmail.com>
To: Daniel Drake <dsd at laptop.org>
Cc: Gonzalo Odiard <gonzalo at laptop.org>,	Sugar Devel
	<sugar-devel at lists.sugarlabs.org>
Subject: Re: [Sugar-devel] Window handling for non-Python activities
Message-ID:
	<CANTHhvb2pDyLACyT3XnqMBppqtLYEvGFBz7kGvbRESvRGSBDiw at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 25 February 2013 18:45, Daniel Drake <dsd at laptop.org> wrote:
> On Mon, Feb 25, 2013 at 11:22 AM, Daniel Drake <dsd at laptop.org> wrote:
>> 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.
>
> Without modifying Sugar, here's how I got such activities to behave 
> (took a few tries to find a working solution).
>
> TuxPaintLauncher __init__ uses subprocess.Popen to launch TuxPaint, 
> and then schedules a GTK+ exit to happen only after the launcher's 
> window registration has happened.
>
>         subprocess.Popen(options)
>         gobject.idle_add(gtk.main_quit)

Does that only solve the "launch failed" problem or does it make them work
properly? I mean I wouldn't expect the shell to be able to show the right
icon in the frame for example, because it would not be able to map the tux
paint window to the activity.





More information about the Olpc-france mailing list