Obscure Window Manager Problem [Enhancement]
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| xfwm4 (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
Xubuntu 20.04
xfwm4 4.14.1-0ubuntu1
This is a problem that only occurs under very specific conditions. However, I think it is problematic enough to deserve consideration for an enhancement.
My setup includes multiple (8) virtual desktops. I use Meta-{L,R}ArrowKey to move between desktops and Shift-Meta-
My Window Manager settings include:
- Focus Follows Mouse
- Automatically give focus to newly created windows
- Raise window when clicking inside application window
I do not use Auto raise when window receives focus.
The Problem: I move my mouse over a window on the current screen. It receives focus, but I do not click on it. I want to move the window three desktops to the left. I use Shift-Meta-
As I said, this happens because of my particular settings. I don't like auto raise on focus because it causes a lot of visual jumping on the screen when you move the mouse around. I did try it out with a long delay, but the problem described above can still occur.
I would suggest a reasonably simple fix which is whenever a window is being moved, immediately raise it so that it floats above the other windows and never gets lost under another window. I assume that raising a window makes it "higher" then all windows on every desktop, not just the current one. Thoughts?
| C. Jeffery Small (loyhz2ay-jeff-h670zbts) wrote | #1 |
Not getting much attention here! :-)
Here is some additional information that might be useful. I was having problems with new windows being created and hidden underneath existing windows. In a forum discussion it was suggested to turn off (uncheck) the "Activate focus stealing prevention" on the "Window Manager Tweaks->Focus" tab. This indeed was the problem and once unchecked, new windows were consistently created on the top of the stack. However, this does not address the problem of moving a window that is lower or at the bottom of the window stack to another workspace using keyboard shortcuts. The moving window may still disappear beneath other windows higher in the stack.
I have "Raise window when clicking inside application window" set so any attempt to drag a window with the mouse forces it to the top of the stack. My suggestion is that if the user has this option set, that it then also imply that any window movement initiated by a keyboard shortcut also causes the window to be raised so that it will float above all other windows as the virtual desktops (workspaces) change. Unchecking this option would leave the keyboard shortcut action as is.
Of course, it would be clearer for everyone involved if this raise-on-