View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0015472 | Scribus | User Interface | public | 2018-11-03 19:58 | 2019-12-31 15:34 |
Reporter | hawson | Assigned To | |||
Priority | normal | Severity | major | Reproducibility | always |
Status | new | Resolution | open | ||
Platform | Arch Linux | OS | Linux | ||
Product Version | 1.5.4 | ||||
Summary | 0015472: [ON HOLD] Shortcuts with modifiers do not work | ||||
Description | All shortcuts that require a modifier such as ctrl- or alt- do not work. Thus, common actions such as copy (ctrl-c) and paste (ctrl-v) and save (ctrl-s) do not work from their shortcut keys. Single key shortcuts work fine. All actions work fine from drop down menus, toolbars, etc. This appears to be related only to how the keystrokes are interpreted. Attempts to re-map the shortcuts show that the control key is being interpreted as "Meta". I downgraded to Scribus 1.4.7, and shortcuts work fine (version 1.4.7 also required downgrading libidn and podofo minor versions as well, but those seem unlikely to be culprits). | ||||
Steps To Reproduce | 1. Open a new document 2. Create an element 3. Try to copy/paste the element using ctrl-c/ctrl-v | ||||
Additional Information | This seems similar to task 15436, although there seems to be no correlation with opening the preferences dialog box: the shortcuts never work. | ||||
Tags | shortcuts | ||||
Patch | No | ||||
|
Unable to reproduce on Windows. |
|
> Unable to reproduce on Windows. Not surprising. Two other datapoints: 1. under 1.4.7 (where shortcuts *do* work), attempting to reset a shortcut shows some odd characters. (See attached). Prior to this, it displayed as "Ctrl-S" as normal. Under 1.5.4, trying to remap reports "META" (not Ctrl or SUPER). 2. The laptop in question is technically a Chromebook, although it has a full Linux install on it. This is relevant only in that the key I'm using has been remapped to "control" instead of the original "search" function. I think that this is interpreted as a "SUPER" key, as opposed to CTRL, ALT, or something else. From the 'xev' tool, here are two scankey events: one when the search/SUPER key is pressed, and one when released: KeyPress event, serial 37, synthetic NO, window 0x5600001, root 0x10f, subw 0x0, time 182196939, (30,103), root:(624,426), state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 37, synthetic NO, window 0x5600001, root 0x10f, subw 0x0, time 182197058, (30,103), root:(624,426), state 0x4, keycode 133 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False |
|
... unable to reproduce on debian testing with a somehow recent development code... |
|
Unable to reproduce on Linux Mint 19. |
|
Could the window manager have anything to do with it? I'm running XFCE 4.12, but I don't think I have any particular settings that would interfere. |
|
Here's the ~/.Xmodmap file, in case it's relevant: <---snip---> $ cat .Xmodmap clear control clear mod4 keycode 133 = Super_L keycode 37 = Control_L add control = Control_R Super_L add mod4 = Control_L Hyper_L Super_R keycode 74 = XF86AudioMute F8 F8 F8 F8 F8 XF86Switch_VT_8 F8 F8 XF86Switch_VT_8 keycode 75 = XF86AudioLowerVolume F9 F9 F9 F9 F9 XF86Switch_VT_9 F9 F9 XF86Switch_VT_9 keycode 76 = XF86AudioRaiseVolume F10 F10 F10 F10 F10 XF86Switch_VT_10 F10 F10 XF86Switch_VT_10 <---snip---> |
|
I tried a different window manager (TWM), in case that was getting in the way of things: no change. Shortcuts still don't work. |
|
Built scribus from source (r22773), but there's still no change in behavior: ctrl/alt shortcuts are not registered. |
|
you might want to try to remove all your customization (like the Xmodmap file) and see if then scribus works correctly for you. when you get to a working state, then add each customization back, once at a time, until oyu find out which one is giving you headaches... |
|
please test with 1.5. if you cannot reproduce with 1.5 i think we can close this ticket. |
|
This problem still occurs in 1.5.5 (tested this morning). |
|
so, generally speaking the shortcuts do work. in your case shortcuts do not work in scribus but work in other applications. i tried to do an internet search for "chromebook qt shortcuts" or "chromebook qt keyboard" but i could not find anything relevant. nonetheless, i tend to think that it's a chromebook related issue... hard to say what is happening on your computer and since nobody else commented in this ticket it seems to be something that is specific to your setup... |
Date Modified | Username | Field | Change |
---|---|---|---|
2018-11-03 19:58 | hawson | New Issue | |
2018-11-03 19:58 | hawson | Tag Attached: shortcuts | |
2018-11-03 21:07 | jghali | Note Added: 0045568 | |
2018-11-03 21:31 | hawson | Note Added: 0045569 | |
2018-11-04 11:05 | ale | Note Added: 0045570 | |
2018-11-04 15:16 | PeterBenedek | Note Added: 0045571 | |
2018-11-04 15:33 | hawson | Note Added: 0045572 | |
2018-11-04 15:43 | hawson | Note Added: 0045573 | |
2018-11-17 19:06 | hawson | Note Added: 0045634 | |
2018-11-19 13:03 | hawson | Note Added: 0045645 | |
2018-11-19 13:56 | ale | Note Added: 0045646 | |
2019-08-19 12:29 | ale | Note Added: 0046486 | |
2019-08-20 07:50 | ale | Summary | Shortcuts with modifiers do not work => [ON HOLD] Shortcuts with modifiers do not work |
2019-12-30 17:41 | hawson | Note Added: 0047312 | |
2019-12-31 15:34 | ale | Note Added: 0047314 |