[Chandler-dev] Proposal for a startup-options dialog
heikki at osafoundation.org
Wed May 17 14:21:54 PDT 2006
Alec Flett wrote:
> Bryan Stearns wrote:
>> It's not supposed to be a be-all-end-all of crash recovery mechanisms,
>> and I don't think we should bother reorganizing the startup code to
>> support retrying after a failure (at least, not right now - further
>> improvements could be designed and prioritized like anything else we
>> do). There's clearly more that could be done at startup, but that's
>> beyond the intent of my proposal.
By the way, the feedback reporting part of your proposal is something I
am working on during alpha2, aka talkback (although we might need
another name for various reasons). See
> +1 - Bryan's solution is an excellent one to a frustrating problem. It's
> not meant to be discoverable, its not meant to be accessible (though it
> is, meta keys are perfectly accessible)
The reason I suspect it might not be accessible is because you either
need to hold down one key while clicking another, or first click
something then quickly hold down another. Both of these can be
problematic for people with certain disabilities.
> Heikki wrote:
>> - I think we should consider automatically discovering UI data problem
>> and resetting it (or just automatically resetting in case of an unknown
> We're not in a state where we can detect what problems are UI related,
> nor is the refresh-ui option even functional at the moment. I feel a
If it is not detectable we could just do it unconditionally.
But I am confused about your statement that refresh-ui is not functional
at the moment... Bryan's proposal included that option in the dialog,
did it not? So either asking the user to do it or doing it automatically
isn't that big a difference in code.
> little bit like the argument for "discovering UI data problems and
> resetting it" is like saying "we should detect crashes, and then not
> crash just before we would have crashed" - sure maybe these are
Not at all. I am assuming we can/could identify an area of the
repository that contained UI data, and if during load of that portion we
encountered a problem we could reset that portion of the repository. If
neither detection nor reset of that portion is going to be feasible then
we can stop talking about that either via automatic mechanism or asking
the user if they'd like it to be done.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20060517/d14f9832/signature.pgp
More information about the chandler-dev