Print

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

[PeridexisErrant]

No objections, that sounds great.

[Pidgeot]

V0.10c is up. It adds support for DF 0.42.01, and a few minor features for pack authors by PeridexisErrant (described below).

Pack maintainers: I can only provide Windows builds at the moment; you will have to compile yourself or rely on others to get binaries for other platforms.

Hacks are being handled slightly differently to allow dfhack to auto-load certain scripts automatically. You can specify a file prefix of "dfhack", "onLoad" or "onMapLoad" using the "file" value in PyLNP.json; the hacks will then be written to <prefix>_PyLNP.init.

Finally, keybinds for the SDL version may now be distributed as only the changed bindings compared to vanilla.

[PeridexisErrant]

V0.10c is up. It adds support for DF 0.42.01, and a few minor features for pack authors by PeridexisErrant (described below).

Pack maintainers: I can only provide Windows builds at the moment; you will have to compile yourself or rely on others to get binaries for other platforms.

Hacks are being handled slightly differently to allow dfhack to auto-load certain scripts automatically. You can specify a file prefix of "dfhack", "onLoad" or "onMapLoad" using the "file" value in PyLNP.json; the hacks will then be written to <prefix>_PyLNP.init.

Finally, keybinds for the SDL version may now be distributed as only the changed bindings compared to vanilla.

Yay!  (Sorry, non-windows people.)

Note that the DFHack "file" value is optional.  If you don't set it or use an invalid option, it'll default to "dfhack".

You can see example minimal keybinds here.  Loading and saving keybinds will also convert them to the minimal format.

[Pidgeot]

I've just uploaded a minor update v0.10d. The primary reason is to make the UI a bit shorter, because it was getting a bit too tall. As a result, I have decided to move the Aquifers setting into the Gameplay Options section, and reduce the default size of the embark profile list by about 25%.

I have also added the ability to override the DF executable name if you want to use a custom startup script or something (using command-line argument --df-executable).

For pack maintainers, there are also some initial steps towards some automation that may be of interest to you (see issue #98). This will not be of interest to users, however, so it does not justify moving to 0.11.

Still no Linux or OS X builds, so that will have to be provided from other people (or you can just run from source, of course).

[txtsd]

Why aren't graphics packs recognized unless they contain all 3 files (init.txt, d_init.txt, colors.txt) in the init folder?

[PeridexisErrant]

It's not a valid graphics pack without them, to define which tileset, what tiles to what, and what colour things are respectively.  We could fall back to vanilla settings if one is missing, but that's more likley to cause hard-to-debug problems than really help anyone.

[txtsd]

It's not a valid graphics pack without them, to define which tileset, what tiles to what, and what colour things are respectively.  We could fall back to vanilla settings if one is missing, but that's more likley to cause hard-to-debug problems than really help anyone.

That makes sense, thanks.

EDIT: Pidgeot could you take a look at my Pull Request please?

[DOZO]

Is it just me or has the init editor stopped working? The 'Save' button doesn't seem to do anything.

[txtsd]

I'm working on a Qt based GUI for PyLNP. I've only got the basics done so far (no demo list items), but please let me know what you guys think. I've tried to keep close to the current PyLNP layout.

Images are links to albums of screenshots of all the tabs.



The dark UI is just the theme I use on my desktop. It's an example of how your gtk/qt theme can integrate more or less seamlessly.
The second one is Qt's built-in fusion theme. It's an approximation of what it would look like with Adwaita.
The last one is Qt's built-in windows theme. It looks very win98/winxp, and I'm not sure if that's how it will look on modern Windows. It should look better when actually run in a Windows environment.

There's also Dricus' Qt GUI implementation, but it wastes a lot of space imo and shows very little information at a time. The screenshot uses Adwaita because there are a couple of hardcoded background colors which make it impossible to read on a dark theme.

[Pidgeot]

I don't have time to look too much at it right now, but please pay attention to some of the discussion we've previously had regarding Dricus' attempts (https://bitbucket.org/Pidgeot/python-lnp/pull-requests/41/replace-the-tkinter-gui-with-a-qt-gui). For example: make sure you're using Pyside and not PyQt (because of licensing issues), and make sure your code ends up still handling older versions correctly (SET_LABOR_LISTS is a particularly unusual one, because it existed as a boolean-type option for a few versions in the early 0.34 days).

[lethosor]

Is there a reason why the Tk UI doesn't use ttk? I've found that replacing tkinter.Button with ttk.Button looks a lot better on Windows (although it looks no different on OS X, but the default background color around the button is wrong). I haven't seen what PyLNP looks like on Windows, but I suspect other widgets like checkboxes could be improved by using ttk as well. (OS X uses a single UI theme regardless of ttk usage, so it looks pretty good there.)

[Pidgeot]

It does. Tkinter and ttk are imported in such a way that if a widget has a ttk version, it gets used automatically.

Code: [Select]

from tkinter import *
from ttk import *

I make an exception on OS X, where it uses the tkinter button regardless (because of that border you mention), but everytjing else uses ttk where possible to get a more native look and feel.

[txtsd]

I don't have time to look too much at it right now, but please pay attention to some of the discussion we've previously had regarding Dricus' attempts (https://bitbucket.org/Pidgeot/python-lnp/pull-requests/41/replace-the-tkinter-gui-with-a-qt-gui). For example: make sure you're using Pyside and not PyQt (because of licensing issues), and make sure your code ends up still handling older versions correctly (SET_LABOR_LISTS is a particularly unusual one, because it existed as a boolean-type option for a few versions in the early 0.34 days).

I saw it after I made this. It's just ui files right now. There's no code involved yet.
Do you know why Dricus has been MIA since the middle of the year?
Should I fork his branch and pick it up from there?

[lethosor]

It does. Tkinter and ttk are imported in such a way that if a widget has a ttk version, it gets used automatically.

Code: [Select]

from tkinter import *
from ttk import *

I make an exception on OS X, where it uses the tkinter button regardless (because of that border you mention), but everytjing else uses ttk where possible to get a more native look and feel.

Ah, okay. There was a discussion on IRC that made it sounds like it's using the older tk theme on Windows. Maybe people prefer specific Qt themes, though - is there a way to switch themes with ttk? (I'm pretty sure I've seen Tcl demos of it, but I don't know if Tkinter offers the ability to do that or if it would have to be implemented manually.)

[Dricus]

I saw it after I made this. It's just ui files right now. There's no code involved yet.
Do you know why Dricus has been MIA since the middle of the year?
Should I fork his branch and pick it up from there?

MIA? Me? I'm here . I'm still following the PyLNP development, but it's just that time again when real life kicks in. Holiday, new job, lots of courses to follow, stuff like that...

As for your UI prototype: For me, it was a very deliberate decision to show much less information on the screen than the current UI does. In my humble opinion, your prototype (just like PyLNP and the old LNP launcher) looks sort of haphazardly thrown together. I mean, why should FPS, sound, save related stuff, process priority, embark, etc all be visible on one single tab? Why should the installation of graphics packs be on the same tab as modifying display settings like varied ground and liquid depth? Sure, to the trained DF player it does make a little bit of sense, but (again, IMHO) it does not do a very good job of making all these settings easy to find in the UI. Especially for newbies, these kinds of UI's can be a bit intimidating.

I'm not saying my attempt is perfect, but to me, it's a step in the right direction.