Re: storing Activity parameters
On Sun, Mar 2, 2008 at 1:51 PM, Gary C Martin [EMAIL PROTECTED] wrote: I'm having some indecision about my own (very simple) activity state saving. Just had a though that may add another possibility to this thread. What if both journal and file-system were used to store the activity state, with the journal settings overriding the file-system settings. This way a new activity start-up could inherit the last used activity settings, and a specific journal start-up would inherit the settings used for that specific entry. So in the case of Speak I could have separate favourite journal entries for '3 eyed alien' and another for 'Mr square eyes', then if I also just started the activity from fresh I'd pick-up whatever the last used setting were (picked up from the FS). I like this idea a lot. Thanks for sharing. [...] On 2 Mar 2008, at 01:29, Joshua Minor wrote: I implemented the save/load feature of Speak without fully understanding the other options. Now that I've seen the recent discussion about data vs instance vs the journal I think it would make more sense to have Speak save its state in a different way. On the other hand, the new frame redesign makes it much easier to resume an Activity, which would mean that parameters saved to the Journal, like Speak does now, would naturally be restored when you resume the Activity. A nice best practices document would be very handy. Yeah, storing some settings both in the fs and in the datastore would be suggested by these best practices document. Any activity author would like to start it? I'm sure many interesting discussions will come from this effort. Thanks, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: storing Activity parameters
I'm having some indecision about my own (very simple) activity state saving. Just had a though that may add another possibility to this thread. What if both journal and file-system were used to store the activity state, with the journal settings overriding the file-system settings. This way a new activity start-up could inherit the last used activity settings, and a specific journal start-up would inherit the settings used for that specific entry. So in the case of Speak I could have separate favourite journal entries for '3 eyed alien' and another for 'Mr square eyes', then if I also just started the activity from fresh I'd pick-up whatever the last used setting were (picked up from the FS). My Moon activity isn't complicated enough (just 2 key/value pairs so far) to make this much of a time saver, but for my planned Earth activity (a port of EarthGlobe, a Mac desktop app I wrote a few years back), I'd want to make use of shared location tagging (basically lon/ lat markers attached to some metadata) and some more detailed custom user settings that a user would not want to make each time. So the more detailed user settings (default location, some basic info/notes, viewing preferences) would be best going to the FS, and any tagged locations would go to the journal (so you could have different sessions for making different sets of geotags). I guess in this Earth case though there is a more clear separation between settings, and activity data. You'd (likely) want just one set of global settings for your details, while using the journal to store separate sets of tags - though I guess if you change location frequently you might want a journal entry for each location* Hm *probably a low usage case for our target audience. On 2 Mar 2008, at 01:29, Joshua Minor wrote: I implemented the save/load feature of Speak without fully understanding the other options. Now that I've seen the recent discussion about data vs instance vs the journal I think it would make more sense to have Speak save its state in a different way. On the other hand, the new frame redesign makes it much easier to resume an Activity, which would mean that parameters saved to the Journal, like Speak does now, would naturally be restored when you resume the Activity. A nice best practices document would be very handy. -josh ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: storing Activity parameters
I implemented the save/load feature of Speak without fully understanding the other options. Now that I've seen the recent discussion about data vs instance vs the journal I think it would make more sense to have Speak save its state in a different way. On the other hand, the new frame redesign makes it much easier to resume an Activity, which would mean that parameters saved to the Journal, like Speak does now, would naturally be restored when you resume the Activity. A nice best practices document would be very handy. -josh On Mar 1, 2008, at 11:23 AM, Mikus Grinbergs wrote: There has been discussion of the use of the Journal, versus other places, to store information associated with an Activity. What I've noticed is that some Activities are now storing their parameters in the Journal. For instance, I prefer to change the shape of the eyes in 'Speak'. If I launch 'Speak' from the menu frame, it shows the default eye shape. If I launch 'Speak' from the Journal, it shows the eye shape I specified earlier. Personally, I would prefer having Activities store user-specified overrides someplace other than in the Journal. Then when a new 'instance' of the Activity gets invoked, it can come up looking the way the user likes it, not just with its built-in appearance. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
