no Center new windows on screen, no Attach modal dialogs to windows
Main window: opens somewhere near to the upper left corner
Preferences: window opens in the center of the screen with its natural size
About box: opens in center of the main window, doesn’t stick to main window
Attach modal dialogs to window
Preferences: same as above
About box: same as above, but sticky to main window
Center new windows on screen, but not Attach modal …
Preferences: same as above, i.e. always opens in the center of the screen
About box: same as in first case (not sticky)
Window rules engaged (see rule below):
no Center new windows on screen, no Attach modal dialogs to windows
Main window: opens at the rule-specified position and size
Preferences: Opens in the center of the screen at way to small size, after short moment (few seconds) or after changing focus, moves to upper left corner (still same size):
_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 30, 0
(sorry, can’t get the position while in center, because window moves at focus change). Even if window is resized and opened again, same behavior. When trying to resize the window, while it is still in the center, the frame resizes, but the window content doesn’t render.
About box: Opens in upper left corner at reasonable size:
_GTK_FRAME_EXTENTS(CARDINAL) = 56, 56, 50, 63
Attach modal dialogs to window
Main Window: same as above (some visual effect, because the window maps in upper left corner, then only gets positioned)
Preferences: same as above
About box: opens ok (centered to main window, sticky)
Center new windows on screen, but not Attach modal …
Main Window: same as above (some visual effect, because the window maps in center of screen, then only gets positioned)
Preferences: same as above
About box: opens in upper left corner at ok size:
_GTK_FRAME_EXTENTS(CARDINAL) = 56, 56, 50, 63
Window rule definition:
WM-class: nemo
Grid: 5x3
X, Y: 0,1
Span: 1x1
Display: not set
Workspace: not set
I’m running this on a 4k screen at 3840x2160px. I feel that WindowShuffler is using a hook and is not passing on the requested window geometry if it is NOT a normal window. Hope, this helps. Feel free to ask back. I’d very much appreciate, if this feature becomes available in Ubuntu Budgie 22.04.
Interesting observation, didn’t run into it before with any other application. Thanks for the detailed report.
Although results are slightly different on my (also 4k) laptop, the positioning of nemo preferences seems to be affected by rules, although I am positive shuffler does not take action on any window, other than type NORMAL. Possible explanation could be a timing issue with nemo, changing/setting its window type after creation of its preferences window, at a point where shuffler already started its action. The resulting size & position doesn’t seem to refer to anything shuffler is set to do though, so that’s weird.
We know of some other applications which are problematic in some ways, getting their final window name after having an “intermediate” temporary name, or applications, incorrectly setting their dialog- or splash windows as NORMAL typed windows.
It needs to be investigated to understand exactly what is happening during creation of nemo’s preferences/about windows. Since we’re approaching freeze date, it is unlikely to have any effect on 22.04’ coming release though.
I have given Nemo just as an example. I can also observe behaviors with Evolution (mail). Also firefox is affected, but that is probably a special case (but important).
Anyways, I think it is not critical, not even high prio and can be fixed even after release. It’s just a pity that the feature is practically not usable. I was waiting for something like this since long. But again, as you are claiming that other than normal windows would not even be treated by WindowShuffler: I guess you are using some hooks. Can it be that in case of not treating a window, the hook has to somehow pass on original parameters if not treating the window?
btw.: I’m amazed, how fast I was getting response on this. Thanks.
Hah, I believe the issue is fixed.
Thing is/was that shuffler maintains info on currently existing windows, filters out only NORMAL windows. Rules however was during development hooked upon new-window-signal, which was originally only available as an option in gsettings for those who wanted to hack the functionality. Since this was (again originally) a “free” option, you could make it do anything, it was surpassing the existing window-type check for the database.
Will push it tomorrow , will be available in daily, should be tested thoroughly to make sure It doesn’t break anything, but it seems unlikely.
Great! Will spend some time on testing. Thanks again, looking forward.
Feature request: to add another argument for specifying a wildcard match on window name, to distinguish normal windows (like Evolution main window from Email windows).