-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Floating windows vanish when mouse moves #92
Comments
Do you have either of the Emacs settings Honestly, this sounds like it might be a Jetbrains issue (i.e., Jetbrains is telling EXWM to raise windows when the mouse enters them). My experience is that Jetbrains never works well on tiling window managers. Here's some advice that sound familiar from when I last tried to get this to work. |
I do have what is recommended in the exwm user guide:
The guide says this is needed for focus follows mouse, which is a less controversial behavior than what is happening, which is mouse pops up the window. Generally there's 3 ways to run a window manager, click to focus, focus follows mouse, and mouse raises window to the top. The first 2 are not controversial, the 3rd is kinda. Although a decade ago I ran that option and don't remember it restacking dialogs WITHIN apps, as opposed to just the apps themselves. I seem to remember when it restacked, it restacked all of an app, but anyway... I don't think there's any way that jetbrains is doing this, I've run it for years under other window managers. The thing is, these dialogs are not tiled, they're floating, so it's hard to say, well it's a tiling problem. The option you mention, to tell Java it's a reparenting window manager.... Reparenting means that it forces an extra frame between a top level window and the X root window, for the purposes of drawing a frame. Everything I read says this can cause rendering problems, windows blank, popup menus not showing. But this is rendering fine. It's just changing the zorder of windows with focus. That's surely a window manager choice, there is no way either Java or jetbrains would have code to change zorder by mouse focus. Why does the doco say you need to set 2 options for focus follows mouse:
The first option sounds a bit suspicious, however the documentation is insistent I need both to get focus follows mouse. |
Can you try disabling those options to see if that fixes the raising issue? EXWM mostly focuses on tiling (floating is very much a second class citizen) so I wouldn't be surprised if there are bugs there. |
I turned those 2 options off, and there was no disappearing windows. I also tried only using the 2nd option, but that did not enable focus follow mouse. So you need both, but it leads to that problem. I'm curious what the 1st option means.... surely good design would dictate that if focus-follows-mouse requires the other option too, then setting it should automatically imply the other thing without having to explicitely set it. |
I notice in squirrel-sql .... another Java program .... that the windows getting promoted over each other as you mouse around happens also. BTW, it doesn't render at all until I do (setenv "_JAVA_AWT_WM_NONREPARENTING" "1") ... I have to wonder if this should be in the exwm core to avoid issues for new users. |
These are both Emacs options, not EXWM options:
It's important that these variables have the same value because, in this case, Emacs is the window manager. |
@Stebalien yes but, while focus follows mouse is a popular option, mouse causing auto raise of the zorder is considered anti social by most folk, especially of the zorder within an app's modal dialogs. And yes you do need mouse -auto-select-window for the more benign focus follows mouse behaviour, but we don't want the collateral damage of auto raise. |
Yeah, I generally agree. Fixing it should be a matter of:
But, TBH, I've never even gotten the focus-follows-mouse functionality to work well at all in the first place and I'd like to see that work better before spending time polishing it. |
What do you define as "switching to them"? Auto raise, or indeed raising at all for tiled windows makes no sense anyway. I dare say raising dialogs for tiled windows, auto or otherwise is undesirable. Raising purely floating apps potentially is useful, but also seems broken (see my other comments how they keep popping up) |
E.g.,
As far as I know, EXWM doesn't have any "autoraise" functionality. However, the issue here is that it doesn't have a distinction between raised and focused. |
I'm using intellij idea here. If I open Settings -> Keymap it opens a large dialog box. If I then select keymap and try and add a key mapping, it opens a tiny dialog on top of the bigger dialog. If I then have the mouse somewhere else and move it towards the small dialog, on top of the big dialog, the small dialog vanishes. I was confused for a while where it had gone. I tried to get it back with the buffer list, but seemingly the buffer list can't have any affect on floating windows (surely selecting one should bring it to the front? But no.). I was about to kill intellij, and then I realised that what was happening was that it has pushed the small dialog to the back of the big one.
I remember back in the old days that having window managers automatically bring windows to the front with mouse movement was an option, albeit it was a very unpopular controversial option. And I don't remember it happening with temporary dialog boxes, which doesn't make sense. It seems to me that exwm is doing that, and it shouldn't be, or at least it shouldn't be the default. Not sure if there's a way to turn it off.
The text was updated successfully, but these errors were encountered: