HostedRedmine.com has moved to the Planio platform. All logins and passwords remained the same. All users will be able to login and use Redmine just as before. Read more...
Main window can jump about when unit stack size changes
In the Gtk3.22 client, and the Gtk3 client on S3_0+, with "Arrange widgets for small displays not set", in tilesets where units are considered particularly wide (like ampliohexbig):
The left column of the main map view can be different widths depending on the number of units on the current unit's tile (different widths for 1/2, 3, and 4+). This causes the view to jump about irritatingly when changing focus.
Gtk2 is fine, as is Gtk3 on S2_6.
This is anti-correlated with use of gtk_pixcomm for
unit_below_pixmap. I'm guessing that gtk_pixcomm was setting a fixed size request, and the new arrangement is not.
In gna bug #23562 , I solved a similar problem for the "more units" button in Gtk2/3 by adding an extra GtkContainer around
more_arrow_pixmap_button's GdkPixbuf. That would presumably work here, although perhaps we can set a size request directly, I haven't looked yet.
(That 2015 bug says that it "reduces but doesn't completely eliminate the effect when using the Gtk3 client with the Freeciv theme. My prejudice is that this must be a bug in the theme, adding padding to layers of widget hierarchy that should be invisible. Doesn't happen with the system Greybird theme." I don't think I can have been running into this, as it looks like pixcomm removal was in 2016. So maybe there will be a remaining contribution from some padding.)
#1 Updated by Jacob Nevins over 2 years ago
- File m-gtk3-unit-buttons-size.patch m-gtk3-unit-buttons-size.patch added
- File 30-gtk3-unit-buttons-size.patch 30-gtk3-unit-buttons-size.patch added
- File 26-gtk3-unit-buttons-size.patch 26-gtk3-unit-buttons-size.patch added
- Status changed from New to Resolved
- Assignee set to Jacob Nevins
- Sprint/Milestone set to 2.6.2
Changes were easier than gna bug #23562, as the unit buttons are always shown even when they are not in use.
Gtk4 changes, as usual, not compile-tested, and they were not completely trivial due to feature #778842. I don't know for sure that Gtk4 suffered the symptom, or that this helps; but I think it probably did, and I think it should compile.
(Sorry about this. I should really sort out ability to compile against Gtk4.)