Skip to content

Conversation

@ChrisJohnsen
Copy link
Contributor

Addresses: #5644

This repositions the search widget and makes it functional on the "Siege engines" subtab.


Open questions:

  1. Bumping the version in PlacesOverlay is the only way I know to cause the new default_pos to 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?

  2. Should siege_engine_type be replaced with an enum-attr on siege_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.

  3. 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.

  4. 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?

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 ChrisJohnsen changed the title Cj/search siege engines search widget support for DF siege engines subtab Nov 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant