Print

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

[Pidgeot]

- Support for DFhack under Linux/OSX (i.e. see my commits below)

I'm currently working on a DFHack tab; I'll throw this in while I'm at it.

- Linux and OS/X are case sensitive with respect to folder and file names (to my knowledge). Windows is insensitive with this respect. Maybe follow along the lines as suggested here https://stackoverflow.com/questions/8462449/python-case-insensitive-file-name to fix this.

I don't see this as an issue in practice. When running on a case-sensitive file system, you would (as a user) *expect* that case-sensitivity to remain intact. Furthermore, the case used in the program matches the current Starter Pack/old LNP exactly, so it is only an issue to people who create a new pack without using an exisiting pack as a template.

Regarding version check of plugins, I hacked a small script that uses headers to overcome the hurdle imposed by dffd.

That sounds very nice. If you think you can integrate it yourself, feel free to submit a patch (or pull request); leave the download part out, though (that would probably be relevant once auto-updating gets added, but for now it's just *checking*).

As a further development suggestion, one could centralize the version check somewhere and just download a specific file with all the version numbers (I suggest going with updated) instead of DDOSing the dffd server... find it here: https://gist.github.com/MagiX13/651e323c92ab86196a04

The version check is currently only for the pack as a whole, because there's no automated download anyway. (D)DOSing risk is minimal, and there's no requirement to use DFFD at all in the code, so I'm not too worried about that.

I'll be willing to help with development, even though my coding style sucks and I'm rather new to "application" programming, as you can see from here: https://github.com/MagiX13/pyLNP/commits/master

I would be willing to help with the development of this project, but I'm far away from being a reasonable programmer of any kinds...

Looks good enough to me, so don't worry too much about it. Besides, if your code is too bad to salvage, I can always just not accept it.

[MagiX]

I'm currently working on a DFHack tab; I'll throw this in while I'm at it.

Saw the commit, ty

Furthermore, the case used in the program matches the current Starter Pack/old LNP exactly, so it is only an issue to people who create a new pack without using an exisiting pack as a template.

Actually, the starter packs I checked (i.e. http://dffd.wimbli.com/file.php?id=7622 and http://dffd.wimbli.com/file.php?id=8936) both use lowercase for their LNP subfolders (like graphics and utilities), the program uses uppercase, that's why I came up with that issue to begin with.

That sounds very nice. If you think you can integrate it yourself, feel free to submit a patch (or pull request); leave the download part out, though (that would probably be relevant once auto-updating gets added, but for now it's just *checking*).

The version check is currently only for the pack as a whole, because there's no automated download anyway. (D)DOSing risk is minimal, and there's no requirement to use DFFD at all in the code, so I'm not too worried about that.

Will do that once I'm done, time to create a bitbucket account or are there plans to move to github?
Right now I'm working with a JSON file that is read and saved with all the details, i.e. packages(i.e. graphics, utilities etc.) installed, where to find them online (dffd id) and installed version. I plan to extend this to allow for checks of manually installed packages and a way to incorporate them into the version check/upgrade routine.
Currently I only plan to work with dffd as this is probably the most used way and also the easiest way to check for new versions. Not sure if it is worth it to go on with a universal version checker and I have no idea how to approach this...
I guess I will implement it including the download and extract part (for win/linux at least) and make it complete and testable.

Looks good enough to me, so don't worry too much about it. Besides, if your code is too bad to salvage, I can always just not accept it.

Seems fair


Btw the goal is to have it running under Win/Linux/OSX and with python 2 and 3, right?
Currently it doesn't work on my machine with python2 due to some errors with the imagetk library. I will try to write my code python2 compatible anyways, but can't test it under Win or OSX.
Any suggestions where to get started with the UI development/modification? Never did stuff like that before

[Pidgeot]

Furthermore, the case used in the program matches the current Starter Pack/old LNP exactly, so it is only an issue to people who create a new pack without using an exisiting pack as a template.

Actually, the starter packs I checked (i.e. http://dffd.wimbli.com/file.php?id=7622 and http://dffd.wimbli.com/file.php?id=8936) both use lowercase for their LNP subfolders (like graphics and utilities), the program uses uppercase, that's why I came up with that issue to begin with.

I just checked both of them, and you're right. (The Starter Pack USED to have the first letter in upper case...)

I'll think about what seems like the best choice. I don't really like forcing case-insensitivity on case-sensitive file systems, so maybe I'll just end up allowing all-lowercase as well - we'll see.

That sounds very nice. If you think you can integrate it yourself, feel free to submit a patch (or pull request); leave the download part out, though (that would probably be relevant once auto-updating gets added, but for now it's just *checking*).

The version check is currently only for the pack as a whole, because there's no automated download anyway. (D)DOSing risk is minimal, and there's no requirement to use DFFD at all in the code, so I'm not too worried about that.

Will do that once I'm done, time to create a bitbucket account or are there plans to move to github?

I prefer Bitbucket to Github, so no plans to move.

Right now I'm working with a JSON file that is read and saved with all the details, i.e. packages(i.e. graphics, utilities etc.) installed, where to find them online (dffd id) and installed version. I plan to extend this to allow for checks of manually installed packages and a way to incorporate them into the version check/upgrade routine.
Currently I only plan to work with dffd as this is probably the most used way and also the easiest way to check for new versions. Not sure if it is worth it to go on with a universal version checker and I have no idea how to approach this...

The only thing you need to make it universal is a complete download URL instead of just a DFFD ID. DFFD is certainly used a lot, so it would be great to support it, but it's not perfect, so pack distributors should be able to use other sources.

Btw the goal is to have it running under Win/Linux/OSX and with python 2 and 3, right?
Currently it doesn't work on my machine with python2 due to some errors with the imagetk library. I will try to write my code python2 compatible anyways, but can't test it under Win or OSX.

That is the goal, yes - many systems still have Python 2 as the default, so I do most of my testing, etc. on that, but try to keep the code Python 3-compatible as well.

It is possible that there are some bugs I didn't catch when running on Python 3, so if you find anything, please submit a bug report.

Regarding your ImageTk issues, throw me a PM or something if you want me to take a look.

Any suggestions where to get started with the UI development/modification? Never did stuff like that before

This is my first Python GUI program, so I'm pretty much learning as I go, too

The best advice I can give is to just read code and try to see how that leads to whatever layout it puts on screen. When you're trying to add something yourself, make a sketch or mental picture of the UI you want, then add the necessary controls in code and fiddle with the layout until it gets to what you want.

[PeridexisErrant]

Furthermore, the case used in the program matches the current Starter Pack/old LNP exactly, so it is only an issue to people who create a new pack without using an exisiting pack as a template.

Actually, the starter packs I checked (i.e. http://dffd.wimbli.com/file.php?id=7622 and http://dffd.wimbli.com/file.php?id=8936) both use lowercase for their LNP subfolders (like graphics and utilities), the program uses uppercase, that's why I came up with that issue to begin with.

<snip>
Any suggestions where to get started with the UI development/modification? Never did stuff like that before

That's a change I made to work with the Java LNP when that was in development, which I really should change back eventually... but since it isn't case-sensitive on windows the issue hasn't really come up. I'll change back for consistency. 

My lecturer recommended googling "[O`Reilly] - Programming Python, 4th ed. - [Lutz]" - chapter five covers GUI development with tkinter.  I've only glanced at it so far, and never done a GUI, but it looks good. 

[MagiX]

I'll think about what seems like the best choice. I don't really like forcing case-insensitivity on case-sensitive file systems, so maybe I'll just end up allowing all-lowercase as well - we'll see.

That's why I (locally) fixed it by checking for Uppercase and allowing for lowercase (see commit on my github )

The only thing you need to make it universal is a complete download URL instead of just a DFFD ID. DFFD is certainly used a lot, so it would be great to support it, but it's not perfect, so pack distributors should be able to use other sources.

Alright, will do that: complete download URL and version check possibility if DFFD, manual otherwise (for now)

Regarding your ImageTk issues, throw me a PM or something if you want me to take a look.

I'll try to figure it out, but I guess it's more a local issue or depending on the python image library (PIL) or so. Someone has a Linux machine in a VM or so? Haven't seen the need to set one up yet

That's a change I made to work with the Java LNP when that was in development, which I really should change back eventually... but since it isn't case-sensitive on windows the issue hasn't really come up. I'll change back for consistency. 

My lecturer recommended googling "[O`Reilly] - Programming Python, 4th ed. - [Lutz]" - chapter five covers GUI development with tkinter.  I've only glanced at it so far, and never done a GUI, but it looks good. 

So we found the fun person
Thank you, I will check out that section. Will focus on the core functionality first. (e: It's actually Part III/Ch 7+)

[Pidgeot]

I'll try to figure it out, but I guess it's more a local issue or depending on the python image library (PIL) or so.

It's supposed to degrade gracefully if PIL/Pillow isn't available (it's only imported for the ability to display PNGs).

Someone has a Linux machine in a VM or so? Haven't seen the need to set one up yet

I'm doing the Windows build natively, but the other 3 builds are all done in VMs. I use Linux Mint with MATE for the 64-bit build and Linux Mint Debian Edition with MATE for the 32-bit build; that's what I based the instructions in the README on.

[lethosor]

The "Close GUI when launching DF" option is broken on OS X and Linux when using DFHack - after calling sys.exit() (line 129 of lnp.py), DFHack appears to lose access to the console and displays "Do 'help' or '?' for the list of available commands" repeatedly. A possible solution could be to make run_program() optionally use exec or one of its variants (i.e. when autoClose is enabled).

[Pidgeot]

The "Close GUI when launching DF" option is broken on OS X and Linux when using DFHack - after calling sys.exit() (line 129 of lnp.py), DFHack appears to lose access to the console and displays "Do 'help' or '?' for the list of available commands" repeatedly. A possible solution could be to make run_program() optionally use exec or one of its variants (i.e. when autoClose is enabled).

I'll look into it before releasing a build with this option included.

EDIT: exec* is not an option because utilities need to be launched after DF - so it's necessary to find a way to launch DF as an entirely stand-alone process, with its own terminal window. For Windows, I can use the start command; on OS X, I can use open. I haven't been able to figure out a useful possibility on Linux; I don't see a way to make Python do it directly, and I haven't been able to detect which terminal program the user is using to launch a new one. If anyone knows something I don't, I'm all ears.

[shaver]

The "Close GUI when launching DF" option is broken on OS X and Linux when using DFHack - after calling sys.exit() (line 129 of lnp.py), DFHack appears to lose access to the console and displays "Do 'help' or '?' for the list of available commands" repeatedly. A possible solution could be to make run_program() optionally use exec or one of its variants (i.e. when autoClose is enabled).

I'll look into it before releasing a build with this option included.

EDIT: exec* is not an option because utilities need to be launched after DF - so it's necessary to find a way to launch DF as an entirely stand-alone process, with its own terminal window. For Windows, I can use the start command; on OS X, I can use open. I haven't been able to figure out a useful possibility on Linux; I don't see a way to make Python do it directly, and I haven't been able to detect which terminal program the user is using to launch a new one. If anyone knows something I don't, I'm all ears.

I think you want to use x-terminal-emulator if it's present, else xdg-terminal, else just let them eat xterm or set a pref.

[Dricus]

In my Java launcher I start 'xterm -e path_to_df_executable' when dfhack is enabled. That way you will see a terminal window. It's not the most pretty one (it's good old xterm), but it is included in most Linux distributions, so it's reliable.

[Pidgeot]

I think you want to use x-terminal-emulator if it's present, else xdg-terminal, else just let them eat xterm or set a pref.

I have five different VMs installed, and I tested the availability of the three commands you mentioned:
Mint 15/MATE, x64: x-terminal-emulator works, none of the others do.
Mint 16/XFCE, x64:  x-terminal-emulator works, none of the others do.
Mint Debian Edition/MATE, x32: None of the options work.
Fedora 20/MATE, x32: None of the options work.
Arch/MATE, x32: None of the options work.

Something more portable is necessary to make this work satisfactorily on Linux. If nothing is available, then I can always ignore that option on Linux... but that's obviously not ideal.

In my Java launcher I start 'xterm -e path_to_df_executable' when dfhack is enabled. That way you will see a terminal window. It's not the most pretty one (it's good old xterm), but it is included in most Linux distributions, so it's reliable.

Out of the 5 distros I tested, not one of them had xterm available by default. It may make sense to TRY xterm, but it isn't portable enough to stand alone.

[Dricus]

Out of the 5 distros I tested, not one of them had xterm available by default. It may make sense to TRY xterm, but it isn't portable enough to stand alone.

Hmm, then apparently memory serves me wrong . From what I remember, I decided to use xterm by default, cause I found out it came preïnstalled with most distro's. Either I was wrong, or maybe times have a-changed since then .

[Pidgeot]

After a lot of searching, it appears there are precisely 2 options to spawn a terminal with reasonable reliability:

• Bundle the xdg-terminal script and just run that on Linux, or
• Reimplement the xdg-terminal script in Python to avoid having another file in there

I can't even just yank out the auto-close feature, because pre-built executables don't necessarily HAVE a terminal window, and dfhack doesn't spawn one itself, causing an immediate crash (and even if I only supported running from source, it'll still break if you close the launcher while dfhack is running, or if you used your file manager to launch the script without a terminal). The only way to avoid the issue is to not allow launching of DFHack on Linux, and that's no good either.

...at least the license for the script ALLOWS these options, and the script just requires /bin/sh, which at least CAN be relied on. This is going to have to wait until tomorrow, though.

[MagiX]

It's supposed to degrade gracefully if PIL/Pillow isn't available (it's only imported for the ability to display PNGs).

I guess my PIL is broken somehow. I reinstalled 170 python2 related packages today but still have problems. I guess there is some conflict between two packages. I will fall back to a VM for python2 testing.

After a lot of searching, it appears there are precisely 2 options to spawn a terminal with reasonable reliability:

What about a fallback to user specified function in pyLNP.json or user.json?

I'm have done quite a bit on version checking and updating the packages like utilities and graphics but have some questions/issues:

• What archive format support is required? I have zip and tar.(bz2|gz) as these are build into python
• Is there an easy way to check for a new DF version, other than checking the http://bay12games.com/dwarves/index.html file?
• Suggestions how to handle the different flavors(?) of graphics packages? i.e. Phoebus comes with a TT and a noTT version (in the data/init folder). As TT is handled by the launcher itself, we can safely use anyone of these versions and ignore the other one, right? As I'm fairly new to DF: are there graphics packages that have different flavors beyond the TT and noTT? or can I just move the data/init/*tt files to data/init ?
• Mac (noob) question: if DwarfTherapist.dmg is updated, it is enough to copy the dmg file to the respective DT folder under utilities? I guess I have to extract the files, right?
• If a graphics package is updated, is there a need to remove and reinstall the package itself?

I guess that's it for now

[salithus]

Is there an easy way to check for a new DF version, other than checking the http://bay12games.com/dwarves/index.html file?

I'd recommend using this: http://bay12games.com/dwarves/dev_release.rss