[sugar] A Launcher Activity

[Carlos Neves]

Hi Eben,

Once again you chime in with a logic that is hard to beat :)

Although the shared data is an issue, it could be easily solved by 
creating a non-activity bundle, to be installed side by side with the 
activities, or by using another MMM activity as base, so that by itself 
is not an issue.

As for everything else, all my logic assumes the existence of launchers, 
and I can only argue details based on that assumption. If not having 
launchers is a good thing, and a desired feature, all that's left for me 
is to pass this information upstream for consideration, which I'll be 
doing now.

But still assuming a launcher activity, we have another activity that 
bears no gain in having it shared and is not less of an activity just 
because of that. I must admit we have plans on changing that, but still...
Also, would it be hard, or something to avoid, to allow certain 
activities to state they don't want to be put in the Journal or should 
not be sharable? I can work with the fact that, in principle, launcher 
activities are not what Sugar was designed for, but I'm sensing a 
terrible change in the way the whole system is being designed now, from 
a totally open "here's a great and fully supported way of doing things, 
but you are welcome to be as creative as you want" into a "here's how we 
allow you to be creative". It's starting to frighten me a bit :)

Thanks,

cn

Eben Eliason wrote:
> I'm sorry I didn't missed the beginning of this discussion.  I have to 
> say, I'm a little concerned about the underlying principles at work 
> here, since we've been doing everything we can to eliminate the notion 
> of "launchers" or "splash screens" altogether.  TamTam used to have 
> this, but was broken up in favor of 3 distinctly separate activities.
>
> The concept of a launcher doesn't really fit well with the Sugar 
> object or collaboration models.  If I open a launcher activity, what 
> do I get?  Do I get a Journal entry telling me I launched a launcher? 
> Likewise, if I share a launcher, what do I get?  It seems like the 
> idea of the launcher activity here is taking over a task which the 
> Journal is already itself designed for.
>
>  
> Each activity should be self contained (as you've mentioned yours 
> are), so that they can be individually tracked and versioned by the 
> Journal, and individually shared across the mesh.  This model works 
> well with Sugar.  This also means that each of these self contained 
> activities will have its own entry in the Journal (the activity object 
> itself), from which new instances of the activity can be launched 
> directly.  By applying a single filter in the Journal, the child could 
> have a view of all the MMM activities.  In order to support this, 
> simply tag each activity object with "MMM" and "MaMaMedia" in the 
> activity.info <http://activity.info> file.  A search or filter for 
> this tag will provide a "launcher-like" service, without the need for 
> a separate activity, hidden or otherwise.  Of course, each should also 
> be tagged uniquely as well, so that they can come up independently 
> when the child looks for a "math" activity vs. a "spelling" one, for 
> instance.
>
> The notion of shared data is still a consideration, but one that 
> should be handled independently I believe.  I think we should squash 
> the notion of launcher activities up front, since Sugar was never 
> designed with this type of interaction in mind.  The Journal is great 
> for launching and providing views of activity sets, particularly 
> because it doesn't require a static grouping, and I think we should 
> emphasize that.
>
> - Eben
>
>
>
> On 8/14/07, * Carlos Neves* <cn at sueste.net <mailto:cn at sueste.net>> wrote:
>
>
>
>     Marco Pesenti Gritti wrote:
>     > On 8/14/07, Carlos Neves <cn at sueste.net <mailto:cn at sueste.net>>
>     wrote:
>     >
>     >> The problem with current builds, specifically 542, is twofold:
>     >> - the 'success' and 'error' signals no longer exist and
>     >>
>     >
>     > The idea is to show error messages on launch failure?
>     >
>     > Ccing Eben, it was discussed recently and our feeling was that the
>     > icon disappearing from the home page was all the feedback we could
>     > give to the user. Displaying a "Activity blahblah cannot start."
>     would
>     > just be more intrusive without providing any additional information.
>     >
>     >
>     >> - Home view is brought to front
>     >>
>     >
>     > I guess I don't see why we should not use the normal startup
>     > notification in the case of an activity launching another one.
>     >
>     > Marco
>     >
>     I can understand the whole concept of giving some information without
>     giving all information being nothing but puzzling, but the whole
>     idea of
>     clicking on an icon that launches an Activity (remember you are
>     already
>     in an Activity, all be it a launcher one) just to get that
>     activity to
>     magically disappear and the Home view appearing with a flashing icon
>     stating that there is something going on, which may or may not be
>     related to the action the user took (clicking the icon to start an
>     activity) is a bit confusing.
>
>     Sure, once everyone knows by heart that the flashing icons in the home
>     circle are activities being launched and that particular icon
>     (remember
>     many more may be there) relates to the activity you just launched,
>     then
>     it's obvious and all, but isn't this 'obvious beacuase you learned
>     before' system what we try to avoid with sugar? Is it not more
>     intuitive
>     to click on the icon and, without more changes, getting the wait
>     cursor?
>     If you then press F3 you'll get to the home view, the flashing
>     icon will
>     be there, but that was your action.
>
>     I don't believe that having Launcher applications getting hid is a
>     good
>     thing, honestly.
>
>     About error notifications, well, the 'sorry, no can do' volatile
>     message
>     could be substituted by a red circle (we use circular 'bubbles' for
>     icons) but again, we are assuming red as the color for error, and
>     it's
>     not understood that way in some places, like china.
>
>
>     --
>
>     cn
>     _______________________________________________
>     Sugar mailing list
>     Sugar at lists.laptop.org <mailto:Sugar at lists.laptop.org>
>     http://lists.laptop.org/listinfo/sugar
>
>