Bay 12 Games Forum

• Added a widget for installing mods to the settings window.
• Implemented the Defaults button.
• Implemented the Update dialog.

• Switched to PySide
• Integrated the settings dialog in the main window
• Download progress is now shown in a status bar instead of in a modal popup dialog
• Shouldn't crash anymore when an unknown setting or setting value is encountered

I dislike it, because it means that there's no way to preserve an unknown value - it would get clobbered as soon as that file is re-written. If, for example, a user decides he wants to test the 2DASYNC print mode on his machine, it wouldn't really be possible to use PyLNP at the same time.

I am well aware that the starter packs are the main source of PyLNP users, and those users aren't really going to do such things - but I do not want to exclude other users, which is part of the reason why PyLNP supports every DF version. This thought doesn't just apply to older versions, but also (in so far as it is possible) future versions, and that requires allowing unknown values for settings.

Now, I haven't had a chance to check out all of your changes yet, but it seems like that's not currently possible, due to your implementation (and creation) of SelectionListSettingProperty (it works with indexes, not strings). On the Qt UI side, at least, it should be possible to achieve a similar effect with editable comboboxes and an insert policy of NoInsert.

On a related note: This actually goes beyond just comboboxes. When SET_LABOR_LISTS was introduced in 0.34.03, it was a boolean. In 0.34.07, it gained multiple settings. Suppose we had a PyLNP release with the same basic structure as your Qt-based branch, but made at the time of 0.34.06, and with SET_LABOR_LISTS as a checkbox. What happens if we try to use it to manage 0.34.07? Obviously toggling it wouldn't give the right results, but so long as the user doesn't do this, everything should still work. (If I'm reading the code correctly, it *should* work, but I'm not 100% sure.)

• Replace them all with LNP-style togglebuttons. This sacrifices a little bit of user friendliness (imho), but is more compatible with how PyLNP works under the hood.
• Leave them as they are now, and make sure unknown values don't get overwritten if the user doesn't change the combobox or checkbox value.
• Add the setting value to the combobox's (or setting's) list of possible values, but don't make the combobox editable. This way we're able to show the user the actual value of the setting, even if it's an unknown one.
• Make comboboxes editable when the underlying setting contains an unknown value. This way we're able to show the user the actual value of the setting, even if it's an unknown one. Users then won't be able to enter custom values for settings that contain a known value.
• Make all comboboxes editable for consistency's sake.
• Replace all checkboxes with (editable) comboboxes, so unknown values will also be visible for YES/NO properties. This will account for situations like the SET_LABOR_LISTS setting you mentioned.

Unknown values are indeed also likely to be a thing with dropdowns. I'm not sure how that should work when using a dropdown - in the current UI, it should preserve the option, but once you start changing it, you can't go back to the old value (without editing the init files manually, of course).

In the case of the unknown *setting*, my personal preference would be to building the UI at run-time, rather than using a pre-designed widget. Not only should it be easier to add more options this way, but it would also prevent non-applicable options from being shown entirely, rather than disabling them at runtime (because the controls simply wouldn't get created).

Essentially, the problem is that you're not handling the case where a dropdown is being used for a setting that doesn't exist. This particular setting was added in 0.34.03, so any version before that would break here.