Hotkeys not working in 1024x768 and 800x600 resolution

[takacstib]

In 1024x768 resolution (this acceptable by my laptop, and Promethean board too), the CTRL-V and some other hotkey is not working. Whe I set the resolution to 1366x768, the CTRL-V worked, and when I set again to 1024x768, it don't do anything. I tried this behavior and same in 1.5.3, 1.5.4, and 1.6.1.

[letsfindaway]

Those hotkeys are defined in OpenBoard completely independent of the screen resolution. So I would suggest you check some more things to identify the problem:

• What platform are you using? Windows, Linux, Mac?
• Can you check whether this happens with any other program, too? E.g. a text editor?
• Is it only Ctrl+V or are other shortcuts also affected?
• Are you copy/pasting from within OpenBoad or from an external program?
• What are you trying to paste? Just text, an image, something else?

[takacstib]

Those hotkeys are defined in OpenBoard completely independent of the screen resolution. So I would suggest you check some more things to identify the problem:
For me was very surprisingly. I tried a lot of times, because I didn't believe this...

• What platform are you using? Windows, Linux, Mac?
  Windows 10x64, 21H1, Hungarian language, Hungarian keyboard
• Can you check whether this happens with any other program, too? E.g. a text editor?
  Working well, without any issue.
• Is it only Ctrl+V or are other shortcuts also affected?
  I tried the CTRL-H and I detected same behavior:
  The resolution 1024x768, push CTRL-H: nothing happened. Windows-D, changed the screen resolution to 2048x1024, CTRL-H: worked as expected... Change back the resolution to 1024x768, CTRL-H: nothing happened...
• Are you copy/pasting from within OpenBoad or from an external program?
  From the clipboard (screenshot).
• What are you trying to paste? Just text, an image, something else?
  The image from the clipboard (previously created screenshot). When I selected the Paste, from the menu, it pasted well.

I tried it with the last version: 1.6.1.

[letsfindaway]

I can actually reproduce this behavior on Linux and will try to track it down further when I have some spare time.

So @kaamui , please add the "Bug" label.

[letsfindaway]

I think I found an at last theoretical explanation of the behavior:

• When screen width is 1024 or smaller, the main toolbar does not completely fit on the screen.
• QToolBar therefore adds an extension button att the end and moves the non-fitting menu buttons to an extension submenu.
• In this situation, the right-most "OpenBoard" menu button is not directly visible on the screen.
• The documentation of QAction says:

An action will be disabled when all widgets to which it is added (with QWidget::addAction()) are disabled or not visible. When an action is disabled, it is not possible to trigger it through its shortcut.

• And this is exactly the situation we have: the widget to which the "Paste" action (and others) is added is the "OpenBoard" toolbar button, and this button is invisible.
• Therefore the keyboard shortcuts assigned to them do not work.

So we have to add the action to other widgets, which are visible in this situation.

[kaamui]

maybe something to do with https://doc.qt.io/qt-5/qt.html#ShortcutContext-enum

[letsfindaway]

maybe something to do with https://doc.qt.io/qt-5/qt.html#ShortcutContext-enum

Don't believe so. The context of these actions is already set to Qt::ApplicationShortcut. And the context does not change with screen resolution and also not with the visibility of the OpenBoard menu widget. But that's just a guess, not verified.

[letsfindaway]

The attached very simple patch resolves the issue:

--- a/src/core/UBApplication.cpp
+++ b/src/core/UBApplication.cpp
@@ -550,6 +550,9 @@ void UBApplication::decorateActionMenu(QAction* action)
             menu->addAction(mainWindow->actionQuit);
 
             tb->setMenu(menu);
+
+            // add menu actions to main window to make them accessible in all situations
+            mainWindow->addActions(menu->actions());
         }
     }
 }

[letsfindaway]

This will be solved in 1.7.2 as #1070 was merged.