Hacker News Reader

Comment by FascinatedBox | Hacker News Reader

This solves a few issues in xdotool for me:

Window selection allows for multiple criteria at once, and I can also reject windows.

I'm also able to use the window manager's client list as a source, which makes getting toplevel windows much easier.

Window movement is done using static gravity, fixing an issue where windows were moving differently if they were a terminal window versus non-terminal window.

Bonk can delete properties. I sometimes delete WM_NORMAL_HINTS if a window has size hints set where I can't resize it the way I want.

xdotool can raise windows but can't lower them (bonk can do both).

View on HN

> I sometimes delete WM_NORMAL_HINTS if a window has size hints set where I can't resize it the way I want.

With kwin it's easy to manually override an application/window to ignore geometry constraints or whatever. I do this for xterm to avoid having a few pixels of background showing at the edge when maximized.

I also used to do this a lot to get the much-nicer "soft fullscreen" in SDL1 applications.

Can it send whatever signal it is that WMs do when a window is fullscreened, or block the signal sent when it's unfullscreened? If so, I'm 100% sold.

Yes, through the state option (xdotool calls it windowstate). I was confused when implementing it, because there appear to be three different fields: maximized_horz, maximized_vert, and fullscreen. If you want total fullscreen (covers taskbar and other stuff), use the last one. If you want the window maximized, use both of the maximized ones.

Come to think of it, I should put in better documentation for the state option, as well as a general maximize alias.

GP's question seems like it might be a common question. Would it make sense to add this to the readme?

Good point. I'll make a note to add some documentation to that effect. I didn't think of it originally because I didn't expect this much interest in my project.

Good problem to have!

Reply on news.ycombinator.com