[sugar] A Launcher Activity

[Samuel Klein]

Aggregating modules and activities outside of the home view is
generally important; we should do this cleanly in terms of
journalling, allowing anyone to define a cluster of related
activities.

Have you thought about packageing the Activity Center as its own
standalone activity that loads activity-sets?  Then the activity
center could be a more core app that takes in clusters of activities
(which would themselves implicitly be invisible from Home; alternately
each cluster could get one group activity icon in the home view).

approaching this problem from the other side, I wonder how we can be
better about journalling what projects within etoys are being launched
and shared.

SJ


On 8/13/07, Carlos Neves <cn at sueste.net> wrote:
> 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
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>