Floating window resize issue

[mathstuf]

So making a summary for this isn't easy. Here's the setup:

• two monitors
• different resolutions (important!)
• keyboard focus on A
• cursor on B

When using a manage hook to float dialogs (isDialog --> doFloat), it is stored in the layout according to the cursor screen resolution (B). When the window actually appears, it shows up next to the currently focused window (on A). However, because the resolutions are different, the ratio stored in XMonad for its location is a different size. When the window appears, XMonad resizes it to be the same ratio, but that means the resolution is different. Dialogs (possibly made worse due to improper size hints) then either get inflated with empty space or squished together with overlapping widgets.

The fix should be to determine the ratio of new windows based on where they will appear rather than the cursor-current screen resolution.

See coldfix/udiskie#79.

[geekosaur]

I had already noticed this and was considering fixes, but as there haven't been complaints previously I was only considering windows with a defined aspect ratio or resize increment (e.g. most terminals, the programs inside which can break rather badly).

[mathstuf]

It also appears that XMonad isn't respecting size hints about minimum or maximum sizes, but that's probably a different issue.

[schlueter]

This was originally reported to the xmonad mailing list back in 2010, and although they had some insights not mentioned here, that thread didn't go anywhere either.

One notable insight:

I think the problem is that xmonad internally represents window dimensions
as fractions of screen size, and these are computed from the initial window
position and size. So, if an application creates a new window at (0,0) and
then asks the window manager to position it, xmonad computes the size as a
fraction relative to the screen containing (0,0) and then places the window
on whatever screen is currently active. If the size of this screen is
different, so is the size of the placed window.
-- Massive Rhino

[bluss]

This seems to be the same bug: kupferlauncher/kupfer/issues/74

[jonhoo]

@pjones is this something that is being worked on? I keep seeing this pop up all over the place, though mostly for gtk dialog boxes (file pickers, launcher windows, pinentry-gtk), and it is quite distracting. Is it something you can reproduce locally?

[pjones]

@jonhoo I don't believe this is actively being worked on, there just aren't enough people contributing code. If you have some time I would love to see a patch ;)

[jonhoo]

Unfortunately I don't think I know enough Haskell, or enough about window managers/xmonad specifically to be of much help :(

[nlw0]

I have two different monitors, one of them I sometimes use in vertical mode. Working with matplotlib, I have noticed my figures, which are floating windows, will be stretched down when I move from the horizontal to the vertical monitor. I believe this is related to this issue?

This is quiiiite annoying to me, and I would love to try working on it. Help would be very much appreciated!

One "fix" would be to always make sure window size ratios are the same, even if they still get resized between screens, IMO a much more reasonable thing than maintaining the relative vertical and horizontal sizes... You just need to stick to e.g. the vertical screen size, might be a very simple fix like this.

[mathstuf]

Related, but it isn't this issue. This issue is about sizing new windows based on where they appear rather than where the mouse or focus is.

That issue is probably a size hint only allowing one dimension to change while the other is limited or fixed.

[wedens]

I've noticed the same issue with keepassxc dialogs. They appear cut off.

[liskin]

@wedens Can you please try if #221 helps?

[wedens]

@liskin Unfortunately, seems like the issue is still there. For example:

[liskin]

@wedens Does the dialog size change depending on which display is currently focused? Do you have different resolutions on your displays? If not, then it might be a different issue than #5.

[wedens]

@liskin I have a single display.

[liskin]

If you have a single display, then it's 100% not #5. Try #207 then.
(I've been meaning to take a look at #207 myself for some time but didn't get to it yet.)

[wedens]

@liskin #207 doesn't help. Is it some new issue then?

[liskin]

@wedens No other ideas :-/

[liskin]

The original issue reported here was definitely fixed by merging #221, so I'll close this one.