[sugar] A Launcher Activity

[Noah Kantrowitz]

In the "good reason to not do it category": this will not work on the  
final system. Anybody other than Sugar itself trying to start an  
activity will simply be ignored. You will be unable to see the other  
activities directly anyway.

--Noah

On Aug 13, 2007, at 9:12 PM, Carlos Neves wrote:

> 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
>>>
>>>
>>
>>
>
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>