Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Pidgeot]

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.

Thanks! I noticed that problem too after installing a graphics pack on a clean DF instance. That graphics pack had PRINT_MODE set to TWBT by default, which isn't valid when TWBT is not detected.

Edit: On second thought, this is not entirely the same problem. I guess I'll have two bugs to fix then .

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

Of course, I'm sure it's much easier to test things out like this and narrow the layout down to something that works - so I wouldn't worry too much about that yet.

[Dricus]

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

Yeah, I'll see if I can think of a way to gracefully handle this.

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

My personal preference when it comes to designing GUI's for desktop applications is to use a WYSIWYG editor like Qt Designer, which I've used to design the Qt GUI. That way I'm much more productive and there's much less source code to maintain and much less regular refactoring needed to keep that code maintainable. It's still possible to not show controls for unknown settings, but it will just look a bit differrent in code.

[Dricus]

A possible solution for the case of unknown values could be to modify DFConfiguration.create_option to keep a dict of fallback options for fields with a limited set of possible values:

Code: [Select]

        if values is not None:
            self.fallback_options[name] = default

DFConfiguration.read_file could then account for that like this:

Code: [Select]

                if match:
                    if (self.options[field] is _force_bool and
                            match.group(1) != "NO"):
                        #Interpret everything other than "NO" as "YES"
                        self.settings[field] = "YES"
                    elif (isinstance(self.options[field], tuple) and
                            match.group(1) not in self.options[field]):
                        self.settings[field] = self.fallback_options[field]
                    else:
                        ...

What I like about this solution is that the "problem" is solved as soon as possible. Opinions?

[Pidgeot]

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

[Dricus]

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.

Good point, didn't think of that.

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.

It should be quite easy to change the implementation of SelectionListSettingProperty to use the plain value in stead of indexes. For settings with an unknown value, the editable flag of the checkbox could be set to true, so the unknown value will be displayed and be editable. Another possibility could be to just add the unknown value to the list of possible values of the setting when the config is loaded.

For YES/NO properties it's different, because a checkbox can't display anything else than checked, unchecked or unknown.

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

As long as you don't change the setting via the GUI, (whether it's a checkbox or a combobox), the unknown value won't be overwritten, as the underlying setting won't be changed.

When it comes to checkboxes and comboboxes there are a number of options to consider for the Qt UI, including but not limited to:

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

[Pidgeot]

It should be quite easy to change the implementation of SelectionListSettingProperty to use the plain value in stead of indexes. For settings with an unknown value, the editable flag of the checkbox could be set to true, so the unknown value will be displayed and be editable. Another possibility could be to just add the unknown value to the list of possible values of the setting when the config is loaded.

For YES/NO properties it's different, because a checkbox can't display anything else than checked, unchecked or unknown.

Changing the set of possible values/editability at runtime seems like it would complicate things too much and remove UI consistency (it seems odd if only one combobox is editable, and adding values could be a bit tricky to implement right, since the inits can be edited manually at run-time)

I have a *slight* preference towards making all the comboboxes editable... it wouldn't be a big deal to me either way, but making them editable would allow for certain more advanced use cases to be done without editing the inits manually (e.g. using an unusual print mode).

Regarding the use of comboboxes instead of checkboxes... that's a bit tricky. I'm okay with just preserving the value (although I think I would prefer it if any non-"NO" value was displayed as checked, rather than the other way around), but if SET_LABOR_LISTS is always displayed as a combobox, that makes it feel out of place for 0.34.03-0.34.06. Moving everything over to editable comboboxes would maximize UI consistency, but checkboxes *are* an appealing choice for binary options... I don't know. I'm leaning towards comboboxes for all, but it's not the kind of thing I'd be likely to care much about as a user, so perhaps I'm not the best person to judge that (although from a pure code perspective, it seems like it might be the simplest option?)

[Pidgeot]

PyLNP 0.9.4 is now up. The main change is a fix for a cross-thread event bug that seems to have been limited to Linux, but theoretically might affect Windows and OS X too. This bug prevented downloads from working properly, so upgrading is recommended even if you haven't noticed any issues.

[Pidgeot]

0.9.5 is up now. In addition to fixing more bugs with graphics and mods merging, it also fixes the "/bin/sh: symbol lookup error: /bin/sh: undefined symbol: rl_signal_event_hook" error that could be seen on some Linux systems (those using bash 4.3/readline 6.3).

There are also some internal changes, which are really only relevant for developers at this point - I suggest reading the commit list if you're interested.

[PeridexisErrant]

0.9.5 is up now. In addition to fixing more bugs with graphics and mods merging, it also fixes the "/bin/sh: symbol lookup error: /bin/sh: undefined symbol: rl_signal_event_hook" error that could be seen on some Linux systems (those using bash 4.3/readline 6.3).

There are also some internal changes, which are really only relevant for developers at this point - I suggest reading the commit list if you're interested.

User-relevant changes:
 - fixed a rare bug where changing graphics instead deleted your raws
 - made updating graphics on saves faster (almost instant if you're not using mods)
 - better feedback during mods install and save-protection features

And on the dev end, I think I might add logging to the mods module over the next few days, to make tracking down further bugs less painful.

[Dricus]

Edit: I created a bug report on Bitbucket for this issue.

In the last version of PyLNP, there has been a change to json_config.py so it now always returns deep copies of configuration data instead of references to the actual configuration data itself. Because of this, toggling hacks in hacks.toggle_hack doesn't work anymore. The line of code quoted below doesn't have any effect anymore, because it just changes a copy of the configuration, not the configuration itself:

Code: (hacks.py line 83) [Select]

    get_hack(name)['enabled'] = not get_hack(name)['enabled']

[Pidgeot]

Edit: I created a bug report on Bitbucket for this issue.

In the last version of PyLNP, there has been a change to json_config.py so it now always returns deep copies of configuration data instead of references to the actual configuration data itself. Because of this, toggling hacks in hacks.toggle_hack doesn't work anymore. The line of code quoted below doesn't have any effect anymore, because it just changes a copy of the configuration, not the configuration itself:

Code: (hacks.py line 83) [Select]

    get_hack(name)['enabled'] = not get_hack(name)['enabled']

...I did not think that change through, it seems.

Making 0.9.5a with this change rolled back; should be up in 15-30 minutes or so.

EDIT: It's up now.

[Dricus]

Heyo, I've uploaded a second alpha version of my Qt GUI for PyLNP.

Changelog

• 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

Download

Windows executable: https://bitbucket.org/Dricus/python-lnp/downloads/PyLNP-qt_gui-alpha2-win.zip
Linux executable: https://bitbucket.org/Dricus/python-lnp/downloads/PyLNP-qt_gui-alpha2-linux.tar.gz
Mac executable: https://bitbucket.org/Dricus/python-lnp/downloads/PyLNP-qt_gui-alpha2-mac.zip

Source code: https://bitbucket.org/Dricus/python-lnp

[Zanzetkuken The Great]

I just downloaded the latest version, and after getting webroot to allow it through, now it won't let me execute the file, saying I don't have adequate permissions.  Can someone explain to me why this is?

Edit: Preferably before I snap my computer in half in frustration as to why nothing is working.

[Pidgeot]

I just downloaded the latest version, and after getting webroot to allow it through, now it won't let me execute the file, saying I don't have adequate permissions.  Can someone explain to me why this is?

Edit: Preferably before I snap my computer in half in frustration as to why nothing is working.

Perhaps Webroot is still blocking it? Other than that, I don't have any ideas off the top of my head - try posting the complete error message (CTRL+C should copy it); maybe that'll provide a better clue.

Also, which version and edition of Windows are you using? That might affect how you'd need to resolve certain issues.

[Zanzetkuken The Great]

Perhaps Webroot is still blocking it? Other than that, I don't have any ideas off the top of my head - try posting the complete error message (CTRL+C should copy it); maybe that'll provide a better clue.

Also, which version and edition of Windows are you using? That might affect how you'd need to resolve certain issues.

Windows 7.

Upon launch it says: Windows cannot access the specified device, path, or file.  You may not have the appropriate permissions to access the item.

I'm running it as administrator.