Alacritty: chunkwm can't tile alacritty when decorations: false

Created on 21 Jul 2018 · 3Comments · Source: alacritty/alacritty

Which operating system does the issue occur on? macOS 10.13.6

When using chunkwm and windows/decorations: false, alacritty appears as a small window that chunkwm is unable to move or resize.

This was reported for iTerm2 with no title bar in koekeishiya/chunkwm#92, and was resolved by upgrading iTerm. I assume therefore that this is not a chunkwm bug per se, but that there's something alacritty can do to not break it.

I've asked for more information in the above issue, as I don't know what the cause would be or how iTerm fixed it.

H - macos

Source

OJFord

Most helpful comment

i fixed this in https://github.com/jwilm/alacritty/pull/1241, but i stopped maintaining the branch after https://github.com/jwilm/alacritty/pull/1241#issuecomment-395887745

Once that merges, I'll probably also wait for https://github.com/jwilm/alacritty/pull/1403 to merge and rebase from there.

sodiumjoe on 16 Aug 2018

👍3

All 3 comments

Summary from that issue:

With decorations:

subrole: AXStandardWindow
resizeable: 1

Without:

subrole: AXUnknown
resizeable: 0

chunkwm author says:

These properties are queried from the macOS accessibility API.

Regarding the subrole, I'm not completely sure how that is set by the applications, but this can be worked around using the rules-system implemented in chunkwm, and is not a big deal.

The real problem here is that the window is not marked resizable. The reason for this is that the windowing toolkit that Alacritty uses does not set the NSWindowResizableMask to the NSWindow's styleMask.

Most frameworks that I've seen have this behaviour (god knows why..) when the window titlebar is disabled. GLFW used by the Kitty terminal had the same issue, however the Kitty developer made the hide_titlebar option re-add the missing NSWindowResizableMask manually. as the GLFW API exposes the underlaying NSWindow if desired.

The author of Alacritty could probably fix this the same way.

OJFord on 21 Jul 2018

This sounds like rather than fixing it in Alacritty, this should be fixed in winit.

Would you mind testing if this also happens with winit using one of their examples (they can be run using cargo run --example <NAME>)? If these have the same problem then opening an issue with winit is probably going to be the most beneficial.