I also made a Python 2.7 version of the base app (which was easy) and had a go at making a Flatpak package of Luke's pyweek entry. This works (though I can only get to the menu screen), but it required some changes to how asset files are found, and I chose to use a different layout of files (in /app/share/solarflair). Here are the changes and additions I made:
https://github.com/lukevp/pyweek23/compare/master...takluyver:flatpakIf you want to try to build either of them yourself, you will first need to build the necessary base apps from my repo here:
https://github.com/takluyver/pygame-flatpak-testThe process for making these packages is still quite involved; I'd like to make some tooling to simplify it. But I think we need some conventions on structuring apps to make that possible - I don't think I can make an easily-understood tool that would handle the two very different layouts above. Allow me to start by describing how I'd ideally like apps to be structured:
1. Use entry points: an entry point is a reference to a function, like 'solarwolf.cli:main'. The launcher script imports that function and calls it ( from solarwolf.cli import main; main() ). Providing a main function like this allows tools to generate a script that does some setup before launching your code - e.g. adding directories to sys.path, or configuring handling for uncaught errors.
2. Include asset files inside the Python package: this means there's just one directory for the developer to specify which contains all the necessary files to run the game.
3. Don't rely on the working directory when loading data files: If you load assets from a path like 'assets/mysprite.png', it's easy for that to break when the game is installed. If you follow #2, you can easily construct an absolute path using the special '__file__' variable (see
http://pynsist.readthedocs.io/en/latest/faq.html#using-data-files ), but if you don't do it like this, please at least use a variable like DATA_DIR=, and make all asset paths from that, so it can easily be changed in one place.
My existing tool Pynsist (for building Windows installers) enforces #1, and encourages #2 and #3. What do you think of these ideas? How could we make it easy for game developers to follow them? Are there other sources of variation you'd like to standardise?
It's not urgent, but I'd also like to find better ways to work with icons for apps. You provide icons in a range of sizes (e.g. 16x16, 32x32, 48x48, 64x64...), but you typically remove some details in the smaller sizes, so it's not just a matter of creating one image and scaling it down. Icons also use different formats on different platforms (png, ico, icns), and I don't think it's terribly easy to convert between them. Are there any tools or techniques people use for dealing with icons?