Bug #2475
opengtk4: unit selection dialog does not show activity change
0%
Description
If you click a tile with more than one unit on it, you get the unit selection dialog.
If you use the "Ready" or "Sentry" buttons on the dialog, they work, but they appear not to work within the dialog, as it does not show the change.
Similarly, if you use the buttons on a unit that is loaded on a transporter, not only does it not update, but the tree it is in collapses, and you have to open it again.
Less commonly, if you have the dialog open and something else happens to a unit you are looking at in it -- maybe it takes damage, or an allied unit leaves a transporter -- then that is not reflected.
The main difficulty is that attempting to refresh the dialog wipes the whole tree and rebuilds it. The packet handling code only attempts to trigger a refresh if a change happens to a unit that is focused or on the focus tile, but the unit selection dialog is frequently showing units that are not focused or on the focused tile.
I have rewritten the dialog so that when refreshing, it updates rows in the GtkTreeStore rather than wiping the whole store and rebuilding it. This solves all these problems. You can now observe a player, open the dialog, and see changes in it as they are triggered. It's not actually possible to open the dialog in global observer mode, but if that were enabled you could see the state of all the units in it live.
Files
Updated by Andrew McGuinness about 8 hours ago
- File 0001-gtk4-change-the-structure-of-the-unit-selection-data.patch 0001-gtk4-change-the-structure-of-the-unit-selection-data.patch added
- File 0002-gtk4-update-the-unit-selection-dialog-live-with-all-.patch 0002-gtk4-update-the-unit-selection-dialog-live-with-all-.patch added
This is the rewrite. Basically, it doesn't clear the treestore if it already exists, it makes a pass through the existing treestore updating or removing the rows based on the unit state in the fresh data, and then makes a pass through the fresh data adding anything that wasn't present.
It's not simple or elegant, I'm very open to suggestion relating to style or structure. But it handles all the edge cases I could think of (such as units leaving nested transporters).
I don't think it depends on RM #2442 , but it certainly makes sense to look at that one first, not least because it is a more noticeable improvement for a lot less work.