-
-
Notifications
You must be signed in to change notification settings - Fork 290
-
-
Notifications
You must be signed in to change notification settings - Fork 290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Floating window resize issue #5
Comments
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). |
It also appears that XMonad isn't respecting size hints about minimum or maximum sizes, but that's probably a different issue. |
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:
|
This seems to be the same bug: kupferlauncher/kupfer/issues/74 |
@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? |
@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 ;) |
Unfortunately I don't think I know enough Haskell, or enough about window managers/xmonad specifically to be of much help :( |
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. |
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. |
I've noticed the same issue with keepassxc dialogs. They appear cut off. |
@liskin Unfortunately, seems like the issue is still there. For example: |
@liskin I have a single display. |
@wedens No other ideas :-/ |
The original issue reported here was definitely fixed by merging #221, so I'll close this one. |
So making a summary for this isn't easy. Here's the setup:
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.
The text was updated successfully, but these errors were encountered: