Hi Sergey, > I am not sure what does it meant "forget about Meta", if the code does not > care > about "altGr"/"meta/mouse_buttons" it should not use it as off/onnmask and as > a result it should ignore it. > BTW it is not missed in the JavaDoc: > https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#field.summary
That is I am talking about! Consider opposite point of view. If the code care about these buttons, your fix breaks the code, because Alt became AltGr unexpectedly. > > I believe that the example in the javadoc is not entirely correct. > > Why it is incorrect? Because on Mac it considers that Alt+F and Alt+Meta+F are equal. And junior developer will be surprised. > > > > On Sun, Mar 17, 2019 at 1:26 AM Sergey Bylokhov > > <sergey.bylok...@oracle.com> wrote: > >> > >> On 16/03/2019 03:58, Sergey Malenkov wrote: > >>> Your example is synthetic and shows a problem in the one specific > >>> case. I think if you introduce new mask, you have to use it in your > >>> example too. If you add ALT_GRAPH_DOWN_MASK to 'offmask' your example > >>> will not work (that's how processed all shortcuts in Swing and IDEA). > >>> If you add it to 'onmask' the KeyEvent(new Button(), 0, 0, > >>> ALT_GRAPH_DOWN_MASK, 0) will not work. > >> > >> Your example is good as well, but it shows the opposite, if > >> ALT_GRAPH_DOWN_MASK was used as "onmask" or as "offmask" then it means > >> that this example tries to take care about altGr and it only > >> properly works after the fix. And if the code is unaware about the altGr > >> flag as in previous example it will be ignored. > >> > >>> Am I right that to support your specific case you have to find and fix > >>> all Alt-based shortcuts in Swing, we should fix all Alt-based > >>> shortcuts in all keymaps in our IDEs and we should notify all our > >>> users that they have to fix all Alt-based shortcuts in their custom > >>> keymaps? The brilliant example of backward compatibility! > >> > >> I do not remember all changes which were integrated since initially it was > >> done > >> ~4 years ago. But Swing was updated by some changes after that, for > >> example: > >> https://bugs.openjdk.java.net/browse/JDK-8194873 > >> > >>> > >>>> So if the client will follow the spec below it should work as before, > >>>> isn't it?: > >>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx() > >>> > >>> If a developer use this method as described his code will be broken > >>> too, because good and attentive developer definitely added > >>> ALT_GRAPH_DOWN_MASK to 'offmask'. > >> > >> If the user wants to ignore all combinations with "Alternate Character Key" > >> then, as you pointed in the start of this thread, he should ignore both > >> "alt" since on macOS both alt keys are "Alternate Character Key". > >> > >>> > >>> On Sat, Mar 16, 2019 at 1:27 AM Sergey Bylokhov > >>> <sergey.bylok...@oracle.com> wrote: > >>>> > >>>> On 15/03/2019 05:54, Sergey Malenkov wrote: > >>>>> We have a major issue about unexpected AltGr in the keyboard layout > >>>>> that should not have AltGr at all: > >>>>> http://youtrack.jetbrains.com/issue/IDEA-206348 > >>>>> Why you decided to support AltGr for every keyboard layout? It really > >>>>> breaks backward compatibility! > >>>> > >>>> Even in your bug report the people complain that altGr key does not > >>>> work, and > >>>> the only problem here is that it does not assigned by default. > >>>> But on the other side it is possible to set separate shortcuts > >>>> to the "Alt + Alt Graph + Enter"and "Alt + Enter": > >>>> > >>>>> I think the main client is Swing and pressed AltGr that looks like > >>>>> 'Alt+AltGr+' breaks all Alt-based shortcuts defined in > >>>>> javax.swing.plaf.basic.BasicLookAndFeel#initComponentDefaults and > >>>>> other places. Now, if you press "alt LEFT", the "moveColumnLeft" > >>>>> action is performed only for the left Alt. And this also breaks a > >>>>> backward compatibility. > >>>> > >>>> The term "all" is not so critical, there are only few such shortcuts, > >>>> and it is > >>>> a good thing that potentially we can set different shortcuts for each. > >>>> This is a bug that these places were not updated, it is easy to fix > >>>> since this > >>>> is not exposed via public API. > >>>> But we will get the same result if we will use the AltGr mask only. > >>>> > >>>>> It is not backward compatible to use AltGr instead of right Alt in > >>>>> both cases. Instead of 'Alt+key' you will get 'AltGr+key' or > >>>>> 'Alt+AltGr+key', which are not bound to any action. > >>>> > >>>> It is compatible to the specification of InputEvent.getModifiersEx(): > >>>> KeyEvent event = new KeyEvent(new Button(), 0, 0, > >>>> ALT_DOWN_MASK | ALT_GRAPH_DOWN_MASK, 0); > >>>> int onmask = ALT_DOWN_MASK; > >>>> int offmask = CTRL_DOWN_MASK|SHIFT_DOWN_MASK; > >>>> if ((event.getModifiersEx() & (onmask | offmask)) == onmask) { > >>>> ... > >>>> } > >>>> > >>>> The code above works before and after the change for altGr. > >>>> But it will stop working if we will use altGr only, and it will be hard > >>>> to argue > >>>> why the ALT flag is not set while alt key is pressed(since on some > >>>> keyboards this key is > >>>> marked as alt and on some other altGr). > >>>> > >>>> And as specially noted in the method above the code should not assume > >>>> which > >>>> flags(and how many) were set by the actions, if such assumptions exists > >>>> in > >>>> Swing itself they should be fixed as well. > >>>> > >>>>> > >>>>> On Fri, Mar 15, 2019 at 9:27 AM Krishna Addepalli > >>>>> <krishna.addepa...@oracle.com> wrote: > >>>>>> > >>>>>> Hi Sergey Malenkov, > >>>>>> > >>>>>>> 'Alt+AltGr+Right' does nothing, because we do not assign this > >>>>>>> shortcut yet > >>>>>> In my personal experience, I did not find any instance, wherein a > >>>>>> shortcut had left and right alt in it. > >>>>>> Although it is not impossible, it seems weird to define such shortcuts. > >>>>>> It would be helpful if you could point to some resources, wherein > >>>>>> defining such shortcuts is acceptable. > >>>>>> > >>>>>> Thanks, > >>>>>> Krishna > >>>>>> > >>>>>>> On 14-Mar-2019, at 4:03 PM, Sergey Malenkov <malen...@gmail.com> > >>>>>>> wrote: > >>>>>>> > >>>>>>> I strongly don't like two masks for one key. If you press VK_ALT, > >>>>>>> ALT_DOWN_MASK should be set. If you press VK_SHIFT then, > >>>>>>> SHIFT_DOWN_MASK should be added to indicate that both keys are > >>>>>>> pressed. And if you press VK_ALT_GRAPH, only ALT_GRAPH_DOWN_MASK > >>>>>>> should be added. Otherwise, you can't distinguish the following key > >>>>>>> strokes: 'AltGr+Right' and 'Alt+AltGr+Right'. But these keystrokes are > >>>>>>> different and should invoke different actions. For example, > >>>>>>> 'Alt+Right' moves cursor to the next word > >>>>>>> 'Alt+Shift+Right' moves cursor to the next word AND adds all skipped > >>>>>>> characters to selection > >>>>>>> 'Alt+AltGr+Right' does nothing, because we do not assign this > >>>>>>> shortcut yet > >>>>>>> > >>>>>>> On Thu, Mar 14, 2019 at 12:09 AM Sergey Bylokhov > >>>>>>> <sergey.bylok...@oracle.com> wrote: > >>>>>>>> > >>>>>>>> On 13/03/2019 03:59, Sergey Malenkov wrote: > >>>>>>>>> I missed the "for ALT keys" in the bug title and thought that > >>>>>>>>> "KeyEvent.getModifiers() returns inconsistent values" was about > >>>>>>>>> incompatible behaviour on different platforms. In fact, JDK-8218917 > >>>>>>>>> should be renamed to something like “The right Alt key on Mac should > >>>>>>>>> behave as Alt and must not break the left Alt key processing”. > >>>>>>>> > >>>>>>>> But the "right Alt" should behave like a "left alt" already, it > >>>>>>>> should use both flags: > >>>>>>>> the common alt(ALT_DOWN_MASK) and the altGr(ALT_GRAPH_DOWN_MASK). > >>>>>>>> > >>>>>>>> So if the client will follow the spec below it should work as > >>>>>>>> before, isn't it?: > >>>>>>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx() > >>>>>>>> > >>>>>>>>> On Wed, Mar 13, 2019 at 6:57 AM Sergey Bylokhov > >>>>>>>>> <sergey.bylok...@oracle.com> wrote: > >>>>>>>>>> > >>>>>>>>>> On 12/03/2019 12:28, Sergey Malenkov wrote: > >>>>>>>>>>> Hi Sergey, > >>>>>>>>>>> > >>>>>>>>>>> 1. macOS uses a regular Alt key as "Alternate Character Key". > >>>>>>>>>>> This is > >>>>>>>>>>> the reason why JDK Toolkit defines Ctrl+Alt to select a mnemonic, > >>>>>>>>>>> instead of simple Alt. See > >>>>>>>>>>> https://sites.google.com/site/malenkov/java/141229 > >>>>>>>>>> > >>>>>>>>>> Right, but introducing this flag for the "left alt" could cause > >>>>>>>>>> even more > >>>>>>>>>> issues, so this flag is set only for the right. > >>>>>>>>>> > >>>>>>>>>>> 3. Regression was caused by adding AltGr to key processing on > >>>>>>>>>>> Mac. But > >>>>>>>>>>> I found more issues with inconsistent key processing on different > >>>>>>>>>>> platforms. See http://sites.google.com/site/malenkov/java/190312 > >>>>>>>>>> > >>>>>>>>>> Not sure that CAPS_LOCK is related. > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Tue, Mar 12, 2019 at 4:17 AM Sergey Bylokhov > >>>>>>>>>>> <sergey.bylok...@oracle.com> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> On 11/03/2019 17:37, Philip Race wrote: > >>>>>>>>>>>>> The debate is about AltGraph which an ancient MS-DOSism for > >>>>>>>>>>>>> asking for an ALTernate GRAPHics bitmap font - all pre-dates > >>>>>>>>>>>>> windows > >>>>>>>>>>>>> and I am sure has never been applicable to any MacOS. > >>>>>>>>>>>> > >>>>>>>>>>>> It also about the "right alt" which is also know as "AltGraph". > >>>>>>>>>>>> I guess currently > >>>>>>>>>>>> it is implemented as "right alt" on Linux/macOS/windows. > >>>>>>>>>>>> > >>>>>>>>>>>> BTW on linux it is also named as "Alternative Characters Key": > >>>>>>>>>>>> https://help.ubuntu.com/community/ComposeKey > >>>>>>>>>>>> > >>>>>>>>>>>>> So someone needs to properly explain why we would claim a Mac > >>>>>>>>>>>>> keyboard > >>>>>>>>>>>>> is OK to generate a keycode it doesn't have and cause a slew of > >>>>>>>>>>>>> regressions > >>>>>>>>>>>>> in the process ...> > >>>>>>>>>>>>> If Mac doesn't distinguish these two, we should generate the > >>>>>>>>>>>>> same keycode for both. > >>>>>>>>>>>> > >>>>>>>>>>>> The macOS supports "right alt", otherwise it would not be > >>>>>>>>>>>> possible to implement it in java: > >>>>>>>>>>>> https://developer.apple.com/library/archive/technotes/tn2450/_index.html > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> One could suppose there is a difference else why two keys, but > >>>>>>>>>>>>> what is the right > >>>>>>>>>>>>> thing to do here that fixes all the problems. What exactly WAS > >>>>>>>>>>>>> the problem > >>>>>>>>>>>>> with what was there in the first place ? And if changing it is > >>>>>>>>>>>>> correct why is it > >>>>>>>>>>>>> causing regressions ? > >>>>>>>>>>>> > >>>>>>>>>>>> Regressions were caused by the bugs in the fix implementation, > >>>>>>>>>>>> or am I missed something? > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> -phil. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 3/12/19, 5:34 AM, Sergey Bylokhov wrote: > >>>>>>>>>>>>>> Hi, Phil. > >>>>>>>>>>>>>> On 11/03/2019 07:43, Philip Race wrote: > >>>>>>>>>>>>>>> The reasoning that AltGraph might be useful to someone is a > >>>>>>>>>>>>>>> bit weak > >>>>>>>>>>>>>>> and I don't think I'd want to support it via system property > >>>>>>>>>>>>>>> or build options. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> If its not a platform keyboard key, why do we need it ? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The "AltGraph" key is also commonly referred to as "Right > >>>>>>>>>>>>>> Alt", and > >>>>>>>>>>>>>> it has been implemented on all platforms as a "Right Alt", it > >>>>>>>>>>>>>> is convenient to > >>>>>>>>>>>>>> distinguish the left/right alts. > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> -- > >>>>>>>>>>>> Best regards, Sergey. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> Best regards, Sergey. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Best regards, Sergey. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Best regards, > >>>>>>> Sergey A. Malenkov > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> -- > >>>> Best regards, Sergey. > >>> > >>> > >>> > >> > >> > >> -- > >> Best regards, Sergey. > > > > > > > > > -- > Best regards, Sergey. -- Best regards, Sergey A. Malenkov
