<div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">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.</blockquote> <blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"> 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? </blockquote><div> </div> <div>I think our main goal is one of consistency and simplified interactions.  One drawback of launchers is that each developer might implement it in a different way, removing consistency.  Arguing for a single "OLPC ordained" launcher seems moot, since the Journal already provides this in a generic and dynamic way.  Another drawback is the activity model, which basically assumes that an activity is all at once an "application" (activity) that is running in a single "window" (fullscreen) which represents a specific "file" (object).  We feel that this model makes strong connections between journal entries (and their versions) and the running instances in the mesh, makes the notion of sharing and scoping simpler to handle, and makes best use of the screen (which is small) while helping the kids focus on one thing at a time.  This model is completely new, and not what most developers expect, but we sincerely hope that it doesn't limit creative potential. </div><div> </div><div>As much as possible, for both consistency and simplicity, we're trying to avoid special casing things. Of course, we certainly can't assume that all activities will be sharable, but we also don't necessarily want to assume that they never could be.  Journaling is another issue, because as soon as certain activities don't journal there is no way to keep record of them, since this is essentially the saving mechanism.  This of course brings up the notion of activities which don't produce artifacts (files or objects).  One of our primary goals is creative expression, which of course encourages the creation of artifacts naturally. Certain activities, such as games, don't necessarily version, or have resultant "files" or objects at all historically, but a journal entry which indicates a running score tally ("you've won 5 of 8 chess matches") can still be interesting and useful as a history of the child's interactions with the laptop. </div> <blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">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 :)</blockquote><div> </div><div>This is all going to come down to community and feedback.  I'd really like to think that the models and rules we set up are an interesting point of departure for a wide variety of new and exciting activities. If, on the other hand, particular aspects of the system are proven severely limiting, we may need to reconsider them in light of both the problems or limitations they cause vs. the simplicity or consistency which they help preserve. </div><div> </div><div>Thanks for the feedback!</div><div> </div><div>- Eben</div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"> 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 > <a href="http://activity.info">activity.info </a> <<a href="http://activity.info">http://activity.info</a>> 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* <<a href="mailto:cn@sueste.net">cn@sueste.net</a> <mailto:<a href="mailto:cn@sueste.net">cn@sueste.net</a>>> wrote: > > > >     Marco Pesenti Gritti wrote: >     > On 8/14/07, Carlos Neves <<a href="mailto:cn@sueste.net">cn@sueste.net</a> <mailto:<a href="mailto:cn@sueste.net">cn@sueste.net</a>>> >     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 >     <a href="mailto:Sugar@lists.laptop.org">Sugar@lists.laptop.org</a> <mailto:<a href="mailto:Sugar@lists.laptop.org">Sugar@lists.laptop.org</a>> >     <a href="http://lists.laptop.org">http://lists.laptop.org</a>/listinfo/sugar > > </blockquote></div>