New gui.dflayout module to provide position information for DF UI elements; starting with fort mode toolbars
#5385
Conversation
These should be equivalent for the integer values being processed here. The tests (entirely different calculations) pass. Also, checked negative values (not that the difference should go negative) and it still holds as equivalent. Not sure it is worth it though.
Easier way to position overlay relative to a (supported) DF UI element.
docs/dev/overlay-dev-guide.rst
Outdated
| while still being player-customizable:: | ||
|
|
||
| local overlay = require('plugins.overlay') | ||
| local Label = require('gui.widgets.labels.label') |
There was a problem hiding this comment.
I have a local commit that changes this to the normal local widgets = require('gui.widgets').
I can push it whenever, but thought I might hold on to it (avoiding a possible Windows-build CI hiccup) until I also have something substantive from my attempts to further generalize the overlay placement code.
The UI elements that were initially supported (toolbars and their buttons) were all fixed-sizes and had inset values that were non-decreasing as the interface width grew. The new functionality supports UI elements that grow with the size of the interface area and have inset values that may increase or decrease as the interface size (or other DF state) changes. The "item list" part of two tabs from the DF info window are given as a demonstration "UI element": the Orders tab and the Places/Zones sub-tab.
The first is the previously-internal wrapper around calling `.frame_fn`. This should help with callers treating the UI element values as opaque, since `frame_fn` was the most interesting bit there. The second is the previously-internal "relative positioning" function used in `getOverlayPlacementInfo`. It should be useful in other contexts that would like to do element-relative position calculations, but without the extras stuff that overlay-positioning requires.
Provide access to the state_fn internal bit of UI elements.
|
The previous code couldn't handle overlay placement for UI elements that moved closer to the edges (smaller insets) when drawn for interfaces of varying sizes. I picked the Orders info tab to experiment with. Its central orders list mostly expands as the interface size grows, but the right, top, and bottom insets all vary in different ways. I also added the Places/Zones tab since the Both of these are exported as "experimental" and not mentioned in the documentation since there may not be anything that actually needs them. The new "features" and "state" bits may be a bit raw. The Orders and Zones UI elements need to check things that aren't just related to the interface size, specifically they need to compare how many items are available with how many item rows can be displayed to know whether a scrollbar will be needed (affecting their right insets). I originally had the "state change" detection code use the "features" return of |
Here is the library code from DFHack/scripts#1426 moved to a top-level DFHack Lua module.
This spin has tests, and two hunks of docs: one for the library itself, and another in the overlay dev guide that describes a generalized "UI-relative" positioning technique (the warmdamp technique, but using the new library to encapsulate the magic numbers, and extending to right- and top-anchored overlay positions).