search widget support for DF siege engines subtab#5665
Merged
ab9rf merged 5 commits intoDFHack:developfrom Dec 6, 2025
Merged
Conversation
Move the Places tab search widget: - in wide interfaces it was being drawn over the new "Siege engines" subtab; move it down so it is drawn in the blank line between the subtab group and the content area (like the Tasks search widget) - in narrow interfaces it was being drawn too far right to show its text field inside the bounds of DF's Info panel; move it left into the space made available now that DF is wrapping the subtab group due to the addition of the new subtab Register a handler for the new "Siege engine" subtab; generate search keys that match the text that DF displays.
The DF info window is based on the interface area, not the full window area. So the sort info overlays should also work with the interface width instead of the window width. If DF is configured to use an interface percentage smaller than 100, then the interface area will be narrower than the full window once the window is resized beyond the minimum width. Basing the info sort overlay size on the window size can let some UI elements extend outside the footprint of the info window. For example, when the DF interface percentage is set to 90, the search box for the Task tab - is too close to the info window border at window widths 115 and 147 - shares a edge with the info window border at window widths 116 and 146 - extends beyond the info window border for window widths 117-145
There hasn't been a LABOR tab sort overlay since 50.12. The WORK_DETAIL overlay was removed in 4c92876. That commit was part of 50.12-r1~34. The DF 50.12 release notes say that work detail sorting and searching was added, and the DFHack 50.12-r1 release notes say that search widgets were removed for screens that gained native search. https://store.steampowered.com/news/app/975370/view/4136064865380703752 https://docs.dfhack.org/en/stable/docs/NEWS.html#dfhack-50-12-r1
ChrisJohnsen
changed the title
ab9rf
approved these changes
Dec 6, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Addresses: #5644
This repositions the search widget and makes it functional on the "Siege engines" subtab.
Open questions:
Bumping the
versionin PlacesOverlay is the only way I know to cause the newdefault_posto be automatically applied. Unfortunately it will also reset the enabled-state of the overlay (possibly causing thoughts like "Why does DFHack keep turning this stuff back on?!" for players that previously disabled the overlay).Should we forego the horizontal repositioning (leaving the search widget text field "squashed" in narrow interfaces) to avoid the associated unconditional re-enabling?
Should
siege_engine_typebe replaced with an enum-attr onsiege_engine_type?Myk has previously mentioned this mechanism to me. I'm not sure if this particular mapping would more generally useful in the future though.
I was initially also adding "search keys" for the siege engine action (
siegeengine_action). DF shows text descriptions for these values when viewing the building's individual info panel, but they are not shown in the Siege engines subtab (only the graphical buttons are shown—without even any hover explanations).While it seems like it might be useful to search by "action", I ultimately found it too surprising. E.g. I had a catapult named "C center" and searched for "ce", but another siege engine that was set to "Practice Fire" also turned up.
The "loaded status" and "operator status" are displayed by DF in the Siege engines subtab, so I made them searchable, but maybe only the name/type should really be searchable?