Fix window centering, windowless commands, and add cascade/tile-all

[gmarthews]

Bug fixes:

• Fix move-to-center positioning window slightly above center due to incorrect application of from_gravity for CENTER gravity. Added Rectangle.center_in() method for proper centering math.
• Fix windowless commands (show-desktop, workspace-go-*) silently breaking after first invocation by extracting windowless flag at decoration time rather than inside the wrapper loop.
• Fix GravityLayout treating explicit x=0.0 as unset (falsy check) by using 'is None' comparison.

New features:

• Add 'cascade' command to arrange all workspace windows in diagonal stair-step pattern.
• Add 'tile-all' command to tile all workspace windows in optimal grid layout respecting screen aspect ratio.
• Add Rectangle.center_in() utility method.
• Add _calculate_optimal_grid() for grid dimension calculation.

[ssokolow]

Wow. Thanks. I'll try to make time to start evaluating your changes today.

I do notice a couple of non-code oversights though (probably my bad for not getting around to writing a better contributing doc):

1. Please add yourself to docs/authors/index.rst and run docs/update_authors.sh. (I give credit for even the smallest contributions and yours is anything but small.)
2. Please add the notes from your commit message to ChangeLog and, since I haven't had time to work on my big 0.5.0 feature, please rename 0.5.0 to 0.4.2 in ChangeLog and quicktile/VERSION.

EDIT: I've added a PR template to make sure those are clear to future contributors.

[ssokolow]

Testing still in progress, but I've found that cascade currently rips Yakuake away from its normal position, at which point Yakuake assumes the user wanted to switch which monitor it's bound to and requires fiddling with its config to get it fixed.

Given this is likely to also affect some desktop sticky note utilities, I'm thinking the most generally applicable solution is probably to exclude windows where Wnck.Window.is_skip_tasklist() == True from the cascade.

The question is whether get_relevant_windows should be amended or split into two classes of relevance. (eg. Whether there any dialog boxes which use _NET_WM_STATE_SKIP_TASKBAR instead of trusting WM_TRANSIENT_FOR to keep them from showing up in the taskbar.)

I'll also want to investigate whether excluding _NET_WM_WINDOW_TYPE_UTILITY from the tiling would be over-broad or just right.

[ssokolow]

Actually, looking through the EWMH, it looks like there's a whole class of "probably don't want this" that I forgot to address because I didn't put much thought into commands which affect windows other than the active one.

For example, I hadn't noticed that, when you tear off a toolbar in Qt, that toolbar can be focused, and it doesn't prevent QuickTile from stretching it in unnatural ways... it just snaps back into shape as soon as you move it with the mouse.

...so yeah. I should probably split the concept of "relevance". I can see the following types of windows being things people might want to reposition with QuickTile's active-window commands, but which they probably wouldn't want subject to "all windows" tiling commands:

• _NET_WM_WINDOW_TYPE_TOOLBAR (Floating toolbars)
• _NET_WM_WINDOW_TYPE_MENU (Torn-off menus)
• _NET_WM_WINDOW_TYPE_UTILITY (Detached docks and things like Yakuake)
• _NET_WM_WINDOW_TYPE_SPLASH (Splash screens)

(i.e. The things which can potentially receive focus, but which a full-blown tiling window manager would generally set "allow floating" exceptions for or have specialized handling of.)

[ssokolow]

As for the hard-coded offset = 25, since I was never the target audience for cascading (I never used it, even on Windows 3.1), I'll ask for your opinion.

It shouldn't be hard-coded, but do you think it should be a line in quicktile.cfg for users to customize or should QuickTile attempt to match it to the height of the WM-provided titlebars?

My intuition says the latter, to ensure the window titles are visible regardless of the user's chosen font size.

[ssokolow]

Sorry for not replying promptly. It's been a busy week. I'll try to make time to look over the updated PR within a couple of days.

[ssokolow]

Clearly things didn't go as planned. Just wanted to let you know I haven't forgotten about this... it's been difficult to make time for my hobby projects when I have the energy to review code.

[gmarthews]

Hi, thanks for the thoughtful review. I am really not very good at any of this; I am getting the AI assistant to help a lot but I have a few responses to the open questions: Window filtering for cascade/tile-all: I went ahead and implemented this in get_relevant_windows() — it now excludes TOOLBAR, MENU, UTILITY, and SPLASH window types, plus any window where is_skip_tasklist() is True. This covers Yakuake, torn-off menus, floating toolbars, sticky notes, and splash screens. Your suggested is_skip_tasklist() approach was the right call for catching the common cases without reinventing the wheel. It's pushed to the branch — happy to adjust if you think the exclusion list is too broad or not broad enough. The offset = 25: I made it a config setting (CascadeOffset in the [general] section, default 25). This matches QuickTile's existing pattern — MarginX/Y_Percent, ColumnCount, GridRows/Cols all work the same way. Users can tweak it to match their titlebar height or personal preference. Titlebar height auto-detection seemed fragile across different WMs and themes, so a config option felt like the more maintainable choice. The grid overlay: I also added a grid-overlay command that shows a GTK overlay with a resizable grid (default 3x3, configurable via GridRows/GridCols). You can click two corners or use arrow keys (+ Shift to resize) to select an area, and the active window fills it. Bound to <Super>Return by default. All pushed to the branch. Let me know if I can add anything, I appreciate the opportunity to fine-tune your excellent program into something with all the functions I wanted. Kind regards, GM

…

________________________________ From: Stephan Sokolow ***@***.***> Sent: Sunday, May 24, 2026 5:35 AM To: ssokolow/quicktile ***@***.***> Cc: GMart ***@***.***>; Author ***@***.***> Subject: Re: [ssokolow/quicktile] Fix window centering, windowless commands, and add cascade/tile-all (PR #158) [https://avatars.githubusercontent.com/u/46915?s=20&v=4]ssokolow left a comment (ssokolow/quicktile#158)<#158 (comment)> Clearly things didn't go as planned. Just wanted to let you know I haven't forgotten about this... it's been difficult to make time for my hobby projects when I have the energy to review code. — Reply to this email directly, view it on GitHub<#158 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AF4QIHNYGBKSAPNCRM6WC3D44IKTRAVCNFSM6AAAAACYHUE46WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKMRWGU4DKOBRGI>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[ssokolow]

happy to adjust if you think the exclusion list is too broad or not broad enough.

Thanks. I'll see if I can find edge cases when I test it.

Titlebar height auto-detection seemed fragile across different WMs and themes, so a config option felt like the more maintainable choice.

How are you detecting them?

Is calculating the offset between Wnck.Window.get_client_window_geometry and Wnck.Window.get_geometry not reliable? ...because I vaguely remember calculating that on GdkWindow being what I did over a decade ago when I wasn't using libwnck and needed to work around bugs.

I could understand applications with client-side window decorations (eg. GtkHeaderbar) returning the same thing for those two calls (though I think there may still be a way to query the difference under GtkHeaderbar... maybe it's exposed in an xprop?).

The grid overlay

Starting to sound closer to what I'd been meaning to rearchitect QuickTile around for #10

...though please do be careful about how far you go. I'm fine with A.I.-generated code where the only thing it could be plagiarizing is QuickTile itself, or where it's generating "glue one API to another" code so simple that it's not eligible for copyright, but I'm not yet sure how far I'm willing to go in areas where, if A.I. training is declared to be plagiarism in the future, it may be difficult to unwind QuickTile from it.