Skip to content

Conversation

@ChrisJohnsen
Copy link
Contributor

Other EditField conflicts will be posted in an issue, but these seemed small- and effective-enough to put into commits.

The encapsulation violation for the CivBox fix isn't exactly pleasant, but it would probably be much more invasive to get EditField to support post-init reconfiguration.

These UIs have hotkeys that conflict with the new EditField editing features,
but the EditFields can are only occasionally focused. Add `disabled` fields to
the conflicting hotkey labels so the player can tell that they are not
available while the EditField is focused.
I'm not aware of any problems from this, but it looked wrong.
The new EditField implementation has a different internal structure.
`ignore_keys` works as part of initialization, but changing it post-init no
longer works. We have to reach "deeper" to change the effective `ignore_keys`
field.

Also, a remove a stray comma. It didn't cause problems, but it was
semantically odd.
@ChrisJohnsen
Copy link
Contributor Author

Should the changelog have separate entries for each of the fixes? Or maybe just one entry to cover everything once the other UIs mentioned in DFHack/dfhack#5226 are also addressed? "Restore (or show when unavailable) some UI hotkeys that were previously masked by new text-editing features."

@ChrisJohnsen
Copy link
Contributor Author

The consensus on Discord seems to be in favor of adopting new UI hotkeys to let the "conflicting keys" be used uniformly as editing keys. Closing this since that probably applies to these cases too. The CivBox change (f2987e2) can always be cherry picked later.

myk002 added a commit to myk002/scripts that referenced this pull request Feb 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

No open projects
Status: Done

Development

Successfully merging this pull request may close these issues.

1 participant