[haiku-development] Re: Variety of quit/save dialogs
- From: Jared Maddox <absinthdraco@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 15 Dec 2012 21:34:21 -0600
Sorry if I'm flubbing mailing-list etiquette in some way, I haven't
posted here before.
On 12/15/12, Humdinger <humdingerb@xxxxxxxxxxxxxx> wrote:
> Hi there!
>
> I've noticed that we use a variety of different quit/save dialogs in
> our apps.
<snip>
> The text of the alert isn't that much the issue, depending on the
> circumstances and the nature of the app, it can vary. I'm aiming at the
> labels and positions of the buttons below it.
>
> Here's my suggestion: Use "Don't save", "Cancel", "Save".
> - "Save" should be uncontested, right?
> - "Cancel" is most generic to abort an action.
> - "Don't save" is the obvious negation of "Save" and therefore even for
> people with only a rudimentary knowledge of English obvious in an
> instant.
<snip>
> I realize this may quickly turn into a bike shed, but how else can we
> determine one style of alerts? But maybe, who knows, everybody just
> showers me in +1s...
>
> Regards,
> Humdinger
>
Here's my bike-shed suggestion: instead of an explicit "File Save"
dialogue, a generic "File access" dialogue. The basic idea would be to
specify the buttons that you want, and the text that goes with it,
when you create the dialogue. The dialogue then gets constructed
accordingly.
With that, for a "Save File Before Exit" dialogue you call the
appropriate wrapper dialogue. At the same time, you can have another
wrapper that just has "Cancel" and "Save", created by another wrapper
function. If a particular program has it's own customized actions
(e.g. an IDE might have a "refresh" button to refresh a generated
non-native build file from the native equivalent) then it can
implement it's own wrapper while still keeping with the conventional
look & feel. If the number of buttons is too high for the space of the
file dialogue, then it switches to a "drop-down + select button"
method.
Other related posts:
