Window keeps raising itself, slow to react to focus gain/loss #5620
Comments
|
Agreed, this is ridiculously annoying for anyone using focus follows mouse. To add to the injury, Prusaslicer (I am using 2.3.1) brings the main window to the front of its own dialogs, thus hiding them and making them impossible to interact with unless you move the main window out of the way! |
|
Looks like it was introduced with this commit: 20f5b7a "Keep your fingers crossed that it will not break something else." |
|
Specifically, adding CallAfter() appears to be the cause... calling them immediately rather than using CallAfter() appears to work. Maybe @bubnikv can shed some light on why CallAfter() was added in that patch. |
The CallAfter() on Linux causes weird window focus issues. For me, using ALT-Tab to switch away from PrusaSlicer would cause PrusaSlicer to take back focus after about one second. Stranger things reportedly occur with focus-follows-mouse. The #ifdef is there because it is assumed the CallAfter() was added in 20f5b7a for a good reason.
|
Submitted PR #6870 which takes the ultra-conservative path to a fix. |
|
Please test the builds attached to #6870 (comment) |
|
Fixed with 3622f06 |
Work around 3D scene focus after de-activation of the main window without having to resort to CallAfter(), which breaks on Linux with some window managers that follow mouser cursor. Fixes #5620 #6870 #6992 3622f06 was not a correct solution, it broke focus for non-modal windows. Fixes #7419 The actual issue seems to be caused by wxProgressDialog not playing well with modal dialogs closed just before wxProgressDialog opens. If wxProgressDialog parent was not a main frame, keyboard focus was not restored correctly after the wxProgressDialog closed.
Version
commit d2b45c2 (git tag
version_2.3.0-rc2)Operating system type + version
Debian bullseye/testing
3D printer brand / version + firmware version (if known)
N/A
Behavior
Like a large portion of Linux users, my desktop is set to focus-follows-mouse, and to never to raise a window without my explicit action.
However, Prusaslicer likes to raise itself to the top if for example I give it focus, do nothing at all, and then hide it behind some other window. Often, if it gains focus, and I then bury it behind something else, it'll raise itself right away and it'll take me a few tries to get it to stay buried. If I give it focus, and then wait a few seconds before I bury the window, usually it will stay down.
A simple way to reproduce this: put a terminal on top of the Prusaslicer window and simply waggle the mouse from one to the other a couple of times, without clicking anything. When you stop moving the mouse, leave the mouse pointer on the terminal, and Prusaslicer will raise itself after a second. If your window manager is anything like XFCE/xfwm4, it will clearly show that focus is following the mouse, and its own decorations will react to the focus changes exactly as you've configured it to, and the terminal will show to have focus at the moment Prusaslicer raises itself.
This may be related to another oddity: whenever Prusaslicer gains focus, it takes about 1 second for it to react (for example, if the gtk3 theme changes the colors of the buttons et al. dependent on focus), and similarly about 1 second to react when it loses focus, during which time the
prusa-slicerprocess spins at 100%, so the above test will peg a CPU core until you stop.Meanwhile other programs, even complex ones like Chrome, display normal window stacking behavior and normal focus behavior.
The text was updated successfully, but these errors were encountered: