Bay 12 Games Forum

But I think we can skip this, the preferred way for updating a pack'd be to pull from a git? repo - if that is even possible. (Is it??)

Github provides a nice "Download ZIP" link to essentially grab the complete repository, but it doesn't include contents of submodules. You'd need special parsing of that to download them individually (but then you might as well just manage them individually...), or a full-blown git client - both are certainly possible, but maybe going a bit too far...

Also, I'm not sure if Github *wants* to have X thousand people doing this on a regular basis... it's not a webhost, so using it as one might be problematic in the long run. That's part of the reason why I  think it's important to not overspecialize this - it's okay to do something special for a particular host, but there needs to be a generic solution in case that host is no longer available.

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.

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

Quote from: Pidgeot on August 18, 2014, 06:05:23 am

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.

Quote from: Pidgeot on August 18, 2014, 06:05:23 am

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

Quote from: Pidgeot on August 18, 2014, 06:05:23 am

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.

Work in progress...


The preview isn't being drawn correctly, but once I figure that part out, color scheme selection is good to go, and I'll upload a new set of builds.

Each colorscheme is a text file that overwrites colors.txt in the DF folder. The program looks in the folder LNP/Colors for these.

Here's a link to the color schemes I have prepared; just extract to the LNP folder and you'll be ready for the next build: https://www.dropbox.com/s/9175wfuzy1vs05c/Colors.zip

Edit: New builds have been posted.

Quote from: Pidgeot on August 15, 2014, 12:50:03 pm

Quote from: PeridexisErrant on July 22, 2014, 11:52:45 pm

- Update notification tool

I'm currently working on this by putting configuration entries in a file specifying a URL containing the version, the pack version, and a regular expression to pull out the latest version number - but DFFD does not allow Python to access the site, so it would be necessary to keep the information elsewhere.

The good part is I've made it general enough that it can really be hosted *anywhere* - GitHub file, forum post, whatever. It just has to be a single, continuous string, with some easily locatable text next to it. As long as Python can access the URL, it can be detected.

Does that include this page too?  http://dffd.wimbli.com/file_version.php?id=7622

That was the exact URL I used to test, so yes.

DFFD can still be used for tbe download (the download page just gets opened in the user's webbrowser, so Python doesn't get involved), but the version number itself currently needs to be somewhere else.

- Update notification tool

I'm currently working on this by putting configuration entries in a file specifying a URL containing the version, the pack version, and a regular expression to pull out the latest version number - but DFFD does not allow Python to access the site, so it would be necessary to keep the information elsewhere.

The good part is I've made it general enough that it can really be hosted *anywhere* - GitHub file, forum post, whatever. It just has to be a single, continuous string, with some easily locatable text next to it. As long as Python can access the URL, it can be detected.