Print

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

[fricy]

....but if that also doesn't work, all that's left is the case and a Blu-ray drive...

Ouch, finding a faulty hardware component sucks. Last time I was doing the same it turned out that whoever installed the cpu used a lot of electric conducting thermal grease. It caused instability exactly like you describe. By the time the culprit was found it fried two motherboards, a network adapter, three hard drives and a dvd drive... Just mentioning this, because even though your cpu was replaced now, it doesn't mean that the faulty one hadn't already damaged some chip on your mainboard... Or maybe it's the ram. Or... I'm so happy I'm not servicing computers any more.

[lethosor]

Someone in #dwarffortress on Freenode reported a problem with init.txt being deleted after modifying graphics settings, causing DF to crash. (I couldn't reproduce the crash by deleting init.txt, so it could have been caused by something else, but it seems likely that the deletion of init.txt was caused by PyLNP.)

[Pidgeot]

Someone in #dwarffortress on Freenode reported a problem with init.txt being deleted after modifying graphics settings, causing DF to crash. (I couldn't reproduce the crash by deleting init.txt, so it could have been caused by something else, but it seems likely that the deletion of init.txt was caused by PyLNP.)

I don't see any possible way that can happen with the code. I can think of a scenario or two where the file contents might be cleared, but even then we're dealing with incredibly bizarre circumstances (e.g. no disk space to write the file changes).

[Dricus]

While I absolutely love PyLNP, there is one thing that's been bugging me for a while now: the user interface. It looks a bit cramped, and the tabs (although they are kind of logically grouped) contain lots of settings. Especially the graphics tab took me a while to understand. Also, the original LNP's way of displaying and changing setting values doesn't really look like a proper Windows/Mac/Linux GUI. A lot of settings could be displayed using checkboxes, comboboxes and textboxes in stead of buttons.

Anyways, the last few weeks I've been trying to build a new GUI for PyLNP which is more focused towards the two most important features (at least to me): Launching Dwarf Fortress and launching utilities. Furthermore, my goal was to make it look more like a proper Windows/Mac/Linux GUI.

For this GUI, I've created a fork of Pidgeot's python-lnp Bitbucket repository and created a new GUI on top of the core modules that he already built, using PyQt4. Hence, everything that is in the GUI should actually work correctly (no guarantees though ).

Now that my hacking has resulted in something I'm actually starting to like, I'd like to show you some screenshots and release an alpha version. It's not entirely feature complete yet (no defaults button, for example), but the most important features are there. Feedback is highly appreciated!

Download

Windows executable: https://bitbucket.org/Dricus/python-lnp/downloads/PyLNP.exe
Linux executable: https://bitbucket.org/Dricus/python-lnp/downloads/PyLNP_linux
Mac executable: https://bitbucket.org/Dricus/python-lnp/downloads/PyLNP_mac.app.zip

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

Screenshots (click here for more)

Spoiler (click to show/hide)

[Pidgeot]

While I absolutely love PyLNP, there is one thing that's been bugging me for a while now: the user interface. It looks a bit cramped, and the tabs (although they are kind of logically grouped) contain lots of settings. Especially the graphics tab took me a while to understand. Also, the original LNP's way of displaying and changing setting values doesn't really look like a proper Windows/Mac/Linux GUI. A lot of settings could be displayed using checkboxes, comboboxes and textboxes in stead of buttons.

Anyways, the last few weeks I've been trying to build a new GUI for PyLNP which is more focused towards the two most important features (at least to me): Launching Dwarf Fortress and launching utilities. Furthermore, my goal was to make it look more like a proper Windows/Mac/Linux GUI.

For this GUI, I've created a fork of Pidgeot's python-lnp Bitbucket repository and created a new GUI on top of the core modules that he already built, using PyQt4. Hence, everything that is in the GUI should actually work correctly (no guarantees though ).

It certainly does look nice. I don't entirely know about the use of a separate window for settings (especially a modal window), but it seems it shouldn't be too hard to e.g. move it to a tab or something.

As far as I can tell from a quick scan of the screenshots, the missing features (compared to the current source code) are the defaults button, folder opening, pack simplification, and the entire mods interface.

I'm not a fan of the way you're handling downloads - since the action needs to be retried, I don't think the download status window should be modal. Perhaps that's another thing you want to revisit later, if so, that's fine.

I notice the UI seems to crash for some older versions; 34.11 works, but 31.01 doesn't. There's no error output, and I haven't dug down far enough to know exactly why (but my guess is that you're not handling the differences between legacy and SDL builds).

FYI: If you think you will eventually want to submit a pull request with your changes, remember that the code should strive to support both Python 2 and 3. You should import unicode_literals and print_function from __future__ to help with this.

[PeridexisErrant]

Yep, this is awesome!  The current interface is basically just sticking around from what was easiest for TolyK et al to implement in Visual Basic (shudder), so I've got no objections at all to changing it.  I think the settings should be a tab rather then a popup, but otherwise the finished part is better in every way!

Support for Qt v4 will cease at the end of 2015. PyQt5 and Qt v5 are strongly recommended for all new development.

Any particular reason to use Qt4 anyway?

[Dricus]

Thanks for the feedback, keep it coming . Good stuff! If I have the time, I'll try to create a version which has the settings in a tab and the download progress displayed in a non-modal way, somewhere today or tomorrow. I'll also have a look at the crash issues with older DF versions.

@PeridexisErrant: The reason for using PyQt4 is that PyQt5 only works on Python 3, and PyLNP is still on Python 2.7. Also, I'm not entirely sure if pyinstaller works well with PyQt5.

@Pidgeot: My ultimate goal is indeed to file a pull request once it's stable, feature complete. I'll make sure to make the code Python 2 and 3 compatible using your suggestions.

[Pidgeot]

For this GUI, I've created a fork of Pidgeot's python-lnp Bitbucket repository and created a new GUI on top of the core modules that he already built, using PyQt4.

Wait, hold on - I didn't notice this last night, but PyQt is GPL. I would not be able to accept your GUI into the PyLNP project without making PyLNP itself GPL; something which I do not want to do.

Consider switching to PySide - both are based on Qt, and it should be fairly easy to switch over, but PySide has the advantage of being LGPL licensed - and therefore eligible for adding to the main repository. (wxPython would arguably be a tiny bit better license-wise, due to an explicit permission to apply static linking, but that's going to be a much larger change, of course, and AFAIK, standard LGPL should be acceptable for the ways PyLNP is being distributed.)

[Dricus]

Switching to PySide shouldn't be problem. I will look into that as well. wxPython would require me to rewrite almost everything (which I don't really feel like), so to me that is not an option.

[Pidgeot]

PyLNP 0.9.3 is ready and uploaded. The main change is some improvements to the merging process.

At the time of this writing, Bitbucket seems to be a bit slow, so if you're downloading straight away, it may take a bit longer than normal.

Switching to PySide shouldn't be problem. I will look into that as well. wxPython would require me to rewrite almost everything (which I don't really feel like), so to me that is not an option.

Sure, that's totally fine - just mentioning it as an alternative.

[Dricus]

Quick update: I switched to PySide and integrated the settings window with the main window.

Screenshot:

Spoiler (click to show/hide)

[Pidgeot]

I notice the UI seems to crash for some older versions; 34.11 works, but 31.01 doesn't. There's no error output, and I haven't dug down far enough to know exactly why (but my guess is that you're not handling the differences between legacy and SDL builds).

After trying to run the source code directly on 31.01:

Code: [Select]

Traceback (most recent call last):
  File "launch.py", line 14, in <module>
    lnp.PyLNP()
  File "core\lnp.py", line 116, in __init__
    window = MainWindow()
  File "qtgui\main_window.py", line 37, in __init__
    self.__initialize_ui()
  File "qtgui\main_window.py", line 49, in __initialize_ui
    self.__ui.tabs.addTab(SettingsWindow(self.__ui.tabs), "Settings")
  File "qtgui\widgets\settings_widget.py", line 92, in __init__
    self.__initialize_menu()
  File "qtgui\widgets\settings_widget.py", line 99, in __initialize_menu
    CategoryTreeItem(title, page_classes))
  File "qtgui\widgets\settings_widget.py", line 49, in __init__
    self.__initialize_pages(page_classes)
  File "qtgui\widgets\settings_widget.py", line 54, in __initialize_pages
    page = page_class()
  File "qtgui\widgets\gameplay_settings_widget.py", line 20, in __init__
    self.__bind_controls()
  File "qtgui\widgets\gameplay_settings_widget.py", line 39, in __bind_controls
    QComboBoxPropertyBinding(self._ui.starting_labors, STARTING_LABORS)
  File "qtgui\bindings\combo_box_property_binding.py", line 21, in __init__
    control.addItems(prop.selection_list())
  File "core\property.py", line 118, in selection_list
    return lnp.settings.options[self._name()]
KeyError: 'laborLists'

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.

[Dricus]

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 .

[PeridexisErrant]

PRINT_MODE set to TWBT isn't valid when TWBT is not detected.

DF treats any unrecognised print mode as STANDARD, so it won't crash - but it is still a bug.

[Dricus]

DF treats any unrecognised print mode as STANDARD, so it won't crash - but it is still a bug.

It is, but IMHO PyLNP should handle these kinds of minor bugs gracefully and not just poop out a stack trace .