odd focus and border behaviour when running in xmonad - xubuntu

[dpnova]

Needed to sudo apt install libgtk-4-dev

Then installed with: cargo install mixxc --locked --features X11

Window pops up ok:

After some time it crashes, and I think if I change focus to another window it crashes instantly - here's the logs:

I'm not rust master but very experienced developer, so not afraid to get my hands dirty if required (might need a hand getting dev env set up 😅 )

[Elvyria]

Ehh... Window probably doesn't crash. By default it automatically closes, when it looses focus together with mouse cursor, because under Wayland WM's don't send close request to layer shells like they do for regular windows. You can change this behavior with --keep flag, it's documented in README.md. I understand why you would think so, because of these GtkErrors, but you can safely ignore them, they appear only under X11 and only because i did some "hacks" for X11 to prevent window flickering on resizes.

Not sure why window is so big tho, default sizes even if you didn't specify them through -w and -h shouldn't be as big.

[Elvyria]

Thanks for the report by the way, i tested Mixxc under X11 only once for I3 and AwesomeWM when i was writing X11 feature. I'll test xmonad and see if there's a need for more atomics for X11, because this window size is not normal and WM shouldn't allow you to resize it manually.

[Elvyria]

So, the issue with size is related to xmonad's behavior towards windows with _NET_WM_WINDOW_TYPE set to _NET_WM_WINDOW_TYPE_UTILITY, both AwesomeWM and I3 treat _NET_WM_WINDOW_TYPE_UTILITY as floating windows with a free position.

You'll have change window rules inside your ${XDG_CONFIG_HOME:-$HOME/.config}/xmonad/xmonad.hs to something like this:

myManageHook = fullscreenManageHook <+> manageDocks <+> composeAll
    [ className =? "mixxc" --> doFloat, hasBorder False ]

or globally (affects PnP in Firefox)

import XMonad.Hooks.ManageHelpers ( isInProperty )
myManageHook = fullscreenManageHook <+> manageDocks <+> composeAll
    [ isInProperty "_NET_WM_WINDOW_TYPE" "_NET_WM_WINDOW_TYPE_UTILITY" --> doFloat ]

[dpnova]

Ehh... Window probably doesn't crash. By default it automatically closes, when it looses focus together with mouse cursor, because under Wayland WM's don't send close request to layer shells like they do for regular windows. You can change this behavior with --keep flag, it's documented in README.md. I understand why you would think so, because of these GtkErrors, but you can safely ignore them, they appear only under X11 and only because i did some "hacks" for X11 to prevent window flickering on resizes.

Not sure why window is so big tho, default sizes even if you didn't specify them through -w and -h shouldn't be as big.

Big window is the xmonad layout I'm using. Opens new windows as the larger middle one :)

Sorry didn't occur to me that it'd auto shut! I will totally add a hook for it. Sorry I rushed this report before work yesterday!

[dpnova]

className =? "mixxc" --> (doFloat <+> hasBorder False)

this did the trick for me, thanks!

I did notice some other weird behaviour, but I suspect that's a result of some weird interplay with layer shells. I've attached a video showing the border and focus behaviour. First I start mixxc which xmonad attempts to control in the current layout, then I use alt-click to drag it out of the layout manager, which makes a huge window :D - then I alt-right click to resize, which seems to trigger the default expect sizing.

I'm used to that stuff as an xmonad user. I think I'd have to stop using focus follows mouse to deal with the other wierdness you'll see in the vid.

2024-03-26.08-52-09.mp4

[dpnova]

I tested with my mouse follows focus hack disabled, commenting out this:

logHook = updatePointer (0.5, 0.5) (0, 0),

and didn't get the cursor issues, but still have the flickering border - which I guess may be a focus issue from the gtk hacks you mentioned too now that I think about it. 🤔

Either way, I love the widget, I think there's huge potential to combine with eww.

Cheers! (happy to test/hack btw)

[dpnova]

Just noticed that I don't get any of the flickering while the window is "managed" by xmonad - ie I haven't pulled it out of the layout manager. 🤔

noticed because I pulled the code and built locally to have a play with the x protocol

[Elvyria]

That's some wild stuff. Looks like WM doesn't accept that window was resized and treats it as a fullscreen? one and it just constantly switches focus as 2 windows are in the same place.

The only thing that i noticed on X11 was a couple of frames of the window in the center of the screen, while it was sending resize+reposition request, but that's cosmetic and should be fixable.

Don't know if this will do anything for this situation, but you could try a different rendering backend, I've seen people mentioning that they have graphical glitches with the modern default one.

GSK_RENDERER=cairo mixxc

You can list everything that's available to you with.

GSK_RENDERER=help mixxc

If you want to try different things yourself you could start gutting out x.rs, maybe some _NET_WM_STATE_ flag is responsible.

I will do some more test with the default xmonad config that i have, but maybe it's something specific with your config and could you post it?

(if you didn't compile with Wayland feature you have no "layer-shell" in your binary to worry about, it's a Wayland specific thing)

[Elvyria]

I absolutely lied about "default" config btw, i got some random one while trying to get xmonad to my distro :p

This is the one I'm testing with, maybe you can reference some differences that will help you:
https://github.com/Axarva/dotfiles-2.0/blob/main/xmonad/xmonad.hs

[dpnova]

Seems people have noticed something similar with Reaper: https://www.reddit.com/r/xmonad/comments/18rck0e/reaper_daw_and_xmonad/

EDIT: actually nm - removing ewmh didn't resolve the underlying issue for me

In the mean time when i use mixxc as an xmonad managed window I don't have any problems :) that's my workaround for now.

[Elvyria]

That could be xmonad <18.0 behavior....
https://xmonad.org/news/2024/02/03/xmonad-0-18-0.html
https://packages.ubuntu.com/search?keywords=xmonad&searchon=names&suite=all&section=all

XMonad.Operations.floatLocation now applies size hints. This means windows will snap to these hints as soon as they’re floated (mouse move, keybinding). Previously that only happened on mouse resize.

[dpnova]

That could be xmonad <18.0 behavior.... https://xmonad.org/news/2024/02/03/xmonad-0-18-0.html

interesting - I'll try upgrading from 0.17 and see how I go.

EDIT: new xmonad indeed fixed the initial layout - window goes directly to anchor point. I end up putting it back into the layout manager though because of the border flickering and focus issues.

[Elvyria]

Can we close this then?
Without a way to reproduce the remaining focus issue (not on xmonad, not on i3 and not on AwesomeWM), i have no idea how to help you further and i don't know if it's related to Mixxc or your config.