Download it now!
Bug 106071 - Customized ctrl-alt-shift-right shortcut doesn't work
Summary: Customized ctrl-alt-shift-right shortcut doesn't work
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.2.5.1 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Shortcuts-Accelerators
  Show dependency treegraph
 
Reported: 2017-02-18 01:40 UTC by john
Modified: 2018-10-31 23:06 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
shortcuts correctly assigned and functional (27.40 KB, image/png)
2017-02-18 05:14 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description john 2017-02-18 01:40:48 UTC
Using the 'customize' dialog, I set the ctrl-alt-shift-right keystroke to increase indent, and ctrl-alt-shift-left to decrease indent.

Despite showing up clearly in the shortcut list, these shortcuts have no effect when I type them.

My system is Ubuntu 16.04 LTS (with the Unity graphical shell)

This issue that makes this especially irritating is that recent changes to the menu structure in LibreOffice have taken away the old 'alt sequences', eg Alt O N etc, so there is currently no alternative keyboard sequence that I can use.

This issue is MAJOR because the broken keyboard functionality has painful implications for RSI sufferers seeking to minimise mouse usage.

Perhaps what is happening here is that the operating system is somehow 'capturing' the keystroke event. I tested with 'xev' however and xev is able to catch ctrl-alt-shift-right no problems.

Perhaps the customize dialog should use actual keystrokes instead of looking them up from a list. That way you would be simultaneously testing whether LO catches the relevant keystroke, and not just assuming that it can.
Comment 1 V Stuart Foote 2017-02-18 05:14:41 UTC
Created attachment 131309 [details]
shortcuts correctly assigned and functional

Can not confirm on Windows 10 Pro 64-bit en-US with
Version: 5.3.0.3 (x64)
Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; 
Locale: en-US (en_US); Calc: group

correctly setting the keyboard accelerators as below results in functional formatting.

1. Open Writer
2. Tools -> Customize -> Keyboard
3. select the LibreOffice radio button (so shortcut will apply to all modules)
4. navigate down the shortcut keys list to the Ctrl+Alt+Shift+Left/Right values
5. select Ctrl+Alt+Shift+Left
6. navigate the Functions -> Category to Format
7. navigate the Function list to "Decrement Indent Value"
8. click the Modify button to apply
9. verify that the Keys list shows Ctrl+Alt+Shift+Left when "Decrement Indent Value" is selected.
10. select the Ctrl+Alt+Shift+Right from Shortcut Keys list
11. repeat 6 - 9 but use the "Increment Indent Value" and verify.

Test the Shortcuts in the open Writer session. They should apply the formatting to increase and decrease the indentation.

If they show in the dialog but do not assert--then your OS/DE is interfering.
Comment 2 V Stuart Foote 2017-02-18 17:02:09 UTC
@John,

Please verify you have the shortcuts set as in comment 1

=-PS-=

<Alt>, F, N (or F10, F, N) should allow you keyboard only navigation for creating a New document via the menus. If not write please that up as well.
Comment 3 john 2017-06-11 03:11:03 UTC
Hi Stuart

My steps were slightly different. I selected 'Increase Indent' and not 'Increment Indent Value'. The option 'Increase Indent' is what I wanted, and it is what the toolbar button shows when I mouseover. I don't know what 'Increment Indent Value' means, and did not notice it when setting this up.

I note that when I mouseover the buttons in the toolbar, then show that the keybinding has been made -- "Increase indent (Ctrl+Alt+Shift+Right)" appears.

The other difference was that I selected this to happen only with Writer. This was what I wanted, since I would like to keep the ctrl-alt-shift-right bindings for other purposes in Calc etc.

I haven't tested with "Increment Indent Value"... I feel that if I must select that one and not the other more obvious choice of "Increase Indent" then it's still a bug :-)

Regarding the other thing -- Alt O N style keystrokes are a bit of a disaster at the moment. Many duplicate bindings, eg Alt F V = Sa*V*e All as well as Save To Remove Ser*V*er (used to be Print Pre*V*iew) and meanwhile there is no binding at all for Format->Character. It should be trivial to write some checks to catch key-binding collisions like this. Perhaps this is somehow specifically an Ubuntu Unity (16.04) problem, not sure why that would happen, but maybe that's it.
Comment 4 V Stuart Foote 2017-06-11 08:54:16 UTC
The UNO commands are .uno:IncrementIndent / .uno:DecrementIndent, as assigned to the Toolbar buttons, and .uno:IncrementIndentValue / .uno:DecrementIndentValue

I was tripped up at the 5.3 release by issue of bug 108458 where changes to the "Label" of commands results in duplicate entries on the list--picking the correct function is difficult.

However, as noted when the Keyboard shortcut is assigned to either flavor Indent control (one set provides logic for handle bullet), on Windows builds the shortcut(s) are functional. Both for Writer, and as global for LibreOffice.

So, this looks to be a Linux OS and DE issue.
Comment 5 Yousuf Philips (jay) (retired) 2017-06-11 15:09:24 UTC
Hi John,

If you are using ubuntu 16.04 LTS, then the shortcuts ctrl+alt+shift+left and ctrl+alt+shift+right are assigned at the desktop environment level to move the window between workspaces and as such wouldnt likely captured by LO when pressed.
Comment 6 Buovjaga 2017-06-18 10:27:47 UTC
(In reply to Yousuf Philips (jay) from comment #5)
> Hi John,
> 
> If you are using ubuntu 16.04 LTS, then the shortcuts ctrl+alt+shift+left
> and ctrl+alt+shift+right are assigned at the desktop environment level to
> move the window between workspaces and as such wouldnt likely captured by LO
> when pressed.

Then this should be closed.