[sugar] A Launcher Activity

[Carlos Neves]

Hello,

One of the things I developed for World Wide Workshop was a launcher 
activity, called the MMM Activity Center (MMM stands for MaMaMedia), 
which aggregates all relevant activities as a bundle to be launched only 
from there, much like etoys does.

Unlike etoys, each activity there is a full blown standalone Sugar 
activity, that could very well be launched from the Home view (and in 
fact is). The simplicity of this approach in terms of mesh sharing and 
journal support tilted us into the current solution.

I'm using bundlebuilder.py to find out if the activities are installed, 
which has worked well from the start, except for the fact this 
particular file has been a moving target between versions... The current 
code checks for it in 3 different locations.

But my actual problem is different. The approach I'm using works on 
build 432, by using

--8<--
            handler = activityfactory.create(bundle.get_service_name())
            self._c1 = handler.connect("success", 
self._launch_success_cb, handler)
            self._c2 = handler.connect("error", self._launch_error_cb, 
handler, idx)
            self.bubble_label.show(_("Loading %s...") % BUBBLE_SET[idx][0])
            self.si.lock()
            c = gtk.gdk.Cursor(gtk.gdk.WATCH)
            self.window.set_cursor(c)
--8<--


The problem with current builds, specifically 542, is twofold:
- the 'success' and 'error' signals no longer exist and
- Home view is brought to front

Looking at the code for the Shell, I see that the notifications are now 
only delivered to _shell and it pops itself to front every time an 
activity is launched, period.

What I would like to see, although I fully agree with the current 
approach for things launched from the Journal or the Mesh, is a way to 
avoid showing the Home view and getting the launched and error 
notifications under controlled circumstances.

for example, 
lib/python2.5/site-packages/sugar/activity/activityfactory.py:create 
could take an extra 'listener' argument that was then passed to the 
ActivityCreationHandler.
ActivityCreationHandler._launch_activity would call NotifyLaunch not 
only on the shell proxy but also on that listener (if not None, of 
course) and the same goes for _create_error_handler/NotifyLaunchFailure.
I could use a NotifyLaunchSuccess on top of _create_reply_handler too, 
if that's not asking too much :)

This would make the notifications work optionally without the signals, 
although implementing signals (again) would work great too. I'm biased 
towards this approach because this way the ActivityCreationHandler knows 
it should signal the shell in order to not pop up front, but adding an 
optional bool on the NotifyLaunch method or something.

Am I being completely unreasonable here? I really think that being able 
to aggregate activities outside the Home view is important, as there is 
only so much space there, and this Activity Center is actually important 
for us.

Best regards,

Carlos Neves
cn at sueste.net