Q Light Controller+

Hi,

I am using QLC+ 4.12.4 under Ubuntu 20.04.3 LTS / MATE 1.24.0. I have run into a bug that puts QLC+ into an unresponsive state. I have not found any way to recover, except by killing the qlcplus process from a terminal window. To reproduce it:

Run qlcplus and put it into fullscreen mode -- not just maximized, but fullscreen.

Select the function editor and create or edit a scene.

Select the tab for one of the fixtures in the scene.

Click the button that activates the color tool. The color tool will appear on top of the main window.

Now try to click any button in the main window. This will move the main window to the top of the stacking order, covering the still-active color tool.

At this point, all buttons in the main window will be unresponsive, because the color tool is still active. But the color tool cannot be dismissed, because it is hidden under the fullscreen main window. The only way to recover is by switching to a different desktop (CTRL + ALT + right arrow), opening a terminal window, and typing "killall qlcplus".

This bug is not present under macOS, where the color tool remains on top even after clicking in the main window. I haven't tried it under Windows.

I would consider this not a QLC+ bug, but a discrepancy in how different window classes, in this case modal dialogs. are handled by different desktop environments/window managers. I don't think QLC+ can do anything to prevent that. I also know of similar issues in Ardour, regarding plugin native GUI windows that ought to stay on top but don't under some WMs.

I just tried your recipe under KDE and cannot reproduce it - the color tool window stays on top under all circumstances, you cannot click any element of the underlying scene editor, and pressing Alt-Tab shows a side panel with only the color tool window available. If I try and choose the speed dial window instead, it can go below the main function tab window, and be raised again by the Alt-Tab shortcut.

I don't know whether MATE offers a similar thing, but in KDE you can set up and edit general window behaviour/rules and exceptions for window classes and also for individual windows (identified via application/window names).

I agree that it's dependent on the X11 window manager being used. However, I found a simple fix for it that should be fine for all platforms. I have created pull request #1295 with the fix. The fix simply specifies a parent when creating the QColorDialog for the color tool.