Menu
▾
▴
#6 OTRproxy alerts incorrectly display default buttons
[On OS X 10.3.9, otrproxy 0.2.0...]
When otrproxy displays dialogue boxes to the user, none of the
buttons in the dialogue box are initially responsive to keyboard input
such as "Enter". This is intended behavior (to prevent accidental
dismissal of the dialogue), and the buttons can be selected by
tab'ing to them, but the UI feedback is misleading.
When alert dialogue boxes are displayed, they show certain buttons
as highlighted, indicating that they can be activated via keyboard
input. This is not true. There is also no visible change once they do
become responsive to keyboard input if the user tab's to the button.
(The button remains highlighted, as it should be at that point.)
Fix: display the dialogue buttons initially non-highlighted, and only
highlight when they are triggerable by keyboard input.
Logged In: YES
user_id=113374
Does this still happen with the test version (for
multi-user) I sent you?
On gtk, this is what's happening:
- The "highlighted" button means that that's the one that
will be "clicked" if the user hits Enter (the "default
button"). The fact that the window doesn't have keyboard
focus doesn't affect this.
- If the user gives focus to the dialog, then Enter works to
"click" OK.
- This is consistent with what I expect from gtk apps.
If I don't make the button the "default button", then it's
not highlighted, but giving the dialog the keyboard focus
and pressing Enter has no effect.
I think you should be *able* to "click" OK by giving
keyboard focus to the window and pressing Enter.
Is what you're saying that OSX apps generally behave
differently from gtk apps, in that the "highlighted" button
in OSX means that *both* this is the "default button" *and*
this window currently has the keyboard focus?
Logged In: YES
user_id=29569
> Is what you're saying that OSX apps generally behave
> differently from gtk apps, in that the "highlighted" button
> in OSX means that *both* this is the "default button" *and*
> this window currently has the keyboard focus?
No, that is not what I am saying.
OS X apps should behave just as you say the gtk apps do. However,
otrproxy does not conform to this behavior.
What happens is this:
- The window appears without focus.
- The window is brought into focus, and the default button is highlighted,
but unresponsive to keyboard input.
- "Tab" is hit, and now, despite no visual feedback, the default button may
be triggered with "Enter".
The "Tab" step should not be required.
Logged In: YES
user_id=113374
It sounds like in step 2, you're actually bringing the *app*
into focus, not the individual window; then step 3 moves the
focus to the dialog box (away from whatever originally had
it, probably the "private connections" frame). Is that
consistent with what you're seeing? [I only have a vague
recollection of seeing how focus works in osx, so I ay be
way off here.]
Logged In: YES
user_id=29569
In step two, I am bringing the app into focus. The window is already in
focus within the app, so I am *also* bringing the window into focus.
Tabs do nothing to affect which window is in focus.