Bug 407869

This is due to the Okular KPart being used in the preview, which is eating the Space key events and uses it for scrolling, despite not having the focus.

While there is a principle issue with shortcuts from used KParts plugins conflictiing with app shortcuts, see bug 386265, this here though is a special variant, as the Space key usually is not a shortcut, so this is IMHO some overly aggressive behaviour of the Okular KParts plugin which should get in conflict in more embedding scenarios. So moving to Okular, so they can consider to improve this in their KParts plugin to restrict stealing the space key event only to when the view has focus.


Some work-around for Kate and Markdown preview: use kmarkdownwebview KParts plugin, select in SystemSettings > Applications > File Associations > text/markdown > Embedded > Move kmarkdownwebviewkpart to top in order, press Apply. Still has the other shortcut conflict issues. But normal editing and previewing at least can be done as one expects :)

you can pass "ViewerWidget" as arg to the part to get the "less aggressive" viewer.

or this would probably make sense in okular

diff --git a/part.cpp b/part.cpp
index c831f8793..229ff7fcb 100644
--- a/part.cpp
+++ b/part.cpp
@@ -576,7 +576,7 @@ m_cliPresentation(false), m_cliPrint(false), m_cliPrintAndExit(false), m_embedMo
 
     setupViewerActions();
 
-    if ( m_embedMode != ViewerWidgetMode )
+    if ( m_embedMode != ViewerWidgetMode && m_embedMode != UnknownEmbedMode )
     {
         setupActions();
     }


if anyone feels like testing

I have just looked at PageView event handling. It implements several scrolling commands trough the event system, and not trough action shortcuts. That is why you can still type all the letters, although PageView uses them as scrolling shortcuts. Only Page Down and Page Up are action shortcuts (and Shift+Down/Up for auto scrolling).

This means only Space, Shift+Space, Shift+Down, and Shift+Up will be stolen, because these are action shortcuts. (Only scrolling.)

Just for info.

What happens when you trigger Save As trough Ctrl+Shift+S? Does it always save the Markdown preview instead of your document?

*** Bug 422203 has been marked as a duplicate of this bug. ***

*** Bug 416267 has been marked as a duplicate of this bug. ***

I just realized this was partially waiting on my input. Sorry about that.

I've been using the kmarkdownwebview plugin for a while, but switching back to Okular, I can confirm this issue is still present in Fedora 32.

Ctrl+Shift+S gives me a popup dialog:

"The key sequence 'Ctrl+Shift+S' is ambiguous. Use 'Configure Shortcuts' from the 'Settings' menu to solve the ambiguity.
No action will be triggered."

A possibly relevant merge request was started @ https://invent.kde.org/utilities/kate/-/merge_requests/419

I marked this bug in the above Kate MR, although it's flagged as Okular bug. In my opinion the issue is either related to Kate or to KXMLGUI. The latter (or QMainWindow) seems to be responsible for handling shortcuts in the main menu bar.

Git commit 40ec8280266a89052612cef289a24caf172690bd by Christoph Cullmann, on behalf of Christoph Roick.
Committed on 29/05/2021 at 12:11.
Pushed by cullmann into branch 'master'.

Work around conflicting shortcuts in preview plugin

Do not let shortcuts issued within a preview widget
propagate to the application's shortcut event handler.
Instead handle the event while it's still a ShortcutOverride
event to prevent the detection of seemingly ambiguous
shortcuts.
Also do not let actions defined inside the preview KPart
capture shortcuts that are handled on the application level.
Related: bug 386265

M  +26   -0    addons/preview/kpartview.cpp
M  +4    -0    addons/preview/kpartview.h

https://invent.kde.org/utilities/kate/commit/40ec8280266a89052612cef289a24caf172690bd