On 25 February 2013 18:45, Daniel Drake <d...@laptop.org> wrote: > On Mon, Feb 25, 2013 at 11:22 AM, Daniel Drake <d...@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. _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
