Unable to reassign an Alt+key to a macro that is used as a menu mnemonic. Upgraded from 5.1.x.x to 5.4.0.3 I used to be able to assign Alt+T (amongst others) for example, to a macro. Under 5.4.0.3 this no longer works properly. Now both events occur. The Menu->Tools is selected AND the macro fires, leaving the Menu->Tools open and having to be closed manually.
If this behaviour is retained we can wave goodbye to being able to reassign Alt F, E, V, I, O, S, A, T, W and H In which case they should not be offered as options in Tools->Customise->Keyboard
No problem for me assigning Alt-T as a macro mnemonic. Do you also have the problem with any other function and not just macros? Arch Linux 64-bit, KDE Plasma 5 Version: 6.0.0.0.alpha0+ Build ID: 668ab2e739397e6b095372a1a468bd4f515927b6 CPU threads: 8; OS: Linux 4.12; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on August 20th 2017
(In reply to Buovjaga from comment #2) > No problem for me assigning Alt-T as a macro mnemonic. > > Do you also have the problem with any other function and not just macros? > > Arch Linux 64-bit, KDE Plasma 5 > Version: 6.0.0.0.alpha0+ > Build ID: 668ab2e739397e6b095372a1a468bd4f515927b6 > CPU threads: 8; OS: Linux 4.12; UI render: default; VCL: kde4; > Locale: fi-FI (fi_FI.UTF-8); Calc: group > Built on August 20th 2017 I am able to assign a macro to Alt-T and any other character that is used as a "Alt menu shortcut" (F,E,V, etc). The issue was that not only does the macro fire up but that the Alt Menu event fired as well. So "hotkey" assignment of the macro was not overriding the menu shortcut as it did previously. Instead both occurred. The result was that the macro ran happily but the Alt menu selection was left live and had to be cancelled. This behaviour was a show stopper for me, I removed LO 5.4.0.3 (the offending version) and reverted back to Build ID: 1:5.1.6~rc2-0ubuntu1~xenial2, where reassigning an Alt menu character to a macro "replaces" the Alt menu function.
(In reply to rolfofsaxony from comment #3) > I am able to assign a macro to Alt-T and any other character that is used as > a "Alt menu shortcut" (F,E,V, etc). The issue was that not only does the > macro fire up but that the Alt Menu event fired as well. So "hotkey" > assignment of the macro was not overriding the menu shortcut as it did > previously. Instead both occurred. Yeah, no such problem for me on Linux or Windows. Yet, you did not answer my question about if this is restricted to macros or also affects any shortcuts. Win 7 Pro 64-bit, Version: 5.4.0.3 (x64) Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c CPU threads: 4; OS: Windows 6.1; UI render: default; Locale: fi-FI (fi_FI); Calc: CL
Could you try with this master build, then you do not have to install anything: http://dev-builds.libreoffice.org/daily/master/Linux-archive-x86_64@80-updater/current/LibreOfficeDev_6.0.0.0.alpha0_Linux_x86-64_archive.tar.gz You just run the soffice binary in the program/ directory after unpacking.
(In reply to Buovjaga from comment #4) > (In reply to rolfofsaxony from comment #3) > > I am able to assign a macro to Alt-T and any other character that is used as > > a "Alt menu shortcut" (F,E,V, etc). The issue was that not only does the > > macro fire up but that the Alt Menu event fired as well. So "hotkey" > > assignment of the macro was not overriding the menu shortcut as it did > > previously. Instead both occurred. > > Yeah, no such problem for me on Linux or Windows. > > Yet, you did not answer my question about if this is restricted to macros or > also affects any shortcuts. > > Win 7 Pro 64-bit, Version: 5.4.0.3 (x64) > Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c > CPU threads: 4; OS: Windows 6.1; UI render: default; > Locale: fi-FI (fi_FI); Calc: CL Yes, sorry. As I said, it was a show stopper, so I stopped and did not test any further. I shall give the build that you have linked to a whirl and get back to you, when I can. Regards
Created attachment 135724 [details] screen shot of the Alt+T behaviour when assign to Underline
Tested Version: 6.0.0.0.alpha0+ Build ID: 0e35b7738d9f276c0566df0f2cc0f1eed7900d6c It displays the same behaviour for macros (python) both in an extension and standalone in the Scripts/python directory. I re-assigned Ctrl-U Underline to Alt-T and it behaves in the same way. The selected text is underlined AND the Tools Menu event fires. I added a screen shot. The same behaviour was observed when re-assigning Ctrl+I Italic to ALt+V although, obviously, the selected text turned to Italic and the View Menu was left on the screen.
Additionally: Setting org.openoffice.VCL:ConfigurableSettings['Menu'] SuppressAccelerators string true Does not appear to make any difference. Accelerators are still active when the Alt key is pressed
Confirmed with gtk3. No problem with gtk or gen.
Created attachment 135919 [details] bibisect details Working on debian-stretch in the linux dbgutil daily till52 repository, I see that the bug came in somewhere in the 49 commits: commit date s-h -------- ---------- -------- good a441153e 2016-02-26 49f81b3f bad 4c8042c3 2016-02-27 af57a81d I am removing keyword bibisectRequest and adding bibisected.
I should have mentioned ... This is with xfce desktop, and I see the bug with SAL_USE_VCLPLUGIN=gtk3 but not with gen.
We should be able to use the return code of the keyboard callback to determine if we've used the keystroke in libreoffice and suppress the native menu bar from seeing it
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3266c3bf545cc3045f843f764b4c420241d9e4da Resolves: tdf#110452 stop menubar processing Alt+foo if handled by core widget It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I see the bug fixed on debian-stretch with xfce desktop in daily Linux dbgutil bibisect repository version 2017-09-05.
(In reply to Terrence Enger from comment #15) > I see the bug fixed on debian-stretch with xfce desktop in daily Linux > dbgutil bibisect repository version 2017-09-05. Is there a build in the daily builds that I can test. I installed the latest from 2017/09/05 but there is something awry with the python, as it can not find its libraries, complaining about no encodings.
(In reply to rolfofsaxony from comment #16) > Is there a build in the daily builds that I can test. > I installed the latest from 2017/09/05 but there is something awry with the > python, as it can not find its libraries, complaining about no encodings. Did you follow the instructions at "Installing in parallel/Linux" <https://wiki.documentfoundation.org/Installing_in_parallel/Linux>? Perhaps it would be worth-while to try another daily build. Then take take your problem to the QA mailing list, including the error message that is stopping you. I wish I could give you more substantive help. Terry.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=aaa6ceb9fa91f38d1c32cfe3882255cfd1490ab9&h=libreoffice-5-4 Resolves: tdf#110452 stop menubar processing Alt+foo if handled by core widget It will be available in 5.4.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.