Skip to content
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

Open
xpusostomos opened this issue Dec 5, 2024 · 10 comments
Open

Floating windows vanish when mouse moves #92

xpusostomos opened this issue Dec 5, 2024 · 10 comments

Comments

@xpusostomos
Copy link

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.

@Stebalien
Copy link
Contributor

Do you have either of the Emacs settings focus-follows-mouse or mouse-autoselect-window set?

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.

@xpusostomos
Copy link
Author

I do have what is recommended in the exwm user guide:

(setq mouse-autoselect-window t
      focus-follows-mouse t)

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:

(setq mouse-autoselect-window t
      focus-follows-mouse t)

The first option sounds a bit suspicious, however the documentation is insistent I need both to get focus follows mouse.

@Stebalien
Copy link
Contributor

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.

@xpusostomos
Copy link
Author

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.

@xpusostomos
Copy link
Author

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.

@Stebalien
Copy link
Contributor

These are both Emacs options, not EXWM options:

  • mouse-autoselect-window is the main option. It instructs Emacs to switch Emacs windows when the mouse moves around. It also instructs EXWM to try to make this behavior work well with X windows.
  • focus-follows-mouse tells Emacs what your window manager does. EXWM doesn't actually look at this variable.

It's important that these variables have the same value because, in this case, Emacs is the window manager.

@xpusostomos
Copy link
Author

@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.

@Stebalien
Copy link
Contributor

Yeah, I generally agree. Fixing it should be a matter of:

  1. Not raising windows on focus.
  2. Explicitly raising windows when switching to them.
  3. Raising windows on mouse-clicks.

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.

@xpusostomos
Copy link
Author

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)

@Stebalien
Copy link
Contributor

What do you define as "switching to them"?

E.g., exwm-workspace-switch-to-buffer, switch-to-buffer, etc.

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)

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants