Skip to content

Modernised icons and asset management#1530

Open
neofelis2X wants to merge 20 commits intokliment:masterfrom
neofelis2X:icons
Open

Modernised icons and asset management#1530
neofelis2X wants to merge 20 commits intokliment:masterfrom
neofelis2X:icons

Conversation

@neofelis2X
Copy link
Collaborator

@neofelis2X neofelis2X commented Dec 18, 2025

Summary

Hello,
I had this cooking for a long time now and decided to push it, to avoid overlapping work. This PR started with new icons, but then I also had to change how they are stored, packed and loaded.

pronterface_128x128 plater_128x128 pronsole_128x128

  • New application icons, multiresolution png, ico and icns
  • New toolbar icons for the excluder / macro widget
  • Dark and light icons to account for darkmode
  • HighDPI support for the bitmaps where possible
  • All shipped data files are now stored under printrun.assets...
  • Updated setup.py to pack the right icons / assets
  • Updated build scripts and github actions to pack all needed assets
  • Updated github actions for the latest supported macos runners
  • Fixed several warnings thrown by pyinstaller
  • Tested as much as possible

Note: I made some of these changes to the filestructure because I need to load shaders for OpenGL 3 later.

Screenshots

WINDOWS (click to expand) icons_win

win_icon_02

Screenshot 2025-01-08 183418

MACOS (click to expand) Screenshot 2025-12-17 at 00 11 41 Screenshot 2025-02-25 at 00 25 56 Screenshot 2025-02-25 at 00 26 27

Comments

This fixes #1529

I guess it is a bit much in one PR, but it all kinda belongs together. Let me know what you think. Feedback is welcome, as always!

@DivingDuck
Copy link
Collaborator

Hi,
a lot of work and a lot of additional files...

I downloaded all windows binaries. The Pronterface x86-py3.8 version do not work and call a exception error. I had the same problem when I compiled it locally in the past. Interestingly the compiled versions from GitHub had not this problem in the past. This is why I wrote the reminder in release_windows. bat and mark this combination as not supported but let it compile on GitHub. Guess we need to exclude it for now in the action file, what expected from my side. But I will have a separate look on it in my PR for Python 3.14 as is want to test all Python versions / combinations for Windows again.

I had seen you reversed the license classifier change in pyproject.toml. Interestingly adding only license = "GPL-3.0-or-later" under [Project] had worked for me for local builds with py3.14.
I will test that on my branch Python-support-3.14. Maybe this is as well a problem with x86-py3.8

@DivingDuck
Copy link
Collaborator

DivingDuck commented Dec 19, 2025

You can revert the revert. Change license to license = {file = "COPYING"}. This will solve the problem.

Edit:
We have the license file in our repository and can point to it.

Edit2:
I wonder if we still need the MANIFEST.in?

@neofelis2X
Copy link
Collaborator Author

and a lot of additional files...

I agree that is alot of new files. All the expected resolutions for the different platforms.
But it is not necessary to put all the files to create the icons into the repo. It is probably better that I take them out again and just upload the final icons.

Change license to license = {file = "COPYING"}.

Yes this used to be the correct way of writing it. But with current tools I get this deprecation warning:

Please use a simple string containing a SPDX expression for
`project.license`.  You can also use `project.license-files`. 
(Both options available on setuptools>=77.0.0).

By 2026-Feb-18, you need to update your project and remove
deprecated calls or your builds will no longer be supported.

See https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license for details.

So the end goal will be to support setuptools >= 77 for all build runs?

What should we do here for now? I guess it is better to make a separate PR that handles all the build updates.

I wonder if we still need the MANIFEST.in?

That could be... Setuptools is the most contradicting and unintuitive thing I have ever seen. I tried to cleanly update how the data files are packed, but it certainly can be improved. I also felt like this PR is changing too many things already.

@DivingDuck
Copy link
Collaborator

So the end goal will be to support setuptools >= 77 for all build runs?

Yes, but we can deal with it next year. For the time being we can use license = {file = "COPYING"}. One problem seems to be that old Python versions like py3.8 can't deal with newer setuptools versions. I think, I will remove the support of older Python versions to get rid of this problem as this will become more and more a problem.

Maybe we are able to push one more official release with the actual changes (this PR and the other from you and in addition my PR for supporting py3.14)

@rockstorm101
Copy link
Collaborator

Hi, I wasn't getting GitHub emails for some reason and I missed this. I hope to have this reviewed by mid February.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Reminder: macOS 13 Ventura based runner images no longer supported for GitHub

3 participants