I had a conversation about this earlier in the year and will post it here in case it's helpful:
> 1. If a button has focus, Enter key should click the button (like it does on Windows). Currently Enter key always actions the default button on a dialog, even if another button has focus. Most people don’t use Space bar to click a button, so this is confusing. My response 1: This might be confusing but it is the standard, even on Windows, but on Windows the default push button moves as focus moves from push button to push button but when focus moves to a non-pushbutton then the default (solid border) reverts back to one of the push buttons, usually the OK button. On Mac the default push button typically remains the same as focus moves from push button to push button. There is some info about Win behavior here https://support.microsoft.com/en-us/kb/126449 which says: SPACEBAR: If the current control is a button, this clicks the button. ENTER: Equivalent to clicking the selected button (the button with the outline) On Mac there is this: https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/WindowDialogs.html which says: Usually the rightmost button or the Cancel button is the default button. A default button has color to let users know that when they press Return or Enter, the default button is activated. FX follows the Mac UX guidelines. Keyboard users, e.g. blind users, are aware of this behavior. My response 2: I was thinking about this some more. I think FX should consider more closely matching Win behavior when running on Win, e.g. moving the blue background (default) from push button to push button when focus is on a push button. Regarding the prior notes in this thread, some comments: Assuming current Mac-like behavior where the default button doesn't move to the focused button, I'm pretty sure I read in a Mac UX document that the Cancel button should be made the default for the case where someone inadvertently used Enter instead of Spacebar, backed up by an Are you sure? message box (if useful information is going to be discarded). I'm not keen on a command line option to change behavior. That will confuse users who are expecting the app to behave like other apps on a particular platform. Pete On 6/7/16 6:33 PM, Tomas Mikula wrote: > On Tue, Jun 7, 2016 at 7:08 PM, Michael Berry <berry...@gmail.com> wrote: > >> On 7 June 2016 at 23:57, Tomas Mikula <tomas.mik...@gmail.com> wrote: >> >>> >>> On Tue, Jun 7, 2016 at 6:48 PM, Michael Berry <berry...@gmail.com> wrote: >>> >>>> On 7 June 2016 at 23:30, Tomas Mikula <tomas.mik...@gmail.com> wrote: >>>> >>>>> >>>>> On Tue, Jun 7, 2016 at 6:10 PM, Michael Berry <berry...@gmail.com> >>>>> wrote: >>>>> >>>>>> On 7 June 2016 at 23:04, Tomas Mikula <tomas.mik...@gmail.com> wrote: >>>>>> >>>>>>> What about forgetting the whole notion of a "default button" and the >>>>>>> only >>>>>>> effect of setting the default property to true being that the button >>>>>>> will >>>>>>> start as focused? >>>>>>> >>>>>>> So I add a question: >>>>>>> >>>>>>> 3) Would anyone miss the "default button"? >>>>>>> >>>>>> Afraid I would - I find the visual difference of the default button >>>>>> rather useful. >>>>>> >>>>> The visual difference is also what is confusing when there is also a >>>>> focused button. Maybe they should then lose its visual distinction when a >>>>> different button is focused (at least in Jonathan's point 2) - non-OS >>>>> X platforms). >>>>> >>>> Perhaps this is just a pure difference of opinion - I find the visual >>>> distinction helpful because it provides a cue (from a UX perspective) as to >>>> which button the user can be expected to hit in "normal" behaviour. This, >>>> in my mind, is very different from the (much more subtle) cue that shows >>>> the currently focused UI component. >>>> >>> If Jonathan's plan is executed: >>> >>>> 2) On non-OS X platforms, we change the behavior so that Enter (and >>> Space) will fire the _focused_ key, if one is focused. >>> >>> then any visual cues on the "default" button are misleading (while a >>> different button is focused, that is), since it will not be triggered on >>> either Enter or Space. >>> >> Not necessarily. You're assuming (rightly or wrongly) that the visual cue >> here creates the expectation that a particular key, either enter or space, >> should activate it. >> > That was my assumption, indeed. And I wonder how many users make the same > assumption. > > >> In my case, the visual cue simply indicates that it is the preferred, >> default, or most common option for a user to press, without implying a >> relation to any particular hotkey. >> >> >>> Tomas >>> >>> >>>> >>>>> Tomas >>>>> >>>>> >>>>>> While it would be possible to just use CSS to style it differently, >>>>>> this (in my mind) would be a step backwards (and that's before the issues >>>>>> that would arise from a backwards-compatibility standpoint due to >>>>>> removing >>>>>> an existing property.) >>>>>> >>>>>> Michael >>>>>> >>>>>> >>>>>>> Tomas >>>>>>> >>>>>>> On Tue, Jun 7, 2016 at 5:47 PM, Jonathan Giles < >>>>>>> jonathan.gi...@oracle.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> One thing I've been looking into recently is the issue of what the >>>>>>> Enter >>>>>>>> key should do when it is pushed with regards to buttons in a UI >>>>>>> where one >>>>>>>> of those buttons is a 'default' button. There are number of Jira >>>>>>> issues on >>>>>>>> this topic, and I wanted to poll the community to understand its >>>>>>> opinions. >>>>>>>> The current situation is that the Enter key does not fire the >>>>>>> focused >>>>>>>> Button. The Enter key is reserved for firing the 'default' Button >>>>>>> in the UI >>>>>>>> (i.e. if someone has created a Button instance with the default >>>>>>> property >>>>>>>> set to true). A default button is rendered slightly differently (in >>>>>>> Modena >>>>>>>> it is blue for example). To fire the focused Button, the user must >>>>>>> press >>>>>>>> the Space key. >>>>>>>> >>>>>>>> Tom Schindl filed a bug (JDK-8139510) that is a good example of the >>>>>>>> 'problem' this creates. In the bug report, a dialog is shown to the >>>>>>> user. >>>>>>>> In the dialog is an OK button and a Cancel button. The OK button >>>>>>> has been >>>>>>>> made the 'default' button. Regardless of which button has focus, >>>>>>> the Enter >>>>>>>> key always fires the OK button. The only way to fire the Cancel >>>>>>> button is >>>>>>>> via the Space key. This can be very confusing for users who have >>>>>>> tabbed >>>>>>>> specifically to the 'Cancel' button and then pressed the Enter key, >>>>>>> only to >>>>>>>> find they unwittingly fired the 'OK' action. >>>>>>>> >>>>>>>> To me this has always been a little counter-intuitive, because of my >>>>>>>> heritage as a long-time Windows user. I believe Linux is much the >>>>>>> same as >>>>>>>> Windows. For others who grew up on Mac, I'm less sure on what >>>>>>> people expect >>>>>>>> (but it seems to be that the Enter key fires the default button, >>>>>>> not the >>>>>>>> focused button, i.e. JavaFX current behavior matches what is >>>>>>> expected on OS >>>>>>>> X). >>>>>>>> >>>>>>>> What I'm proposing we do is to change the behavior as follows: >>>>>>>> >>>>>>>> 1) On OS X we do not change behavior at all - we keep the current >>>>>>> 'Enter >>>>>>>> means default' and 'Space means focus' semantics. >>>>>>>> >>>>>>>> 2) On non-OS X platforms, we change the behavior so that Enter (and >>>>>>> Space) >>>>>>>> will fire the _focused_ key, if one is focused. If no Button is >>>>>>> focused >>>>>>>> (e.g. focus is in a TextField, etc), then Enter will work as it >>>>>>> currently >>>>>>>> does and fire the default button, if one is specified. In short, >>>>>>> default >>>>>>>> buttons will still be rendered blue to hint to the user that they >>>>>>> are the >>>>>>>> default button, but they will be less prevalently fired by Enter key >>>>>>>> presses - only when they also have focus. >>>>>>>> >>>>>>>> The two questions that I have are: >>>>>>>> >>>>>>>> 1) Will this confuse users when there is a behavior change (and >>>>>>>> presumably, this change will be made in JDK 9 and not backported to >>>>>>> JDK 8). >>>>>>>> If it will confuse users, is it still the right thing to do? >>>>>>>> >>>>>>>> 2) Do we want to have different behaviors for OS X and non-OS X? >>>>>>> I'm a >>>>>>>> newly inducted member into the cult of Mac, and I don't yet have >>>>>>> all my >>>>>>>> bearings sorted out, so I don't have a strong opinion here. >>>>>>>> >>>>>>>> Your thoughts, as always, are appreciated. >>>>>>>> -- Jonathan >>>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thanks, >>>>>> >>>>>> Michael >>>>>> >>>>>> >>>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> >>>>>> Virus-free. >>>>>> www.avast.com >>>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> >>>>>> <#m_130544982301072256_m_1455100482491084454_m_-8105136466737180413_m_1700382838741580870_m_-3404683945119215455_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >>>>>> >>>>> >>>> >>>> -- >>>> Thanks, >>>> >>>> Michael >>>> >>> >> >> -- >> Thanks, >> >> Michael >>
