[sugar] A Launcher Activity

[Carlos Neves]

The Activity Center is a standalone activity as things are now, and will 
continue to be unless there is some good reason to change this. It's the 
only MaMaMedia activity launched from the Home view.

The relation to other activities, which are already not launched from 
the Home view, is implicit. There is a hard coded list of activities the 
Center known about, and checks for them at startup. If the activity is 
there, it can be launched, and if not a 'Coming soon...' notice appears. 
We envision that eventually an auto download will be implemented for 
activities not already installed, but that's something for future 
discussion.

At it's present state, the Center has another task on it's hands. It 
holds code and data (images) that are common to MaMaMedia activities, so 
they are not duplicated in the filesystem.

The other activities are not invisible to Home though, they are simply 
not launched from there. This way we reuse the code already done for 
managing the running apps, and Sugar Activity factories are free to do 
their magic and optimizations. This makes each Activity appear 
transparently in the Home donut, if you share the activity it can be 
remotely launched from the Mesh view and you can (not any more, but will 
soon) restart an activity from the Journal, without any extra effort on 
the Center part, as this is all handled by Sugar. That's the extra work 
etoys needs to do for supporting the Journal that we get for free.

Regards,

cn

Samuel Klein wrote:
> 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
>>
>>     
>
>