[Chandler-dev] Proposal for a startup-options dialog

[Alec Flett]

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.
>
+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)

Heikki wrote:
> - I think we should consider automatically discovering UI data problem
> and resetting it (or just automatically resetting in case of an unknown
> problem)
>
>   

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 
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 
possibilities down the road, (yes, even in the actual crashing case) but 
its just not feasible to invest the resources towards the larger more 
abstract problem of "UI related problems", especially when Bryan has 
proposed (and mostly implemented...) such a focused, practical solution 
for the near term.

Alec


> ...Bryan
>
> Heikki Toivonen wrote:
>> Andi Vajda wrote:
>>   
>>> I recently had a similar debate with Heikki about this. While having a
>>> goal of no repository failures or chandler bugs in general is a laudable
>>> one, preventing one from recovering from a failure when it happens is
>>> shooting oneself in the foot.
>>>     
>>
>> We discussed the need of shipping command line db utility executables by
>> default. Ok for now, but not in the long run.
>>
>>   
>>> I sure don't want anyone to complain that Chandler sucks hugely because
>>> we removed all the recovery facilities just because "they should never
>>> be needed".
>>>     
>>
>> You are ignoring the rest of what we discussed. We should have Chandler
>> automatically recover everything that can be automatically recovered.
>> And for the cases where user needs to make a decision, put up some
>> helpful startup dialog along the lines Bryan suggested below. Further, a
>> situation where a user interaction is required should be extremely rare.
>>
>> Finally, we shouldn't ship utility/functionality in the default
>> installers that, say, one in a million would find useful. It is
>> perfectly ok to create some optional power user utilities and have them
>> as separate downloads. And I said if nothing else, I'll do those myself
>> by hand if needed.
>>
>>   
>>> On Mon, 15 May 2006, Bryan Stearns wrote:
>>>     
>>>> I propose we add a mechanism to put up a dialog on startup if the user
>>>> is holding down a metakey (to be named later; we can figure one out
>>>> that works on all platforms and doesn't interfere with basic
>>>> application launching); this dialog would offer this radio-group of
>>>> choices;
>>>>       
>>
>> I agree this dialog would be useful. However, I disagree with the
>> metakey for a few reasons:
>>
>> - it is not discoverable
>> - it might be a problem with accessibility, but I don't really know for sure
>> - I think we should consider automatically discovering UI data problem
>> and resetting it (or just automatically resetting in case of an unknown
>> problem)
>>
>> I propose that we just put up the dialog automatically when we
>> encountered problems during startup.
>>
>>   
>
> ------------------------------------------------------------------------
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20060517/5e2e0e92/attachment.html