[sugar] A Launcher Activity

[Carlos Neves]

Ok, this is a security assertion for sure, but should we not be able to 
politely ask sugar to start an activity, and tell us what comes of it? 
We could/should arrange for an activity grouping system to only allow a 
certain activity (the launcher) to ask for starting a specific set of 
activities.

Anyway, how is the increasing number of activities going to be handled 
by the launcher?

cn

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