Feature Request: Force tiling windows that are not handled as default about miguruwm HOT 9 CLOSED

ah, that was the missing part I'd want to know, I think it's a good idea to put this in the readme

from miguruwm.

To be precise, Alacritty only fails to be tiled when its window decorations were set to none (the default option is full), in which case there's no title bar for the window.

it seems that if I manually hide the title bar for a window

        WinSet, Style, -0xC00000, A
        WinSet, Style, -0x840000, A

then MiguruWM can't handle it correctly (at the beginning)

UPDATE:

I guess that's more difficult than I first thought, as disabling the title bar results in no recognisable WinEvents.

from miguruwm.

Hi there,

I actually had the same issue the other week with qutebrowser.

Your first title is a better fit though I guess, because handling windows without decorations would probably yield a lot of false-positives and forcely managing a few specific windows would thus be more reasonable.

PS:
"after some minor tweaks (like toggleFullscreen, toggleFloating and other functions)", do you just mean something like

*sc05::mwm.Set("layout", { value: "Fullscreen" })

or were you missing something?

from miguruwm.

Sorry I may have caused you a misunderstanding, by tweaks I just mean some adjustments in personal preference, like window resizing for a float window, or refocus the last virtualdesktop. (And if I didn't miss anything, although it does not affect the normal use, the mwm.FloatWindow(hwnd) for floating on Alt-Left/Right click hasn't been implemented yet on master branch)

And, thanks for the reminder, I will change the title back to force window tilings

from miguruwm.

Can you test the latest version?

You should be able to make borderless windows get managed with
GroupAdd("MIGURU_DECOLESS", "ahk_exe alactritty.exe")

If you'd also want to auto-float it, add this as well
GroupAdd("MIGURU_AUTOFLOAT", "ahk_exe alactritty.exe")

from miguruwm.

Thanks! Can confirm that windows missing WS_CAPTION can be handled correctly after adding MIGURU_DECOLESS.

The only less important issue is that even though all other borderless are handled well, alacritty is still treated as floating initially(but it can be manually tiled with mwm.Do("float-window", { hwnd: WinExist("A"), value: "toggle" })) and I can be sure I didn't add any AUTOFLOAT for alacritty

from miguruwm.

I can confirm that there seems to be an issue with alacritty, apparently it's specific to alacritty and not related to it being borderless:
For example, qutebrowser works as expected for me and also giving alacritty window decorations with decorations: full doesn't result in it getting managed/retiled correctly.

Can you check if it's the same for you (buggy even if non-borderless)?
Also instead of using Do("float-window") can you try re-focusing alacritty's window shortly after it appeared e.g. by alt-tabbing twice and see if it gets picked-up correctly? If not, what about resizing the master pane with alt-h/alt-l?

from miguruwm.

In my environment, alacritty can be handled correctly when decorations=full.

I think it might have something to do with this

Some borderless windows still have exstyle, whereas with softwares like alacritty and tauon music box, their windows don't have exstyle in their borderless mode

from miguruwm.

Ahh, you're right. The problem I'm having with alacritty is actually a different one, it's due to startup_mode: Maximized, I'll probably create another issue for that later.

However, after removing that setting, it's working fine for me, with or without window decorations.
It's probably in the lines you quoted, though, and for me alacritty has the style you mentioned because of some other settings I guess.

window:
  padding:
    x: 0
    y: 0
  dynamic_padding: true
  decorations: none
  #startup_mode: Maximized

Btw. to verify the log messages, you can start miguru from powershell with $env:AHK_LOG="info"; autohotkey ./mwm.ahk or $env:AHK_LOG="workspacelist=info"; autohotkey ./mwm.ahk

from miguruwm.