Hi Manuel, On 17 Mar 2012, at 18:38, Manuel Quiñones wrote:
> El día 15 de marzo de 2012 10:48, Pablo Flores <[email protected]> escribió: >>> For B. either mallard (like GNOME does) or a wiki page can be used. >>> We can add a shortcut in the activities to open them. >> >> IIUC it would be a button that would open Browse with the activity's help >> pages, right? I like this idea. In this case, there should be for every >> activity a core documentation that keeps maintained and can be installed >> (for having help even being offline... and for being sure the documentation >> corresponds with the version of the activity and sugar that's being used). >> >> If we're going this way, having the wiki pages of activities updated would >> be a high priority when it comes to Sugar documentation (to be considered >> for the April's documentation sprint participants). It would also require >> this documentation to be updated every time a new version of the activity is >> developed with changes to the user experience (to be considered in the >> development cycles). > > Yeah, also see mallard, GNOME apps use that: > > http://projectmallard.org/ > >> BTW I'm afraid jumping into the browser when looking for help may be >> confusing for unexperienced users, but I don't have a proposed solution for >> this :( > > We should come with a real solution for opening one activity from > inside another, in a way that is not disturbing for the little user. > That is, we should ensure that she/he _wants_ to do it. I think I've mentioned this once before, but how about if we use the Sugar alert strip UI, much like we use it in Browse 'Show in Journal' when an object is downloaded? It would be something like a 'Start <object_title> with <default_activity>?' message. This would allow the user to Cancel if triggered by mistake (or maliciously/automatically), and mean the user is directly interacting with the dialogue to trigger the activity Start. It would need to be a new type of Sugar shell alert, I guess, for security (e.g. Sugar shell enforces the user interaction handover before the object is started by the new activity). Note that this generates a NEW activity object in the Journal each and every time an activity is used to launch another with an object. You would need to use the Journal (or home view) to resume an already created object if you didn't want another new instance generated (ideally the FS or datastore is/would be smart enough when identical unmodified objects are created to save storage space). Regards, --Gary > -- > .. manuq .. _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
