[sugar] frame auto-visibility configuration
Wed Sep 24 12:44:08 EDT 2008
On Wed, Sep 24, 2008 at 12:37 PM, Erik Garrison <erik at laptop.org> wrote:
> On Wed, Sep 24, 2008 at 12:25:43PM -0400, Eben Eliason wrote:
>> On Wed, Sep 24, 2008 at 12:18 PM, Erik Garrison <erik at laptop.org> wrote:
>> > On Wed, Sep 24, 2008 at 11:25:51AM -0400, Eben Eliason wrote:
>> >> On Wed, Sep 24, 2008 at 10:52 AM, Erik Garrison <erik at laptop.org> wrote:
>> > By "saving" I mean that changes in activity state trigger
>> > Activity.save(). This hits jffs2 and the NAND.
>> Sure, as Tomeu says, we could add a dirty bit. Of course, it seems
>> that the Frame-based solution should actually be preventing this
>> (given a long enough delay on revealing the activity window, or not
>> revealing until releasing alt-tab), since the activities don't even
>> get focused at all immediately. Only those you pause or stop on
>> should be doing any saving of state, and even then only if needed.
> How long of a pause or stop triggers auto-save?
> We could also save on user idle. Say, when the user is idle for more
> than 5 seconds and we haven't saved in the last 2 minutes. Or we could
> just auto-save every N minutes. Both of these options would decouple
> CPU-intensive actions from user intervention, with the effect of
> improved system responsiveness.
We could certainly try both of these. To clarify my point above, the
basic rule was to auto-save at the activity's discretion (likely when
dirty and N minutes have passed, and or idle) and when switching
/away/ from the activity (and also dirty). My point, basically, is
that we shouldn't be giving windows focus while we're still tabbing,
in which case we never "leave" any activity we tab past, because we
never "went into" it. Perhaps we can acheive the same effect without
the Frame, but I'm not sure. The only activity which should do any
saving during a tabbing operation, really, is the one we left when
> Sugar mailing list
> Sugar at lists.laptop.org
More information about the Sugar-devel