I've assigned "BackSpace" to "Open Parent" instead of "Back" using GTK+ function of hot-key reassign and now when I try to erase any symbol in "Address bar" ("Location selector" -> "Toolbar style") using "BackSpace" thunar fires "Open Parent" instead of deleting previous symbol.
*** Bug 7242 has been marked as a duplicate of this bug. ***
*** Bug 9797 has been marked as a duplicate of this bug. ***
Problem: ======== GTK priorizes accelerators by default with the highest priority. Solution: ====== Set a "hook" before accelerators are processed and invert the priority. How do others do it? ============= - Nautilus: Inverts the priority, if the currently focussed widget is GTK_IS_EDITABLE - Nemo: Inverts the priority, if the currently focussed widget is GTK_IS_EDITABLE - Caja: As Caja seems too difficult to build, I couldn't figure it out.
Problem: ======== GTK priorizes accelerators by default with the highest priority. Solution: ====== Set a "hook" before accelerators are processed and invert the priority. ( This will also help this bug: https://bugzilla.xfce.org/show_bug.cgi?id=13680 in regard of accelerators ) How do others do it? ============= - Nautilus: Inverts the priority, if the currently focussed widget is GTK_IS_EDITABLE - Nemo: Inverts the priority, if the currently focussed widget is GTK_IS_EDITABLE - Caja: As Caja seems too difficult to build, I couldn't figure it out.
@Nautilus: Found in nautilus-window.c within the function nautilus_window_key_press_event(...) Link to code: https://github.com/GNOME/nautilus/blob/mainline/src/nautilus-window.c#L2506 @Nemo: Found in nemo-window.c within the function nemo_window_key_press_event(...) Checking more detailed on Nautilus, I couldn't find a good reason to use the GTK_IS_EDITABLE-check or even asking for the currently focused widget (asking in #nautilus and checking git logs). My guess is, there is no particular reason. Maybe someone was concerned about processing speed?
Created attachment 9830 patch for xfce4.14 branch This patch is the implementation of my suggestion for branch xfce-4.14
Created attachment 9831 patch for alexxcons' 45s branch This patch is the implementation of my suggestion for alexxcons' branch 45 ( https://github.com/alexxcons/thunar/branches ). However, it probably works for subsequent branches of the GtkActionEntry-removal, as well.
(In reply to DarkTrick from comment #6) > Created attachment 9830 > patch for xfce4.14 branch > > This patch is the implementation of my suggestion for branch xfce-4.14 Works very nice for me, excellent research ! Fixes this bug and Bug #13680 for me. Only flaw I found so far: The shortcut for "open new window", CTRL+N seems not to work any more. Seems like instead the next item is selected. Possibly CTRL+N is already used in exo, though so far that "feature" was hidden :) All other shortcuts still work fine for me, no matter where the focus is .
Created attachment 9835 patch for alexxcons45's branch This patch should fix, that other accelerators stopped working. We're now very close to the nautilus implementation. I left a big comment in the code, so people actually know, why GTK_IS_EDITABLE is needed. I'd love to get feedback on this one.
Created attachment 9836 patch for xfce4.14 <Same as above>
Created attachment 9838 patch for alexxcons' 45s branch applied coding style
Created attachment 9839 patch for xfce4.14 applied coding style
(In reply to DarkTrick from comment #12) > Created attachment 9839 > patch for xfce4.14 Thank you, now CTRL+N is working fine again ! > thunar_window_key_press_event That is a bad method name since you use the same method for "key-release-event". Better to name the method by what it does, not by who is calling it. What about "thunar_window_propagate_key_event" ? > /* Check, if GTK_IS_EDITABLE, because if it's not, we don't want accelerators > of other widgets to be priorized over global accelerators. (E.g. Ctrl+N > is implemented as "next element" within the `list view`)*/ That's not a real good argument why you exactly check for GTK_IS_EDITABLE. How about that: Only allow text-editing widgets which implement the GtkEditable Interface to overwrite thunar accelerators. E.g. If text is selected and a file is focused, CTRL+C should apply on the text, not on the focused file. In your commit message you said: > Half-Fix: Bug 13680 Why only half-fix? If I focus some file and I select a partial file-path in the pathbar, I am able now to copy that partial path with CTRL+C .. before that fix, that was not possible. Maybe I overlook something ?
> In your commit message you said: >> Half-Fix: Bug 13680 >Why only half-fix? If I focus some file and I select a partial file-path in the pathbar, I am able now to copy that partial path with CTRL+C .. before that fix, that was not possible. Maybe I overlook something ? Short Answer: Menu → Edit → Copy/Cut/Paste does still not work as expected. Long Answer: This bug (4537) is about shortcuts overriding behaviour of focused widgets. (IMO) bug 13680 is about copy/cut/paste actions not working as expected (which includes the accelerators as well as Copy/Cut/Paste-actions from the menu).
(In reply to DarkTrick from comment #14) > Short Answer: Menu → Edit → Copy/Cut/Paste does still not work as expected. True, actually I did not see that one, since I never tried to copy text with using the window menu :) > Long Answer: > This bug (4537) is about shortcuts overriding behaviour of focused widgets. > (IMO) bug 13680 is about copy/cut/paste actions not working as expected > (which includes the accelerators as well as Copy/Cut/Paste-actions from the > menu). Afaik Bug #13680 is only about CTRL+C, not about using the window menu for copy. So I would say, that bug is fixed. If items in the window menu are shown/hidden is a different story .. I would open a separate bug for discussing that.
Created attachment 9854 patch for alexxcons' 45s branch Changed comment of the patch
Created attachment 9855 patch for alexxcons' 45s branch
Created attachment 9856 patch for xfce4.14 branch <Worthless comment to satisfy the system so it won't reject this post as "suspicious">
Created attachment 9860 slightly modified patch Thanks alot for the patch ! I just modified some cosmetics: - Fixed 6 whitespace error reported by "git am" - Used "GtkWindow* window" directly as argument - Added guard for "window" - Shortened and standardized commit message and code comment a bit If ok for you, I would push it like that to master and 4.14 branch (Since it is a smaller fix, it is ok for me to rebase the GtkAction branch on it)
I'm ok with that 👍️ Thank you!
DarkTrick referenced this bugreport in commit c3aae2e7d9aa901b5b7efa2f36fe636a4903c9ab Fix shortcut support for addressbar (Bug #4537 and Bug #13680) https://gitlab.xfce.org/xfce/thunar/commit/c3aae2e7d9aa901b5b7efa2f36fe636a4903c9ab
DarkTrick referenced this bugreport in commit 9d69b8b1c93e15bc1b6550fceb6ecd991d54e8f1 Fix shortcut support for addressbar (Bug #4537 and Bug #13680) https://gitlab.xfce.org/xfce/thunar/commit/9d69b8b1c93e15bc1b6550fceb6ecd991d54e8f1
*** Bug 13680 has been marked as a duplicate of this bug. ***
Thanks alot for your contribution, DarkTrick ! Pushed to master and 4.14, will be released in thunar 1.8.15 and thunar 1.9.0