Fix popup height constraints#224
Conversation
c4e7d4e to
e1292af
Compare
|
Didn't check issues first, but this perhaps fixes #148 And I suppose more accurately this PR/commit should be titled fix size constraints, not height. Oh well. |
|
Hmm, this looks good at first glance, and I don't doubt it helps some use cases. However, as per the top of the readme this project is in maintenance mode. I'm committed to not breaking existing users, and releases are infrequent. I encourage apps to use GTK4 (I don't know if this works right on GTK4 Layer Shell either, but if it doesn't I'd be much more open to a fix). Is this fix vitally important for an existing app, or app that must be GTK3 for some reason? If not I'm inclined to leave the logic as-is. |
|
idk, this does look more correct. If this is a useful fix for legacy apps with real users and somebody cares enough to add tests I'll consider merging. |
|
GTK3 may not be fully maintained, but it's still widely used. xfce4-panel & xfdesktop (layer shell windows) have an applications menu, and the menu (or one of its submenus) is often longer than the screen height. This bug makes the menu unusable in those situations. (We have zero plans to migrate to GTK4.) I'm going to be traveling for the next couple weeks, but I'll look into adding tests when I get back, if that's a gate to merging. |
If a popup menu has enough items to be taller than the output/screen size, the compositor may send a configure event telling the client the max height of the menu. However, gtk_window_move()/gtk_window_resize() doesn't trigger a code path that actually honors the passed size in some cases. Using gdk_window_move_resize() does trigger the right code path, and menus are constrained properly. We also need to add in the shadow widths/heights, as the GdkWindow considers them a part of its geometry, while from the GtkWindow's perspective, the passed geometry doesn't include shadows. If the widget is not yet realized (and thus no GdkWindow is available), we fall back to gtk_window_move()/gtk_window_resize().
e1292af to
9f29786
Compare
|
Ok, I added a test, but it needs some work, as it hard-codes the (certainly theme-dependent) shadow width in the (FWIW, the test fails without the fixes in this PR, as I also changed the code a bit; realized that the library shouldn't just blindly accept the width/height the compositor suggests, but should take its own needed size into account, and only shrink when the configure event says there isn't enough room. It seemed to work fine without that, but figured this would be a safer change. (Also the compositor is allowed to pass 0 for width/height, in which case we should stick with our own size.) |
|
|
|
Thanks! Sorry that took a while. Will be in next release, whenever that ends up being. |
|
Great, thank you for taking care of it! |
If a popup menu has enough items to be taller than the output/screen size, the compositor may send a configure event telling the client the max height of the menu. However, gtk_window_move()/gtk_window_resize() doesn't trigger a code path that actually honors the passed size in some cases.
Using gdk_window_move_resize() does trigger the right code path, and menus are constrained properly. We also need to add in the shadow widths/heights, as the GdkWindow considers them a part of its geometry, while from the GtkWindow's perspective, the passed geometry doesn't include shadows.
If the widget is not yet realized (and thus no GdkWindow is available), we fall back to gtk_window_move()/gtk_window_resize().
By opening this pull request, I agree for my modifications to be licensed under whatever licenses are indicated at the start of the files I modified