Summary: | [Gtk][Regression] Keyboard shortcuts are taken from first item in "Input Source" instead of currently active input, thus breaking custom layouts (e.g Dvorak/Colemak/AZERTY) if it's not default layout. | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Leo Ufimtsev <lufimtse> |
Component: | SWT | Assignee: | Xi Yan <xixiyan> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | aaronwells, ansgar.radermacher, daniel_megert, Jean-Christophe.Weill, jmma.aubry, julius.lawson, jwhiting, neo+eclipse, p.scheid92, peter, platform-swt-inbox, xixiyan |
Version: | 4.8 | Keywords: | helpwanted, regression, triaged |
Target Milestone: | 4.10 M1 | ||
Hardware: | PC | ||
OS: | Linux | ||
See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=534580 https://git.eclipse.org/r/129573 https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=95e0cb1ec0942a6f24e42af56a2cb1c308d6d9b8 |
||
Whiteboard: |
Description
Leo Ufimtsev
2018-04-09 16:00:37 EDT
*** Bug 531378 has been marked as a duplicate of this bug. *** As the reporter of bug 532574 (closed as a duplicate), I answer the question I was asked by Alexander Kurtakov : I'm using Eclipse Oxygen.2 Release (4.7.2), Build id: 20171218-0600. Regards. I asked gtk folks if they know of a clean way to reparent gdk windows. If we can't find a good way, we might use gtk_reparent_widget(..) for photon and look for a better solution later. ###################################### Original mail to gtk-devs: Hello guys, gtk_widget_reparent () was deprecated in 3.14. It's suggested to use remove/add container instead. gtk_widget_reparent (..) was subsequently removed in gtk4. The problem with the suggested "removing/adding container" is that it doesn't reparent child's gDk windows. i.e: the method originally also reparented subwindows: GtkWidget.c: gtk_widget_reparent ( ) { g_object_ref (widget); gtk_container_remove (GTK_CONTAINER (priv->parent), widget); gtk_container_add (GTK_CONTAINER (new_parent), widget); g_object_unref (widget); ... gtk_widget_reparent_subwindows (widget, gtk_widget_get_parent_window (widget)); gtk_widget_reparent_fixup_child (widget, gtk_widget_get_parent_window (widget)); ... } If we only remove/add container (with g_object_ref(widget)), we get the error: '(Eclipse:17380): Gdk-WARNING **: gdk_window_new(): parent is destroyed' In the interest of future Gtk4 compatibility, other than manually implementing '*_subwindows()' and *_fixup_child', is there away to do a reparenting via api that also reparents gdk subwindows? Thank you for your help. Hi Leo, I think I missed a step here. Is the gtk reparenting issue causing our keyboard shortcuts malfunction? (In reply to Jean-Marie Aubry from comment #4) > Hi Leo, I think I missed a step here. Is the gtk reparenting issue causing > our keyboard shortcuts malfunction? Ops, I accidentally wrote the comment into the wrong bug. (I had multiple tabs open in my browser). The comment above was suppose to go into this bug: 534089 – [GTK3] Tabfolder setControl(..) breaks with a table that has composite controls. https://bugs.eclipse.org/bugs/show_bug.cgi?id=534089 Please ignore comment #3. I've experience the same bug using Dvorak on Ubuntu. Environment: Ubuntu 16.04 Ubuntu MATE 1.154, GTK 3.18.9 Oxygen.3a Release (4.7.3.a) Build id: 20180405-1200 It took me a while to realize the problem was the keyboard layout not being recognized! I actually came to the bug tracker looking for a bug about the Undo shortcut (Ctrl+z) toggling line comments. Which is, of course, because the Dvorak "z" key is the Qwerty "/" key. :) I actually had Dvorak at the top of the list of layouts in my Keyboard Preferences control panel, but Eclipse was mapping keyboard shortcuts to the second layout on the list: 1. "English (US) English (Dvorak)" 2. "Maori" [which is a Qwerty layout] As a workaround, I removed the other keyboard layout, so that Dvorak is my only active keyboard layout. (In reply to Aaron Wells from comment #6) > I've experience the same bug using Dvorak on Ubuntu. Thank you for your report. Always feel free to vote for bugs, we pay attention to these metrics when deciding which things to fix. I never noticed the issue originally because I use Colemak as my primary keyboard layout and don't really use other layouts. Further Colemak has similar shortcuts (Ctrl-Z/X/C). It's more noticeable on Dvorak. We should fix this thou. *** Bug 534580 has been marked as a duplicate of this bug. *** For me this also happens when the selected keyboard layout is the first input source. I have the following input sources set: 1. German (Neo 2) => XVLCW (weird) 2. German => QWERTZ 3. English (US) => QWERTY 4. English (UK) => QWERTY Output of `setxkbmap -query`: rules: evdev model: pc105 layout: de,de,us,gb variant: neo,,, It seems that the fallback is not the "normal" German layout, because the CTRL+Z shortcut is mapped to the position it would have on a QWERTY keyboard. So my first guess would be that it always falls back to the US layout if the first input is not recognized. For more information and log files see bug 534580 *** Bug 535204 has been marked as a duplicate of this bug. *** Returning bug back to queue as I'm transferring into Consulting. Might be something for Xi Yan to work on. This is a feature/bug of GNOME where the shortcut keybindings persists as the default one when changing layout. This behaviour affects all applications (gedit, terminal, ...), so I don't think there is anything we can fix. See the long discussion about it here: https://bugzilla.gnome.org/show_bug.cgi?id=162726 Hi Xi Yan. You wrote: "This behaviour affects all applications (gedit, terminal, ...)". But it was not the case for me: only Eclipse was impacted (gedit and the terminal were working fine). This bug is so massive when it hurts you that you can't pass through it: if it affects gedit (for instance) you can't ignore it. And the Gnome bug you point us to is closed as fixed for 2 years. Regards. (In reply to Julius LAWSON from comment #13) > Hi Xi Yan. > > You wrote: "This behaviour affects all applications (gedit, terminal, ...)". > But it was not the case for me: only Eclipse was impacted (gedit and the > terminal were working fine). This bug is so massive when it hurts you that > you can't pass through it: if it affects gedit (for instance) you can't > ignore it. > > And the Gnome bug you point us to is closed as fixed for 2 years. > > Regards. I confirm that all other applications are working fine (though I primarily use KDE) and that the bug is quite annoying. Please, do not close it as won't fix. (In reply to Xi Yan from comment #12) > This is a feature/bug of GNOME where the shortcut keybindings persists as > the default one when changing layout. This behaviour affects all > applications (gedit, terminal, ...), so I don't think there is anything we > can fix. See the long discussion about it here: > https://bugzilla.gnome.org/show_bug.cgi?id=162726 I can also confirm, that Eclipse and Eclipse-based applications like "DBeaver" are the only affected applications. All other applications work very fine. Please re-open or give good reasons not to do so. (In reply to Ansgar Radermacher from comment #16) > Please re-open or give good reasons not to do so. Thank you for your comment. Re-opening this ticket. I did some more investigation regarding this issue and found out: 1) On Fedora 28, shortcuts are always taken from 'primary layout (first item)' in Gedit/terminal/Eclipse, which was the case for me when I closed the ticket. 2) On Ubuntu (and likely many others), the shortcuts works fine with Gedit/terminal but not eclipse. 3) Using the following snippet, Text and StyledText behaves differently to copy/paste shortcuts. Under Dvorak, Ctrl-i & Ctrl-. shortcuts copy/paste in Text (expected behavior), but ctrl+c & ctrl+v shortcuts copy/paste in StyledText. This seems to be the same issue. ============================== Snippet ================================ public static void main (String [] args) { Display display = new Display (); Shell shell = new Shell(display); shell.setLayout(new FillLayout()); StyledText styledText = new StyledText(shell, SWT.BORDER); styledText.setText("StyledText"); Text text = new Text(shell, SWT.BORDER); text.setText("Text"); shell.open (); while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); } ================================================================ New Gerrit change created: https://git.eclipse.org/r/129573 Gerrit change https://git.eclipse.org/r/129573 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=95e0cb1ec0942a6f24e42af56a2cb1c308d6d9b8 (In reply to Eclipse Genie from comment #19) > Gerrit change https://git.eclipse.org/r/129573 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=95e0cb1ec0942a6f24e42af56a2cb1c308d6d9b8 In master now. This patch should fix the issue on X11, nothing can be done on Wayland afaict since it's an issue with gtk applications as well. Verified in I20180923-1800. |