Release Printrun 2.0.0

[rockstorm101]

Hi all, I've created this PR to discuss the next release.

@DivingDuck I believe you are able to (I hope) easily build and test the latest master branch. Could you please confirm the latest runs fine for you?

@syky27, concerns have been raised regarding the notarization process for macOS. What's your opinion on this? Would we need to tweak the package a bit so it passes this?

Thank you all before hand. Any other comments and suggestions please let us know.

[syky27]

Hi @rockstorm101 my opinion is that you guys you have your own way of signing your apps, you should enroll to Apple Developer program. I am not sure if Apple has a free of charge program for open-source...

I was thinking about this, few things can happen, when I sign the package.

• I no longer have personal Apple Developer Program, I only have enrolled to programs that tie to my companies, this could have some very catastrophic consequences once Apple would find some legal problems with printrun itself, I am not saying that there are some, but I am not sure that I am preparared to take the chances.
• Secondly I have nothing to do with printrun, and I am sure that the end user can view the certificate that has been used to sign printrun app, I don't think that is ideal, not saying that I personaly don't want to be tied to printrun, but I don't see why my companies should.
• Lastly, I am almost certain that this would go against somewhat Apple policy...

Let me know what you think about actually getting Printrun dedicated dev program, I am willing to help with the process of signing the app, once that would potentially be done.

[kliment]

Hey Tomas,

I fully understand you not wanting to publish it under your IDs, and we're extremely grateful that you were willing to do so before.

As far as I know Apple has no discount or special provisions for open source projects - it's the same 100/year regardless. The only difference is that unlike companies or individual developers open source projects cannot publish anything under the project name unless the project is a legal entity (company). So it's going to have to be someone's personal or company account. I could enroll for a year and do it under my name. I don't know what happens if that subscription ever expires. I still don't have a recent enough mac to be able to sign packages myself, but I can definitely sign up for a developer ID and generate a key for this purpose.

Would you be able to try a few things for us:

1. Can you do a build and check whether it runs on your machine?
2. Can you codesign the build using --runtime and see if it causes any rule violations (we will not distribute that build, so it doesn't matter if you use your company ID)?
3. Can you attempt notarization of the signed build and let us know whether it passes or fails, and if it fails, with what error? (again, we will not distribute that build, and you can remove it as soon as we know whether notarization works)

If we can get a build notarized with no or few problems, I'll sign up for an ID and generate a key for you to use when signing. If it turns out to be difficult or impossible to get a build notarized without major effort, we'll probably have to reconsider whether we can support mac os at all.

If this is too much trouble for you, I totally understand and we'll have to look for another way to do it. Again, thank you for your help to this project so far!

[DivingDuck]

Hi @rockstorm101,
yes building an exe-file for Windows 10 (via VS2019 and latest Python 3.7.8 and actual module versions) works for me. I'm using the updates from here in my fork as well and did some prints with it this week

But I have a problem with translations. I recognized this last week after I tried to test some de translations after I copied the translation files to the program directory (I usually use the English version). There seems to be a general problem with Python 3.7x and gettext.install/locale for OS Windows10. Printrun don't find the local translation files. The issue below maybe describe the problem best: wxWidgets/Phoenix#1616.
I haven't a solution for this. I wonder that there is no other user with this problem.

[rockstorm101]

yes building an exe-file for Windows 10 (via VS2019 and latest Python 3.7.8 and actual module versions) works for me. I'm using the updates from here in my fork as well and did some prints with it this week

Thank you very much. This is the feedback I was hoping for.

But I have a problem with translations. I recognized this last week after I tried to test some de translations after I copied the translation files to the program directory (I usually use the English version). There seems to be a general problem with Python 3.7x and gettext.install/locale for OS Windows10. Printrun don't find the local translation files. The issue below maybe describe the problem best: wxWidgets/Phoenix#1616.
I haven't a solution for this. I wonder that there is no other user with this problem.

Thank you for spotting this. I never tried translations myself, to be honest. I can't get them to work right now on my machine so they might be broken further than just Windows. I'll keep testing, it might be just me. I had a read through the link you shared. The problem described is way out of Printrun's scope. We might need to adapt our code once they introduce the fix though.

[volconst]

Hi, I have some pending commits. I spent a lot of time to 3d view resize problem in Linux/GTK. The solution however turned to be mostly using wxPython (>= 4.1).
There are other commits also, but I do not think they should appear directly in 2.0.0 release.
Do you think the code is in a state for official major release?
I would rather call it release candidate.
Are there some evident issues that need a fix?
I think that user experience suffers from the slow release rate and even thought that releases (exe) are bad at the current status quo and scripted build/installation is better way for distribution.

[DivingDuck]

I do agree with most of @volconst comments. I understand as well @rockstorm101 efforts for pushing a new release.

Good point. There should be an update for requirements.txt, especially for wxPython. I use in general the latest versions for all modules for my own fork. I had overseen the version issue with wxPython in my answer. Sorry for that.

Creating an Windows10 executable file isn't a problem if you use the development version 4.0.dev0 of pyinstaller. It' isn't a good solution using a development version, but it's the only version I found so fare for Windows 10 that's working. (for reference, pls. see issue #1043)

Some additional thoughts:
Regarding running scripted versions and Windows: This will not work. You are asking only for more problems, frustrations, for installing even more program and code garbage on different places they do not understand. This results in not use Printrun and using other solutions instead. Sorry for making this statement. Windows users running executable program files and no scrips - that is why it's called Windows. Most Windows user do not know about using an interpreter. Handling of virtual environments is fare away from an usual Windows user experience depth. There should be an actual development build available if you want that Windows user use or test Printrun. My guess is, this is also valid for Mac users. As soon as there is a new merge in the actual software someone need to make a new developer build version for all supported operating systems.
I guess, one major problem of Printrun is that there is no one who is able to support all os-builds (only a opinion from my side and w/o any complaining).

Are there some evident issues that need a fix? Here are some (not only evident issues) that came in my mind :)

• Translations are not working since some time (haven't any idea since when) and catalog files are outdated/incomplete/with wrong references since years. in addition: Change and store a language on the fly so that a user is able to use a language independent from a system language.
• There was also some useful feature requests if I remember correct.
• Add a direct fan control similar as for Print flow and Print speed.
• Strange behavior of Temperature graph window: It immediately disappear somewhere in background as soon as the mouse pointer loose focus for this window and move over the build plate window
• Gauges: With pointing the mouse to the heater gauge and turning the mouse wheel change temperature for the active heater / tool. Moving the mouse focus to the bed temperature gauge and turning the wheel don't change the bed temperature but instead the heater temperature.
• Material management: For me this isn't a really useful part of the program. Manual update for the rest of material onto a spool - input is in mm or via clicking on +- push buttons with a fixed length. A user don't want to rewind/measure a 5Kg spool first to get this information (or calculating this with an external program, or by hand). Usually this should be done with input of the spool weight and then recalculated from the program it self. Most information would be available for doing this but, once a material was added the user can't find the information anywhere again. Only a length information is available. Adding a additional field for weight of an empty spool is as well a really handy information to make a correct calculation. Displaying and modifying of the complete information for a spool is necessary.
• An additional help entry under Help with all supported keyboard shortcuts. It is not a good procedure that a possible user need first to consolidate a Github repository to find those elementary information.

@rockstorm101, it looks like I got translation back to work (only hard coded now for a quick test I did yesterday). When I find a little bit spare time I will check if there is a better way to do it.

Well, so fare my thoughts for a much to long post.

[volconst]

Thank you @DivingDuck
The issues you report seem reasonable. I am not sure if they are tracked somewhere, but it will be nice to track them. It would also be nice to have them prioritized by some sort of survey/voting.

[DivingDuck]

Hi @rockstorm101,
It turn out that the general translation issue was easier to solve, than I initially thought. In the end it's a six liner changing the method for acquiring the translations. I have tested it for Windows 10.
I don't expect problems with this change as it have the same behavior as initially implemented, but just in case... Can someone test, if this work as well for Linux/MacOs? 3b0ea82
I will then make a clean version for integration if it is OK for you and works as initially implemented for Linux and MacOS.

@volconst , thanks and yes, this would be nice. Actual I don't know if anybody have such a list. I had seen an old ToDo list in the repository. In the end this is something the owner of this project need to take care of.
Anyway, I have just add such a list in the wiki of my fork. I would be happy If some of these points here will find its way to my fork and vice versa.

[kliment]

@DivingDuck if you're willing to maintain a list like that I'm very happy for the help - I've just invited you as a collaborator to this repository

In terms of what you said about releases - it's 100% true that this is a major weakness for me - I ended up doing a mac build ages ago because people kept asking for one, and it was reasonably easy to do so, but doing mac builds now is an absolute nightmare. Back in the day a user donated a mac and I used it for building releases until it was too old to do so (not supported by a sufficiently recent OS to do codesigning). I can still do windows builds but it takes some effort (I need to provision a VM to do it). It would be amazing if we can get a CI setup going that can build binaries on each commit, but I have no idea how to do this, especially on mac os. If it's just a matter of paying apple their blood money every year I'm happy to do that but I don't know how to get there from here. Apparently it's possible to run automated processes via github actions, including on macos and windows environments, so maybe there's something we can do there. Personally I don't know what it would take to set that up, and I'd welcome any help along those lines.

[DivingDuck]

@kliment , thanks a lot for your invitation and confidence. This was much more as I had expected.

I came to my fork like a virgin to a child. :) I simply needed something to handle my own printer's. I usually don't do such stuff. Some weeks ago I was thinking about, that I need something more automated for my own workflow as I was asked in the past for providing a windows executable based on your master branch from some users. Lets see what I can do for you with my limited knowledge.

For the time being I can provide you with actual compilations for Windows 10 based on your master branch as soon your master branch have an update (with a little delay, of cause), if it is helpful for you: 8cace94

For every thing else I need to find some time (as it happen to be always). For the moment I like to fix this translation part first. In addition I can help to maintain such a list. Maybe as a Wiki page here? That would be easy to modify and to follow up from all who want to help. Let me know.

Again, thanks for inviting me.

[rockstorm101]

Do you think the code is in a state for official major release?
I would rather call it release candidate.

I used to agree with you and I would have pushed in the past for a release candidate. But precisely because of the very "slow release rate" I'd rather go for a proper release now even if it means releasing a minor update in a month or two. Of course the more stable it is the better but it's been already more than 2 years since the last "release candidate". Such workflow simply does not work for this project. Just to reiterate, I am not completely against going the release-candidate way, I'd just rather go for "full" releases on this project.

Most Windows user do not know about using an interpreter.

I couldn't agree more with @DivingDuck here. The easier you make it the wider adoption it gets. And this, in my mind, applies to all platforms. Therefore I would always aim to provide one-click-install packages on all platforms as long as it is feasible.

Just a note regarding the issues listed, even though I agree with them I would not consider the feature requests as issues that need fixing but only nice-to-have features.

I don't expect problems with this change as it have the same behavior as initially implemented, but just in case... Can someone test, if this work as well for Linux/MacOs? 3b0ea82

I just tested on my machine (Linux) and the translation seems to now work. Again, thanks a lot for spotting this.

It would be amazing if we can get a CI setup going that can build binaries on each commit, but I have no idea how to do this, especially on mac os.

And yes, this is definitely the way to go. And to achieve some level of automated testing too.

[DivingDuck]

It would be amazing if we can get a CI setup going that can build binaries on each commit

@kliment, I had a little bit time during my travel and played a bit with this idea. Here is my first draft: c475db3. It is already functional and can be used for building an executable, but still needs a little bit work from my side. Anyway here is, what it does:

The batch will compile automated via commandline an executable Pronterface file for Windows 10.

Steps that are automated for now:

1. Clean up previous compilations (directory dist)
2. Check for virtual environment called v3 and generate it, if not available (start from scratch)
3. Install all needed additional module's via pip
4. Check for outdated module's that need to be updated and wait for keystroke
5. Check if virtual environment need an update and update the environment
6. check for existing variants of gcoder_line.cp??-win_amd??.pyd and delete them (to prevent errors and incompatibilities)
7. Compile Pronterface.exe
8. Copy localization files to .\dist
9. Go to directory \dist, list files and ends the activity

Steps, a user need to do manually before running this batch:

1. install python 3.7.8
2. install C-compiler environment
3. check for latest repository updates

Discussion and review is welcome.

[kliment]

@DivingDuck Wow, this is great. When you feel it is in a good state I'll attempt to make a github action to build it on the github servers. They already have visual studio and python installed, so we should be able to build directly.

[volconst]

Is this gcoder_line needed? How much RAM is used for a large gcode file?

[kliment]

It's definitely needed. It massively improves both speed and memory usage. See here

[volconst]

wow, did not expect such a detailed answer, thanks
I remember I subclassed this class for the pronsole to not accumulate the lines - the reason was slower loading before print

[DivingDuck]

@kliment , @rockstorm101
I finished the script and made a clean version. 4c6336b

I changed the behavior of point 4. to:
4. Check for outdated module's that need to be updated and wait for keystroke and update them automatically.
I have check the script today once more and updating outdated modules works fine too.

The only thing that is missing is to generate the master pot catalogs. I put it on my list but this need to be done some when later as there are a lot of cleaning task's necessary after creation (and a bit of learning curve for myself too). But this isn't a show stopper at all for releasing something.

Someone need to teach me a little bit with GitHub. I am somehow not able to to make selective pull requests from my branch to this branch for the language issue: b7032ce and the actual one: 4c6336b.

[volconst]

@DivingDuck ,
For selective pull request you need to isolate the selected commits in separate branch, push it and create a pull request for the branch, e.g.
git fetch kliment_remote_aka_upstream
git checkout -b build-script kliment_remote_aka_upstream/master
git cherry-pick 15e27 c475 4c633
git push your_remote_aka_origin
There is also another approach with git rebase, which allows editing and arranging of commits, but could be destructive if not used properly.

[DivingDuck]

@volconst,
Thank you for helping me once more. I will do so tomorrow and report wether I had success or not. I just finished the german translation. This day was too long...

[kliment]

I had the pleasure of speaking to one of our macos users yesterday and they suggested making a homebrew formula for macos - that builds and runs things from source, and can use git repos and specific commits/tags as targets. I quite like the idea. I found another wxpython application that uses homebrew that we can use as a template. Anyone done something like this before?

[hroncok]

I've done a C library and a Qt C++ app, but never a Python project with other Python dependencies.

[hroncok]

I think that #921 would make things easier. I can look at it again if desired.

[kliment]

That would be awesome. Would help a lot on other OSs too.

[syky27]

Hi, sorry I was away from my computer.

I should have time to take a look at this next week. If you still need help :)

[volconst]

Hi, it's maybe good time to reconsider 2.0 release. At least, now after a bunch of commits, I am not against it - if they work fine :)

[kliment]

Okay, so we now have an rc7 release that seems to work correctly with pip as well. It seems to work well on Linux, and at least starts on osx (I only have macos in a vm without graphics acceleration so things are very buggy and I can't test it comprehensively), I haven't tried anything on Windows. I'd like to ask people with macos or windows machines to try it out and let me know if everything works. If there are no obvious showstopping bugs I am of the opinion we can finally release 2.0.0.

To test, use pip install printrun and then run pronsole.py or pronterface.py. This should work both inside and outside virtualenvs, as long as you use python3/pip3.

@DivingDuck can you please try it out on Windows?
@syky27 can you please try it out on macOS?

[syky27]

Hi @kliment sorry for being away.

I successfully installed it and ran the pronsole, I am unable to run printerface due some macos limitations, can you point me out to the right track?

╭─syky at aluminum in ~/Fekal using
╰─○ pip install printrun
Collecting printrun
  Downloading Printrun-2.0.0rc7-cp37-cp37m-macosx_10_14_x86_64.whl (395 kB)
     |████████████████████████████████| 395 kB 5.4 MB/s
Requirement already satisfied: appdirs>=1.4.0 in /Users/syky/.pyenv/versions/3.7.7/lib/python3.7/site-packages (from printrun) (1.4.4)
Collecting pyobjc-framework-Cocoa; sys_platform == "darwin"
  Downloading pyobjc_framework_Cocoa-6.2.2-cp37-cp37m-macosx_10_9_x86_64.whl (276 kB)
     |████████████████████████████████| 276 kB 7.6 MB/s
Collecting cffi
  Downloading cffi-1.14.2-cp37-cp37m-macosx_10_9_x86_64.whl (176 kB)
     |████████████████████████████████| 176 kB 8.1 MB/s
Collecting pyglet>=1.1
  Downloading pyglet-1.5.7-py3-none-any.whl (1.1 MB)
     |████████████████████████████████| 1.1 MB 8.6 MB/s
Collecting pyserial>=3.0
  Downloading pyserial-3.4-py2.py3-none-any.whl (193 kB)
     |████████████████████████████████| 193 kB 9.5 MB/s
Collecting cairosvg>=1.0.9
  Downloading CairoSVG-2.4.2-py3-none-any.whl (50 kB)
     |████████████████████████████████| 50 kB 11.2 MB/s
Collecting psutil>=2.1
  Downloading psutil-5.7.2.tar.gz (460 kB)
     |████████████████████████████████| 460 kB 10.1 MB/s
Collecting lxml>=2.9.1
  Downloading lxml-4.5.2-cp37-cp37m-macosx_10_9_x86_64.whl (4.4 MB)
     |████████████████████████████████| 4.4 MB 10.6 MB/s
Collecting cairocffi
  Downloading cairocffi-1.1.0.tar.gz (68 kB)
     |████████████████████████████████| 68 kB 6.8 MB/s
Collecting numpy>=1.8.2
  Downloading numpy-1.19.1-cp37-cp37m-macosx_10_9_x86_64.whl (15.3 MB)
     |████████████████████████████████| 15.3 MB 11.2 MB/s
Collecting wxPython>=4.1
  Downloading wxPython-4.1.0-cp37-cp37m-macosx_10_9_x86_64.whl (18.1 MB)
     |████████████████████████████████| 18.1 MB 4.5 MB/s
Collecting pyobjc-core>=6.2.2
  Downloading pyobjc_core-6.2.2-cp37-cp37m-macosx_10_9_x86_64.whl (292 kB)
     |████████████████████████████████| 292 kB 8.2 MB/s
Collecting pycparser
  Using cached pycparser-2.20-py2.py3-none-any.whl (112 kB)
Collecting pillow
  Downloading Pillow-7.2.0-cp37-cp37m-macosx_10_10_x86_64.whl (2.2 MB)
     |████████████████████████████████| 2.2 MB 8.2 MB/s
Collecting tinycss2
  Downloading tinycss2-1.0.2-py3-none-any.whl (61 kB)
     |████████████████████████████████| 61 kB 467 kB/s
Collecting defusedxml
  Downloading defusedxml-0.6.0-py2.py3-none-any.whl (23 kB)
Collecting cssselect2
  Downloading cssselect2-0.3.0-py3-none-any.whl (31 kB)
Requirement already satisfied: setuptools>=39.2.0 in /Users/syky/.pyenv/versions/3.7.7/lib/python3.7/site-packages (from cairocffi->printrun) (41.2.0)
Requirement already satisfied: six in /Users/syky/.pyenv/versions/3.7.7/lib/python3.7/site-packages (from wxPython>=4.1->printrun) (1.15.0)
Collecting webencodings>=0.4
  Downloading webencodings-0.5.1-py2.py3-none-any.whl (11 kB)
Using legacy setup.py install for psutil, since package 'wheel' is not installed.
Using legacy setup.py install for cairocffi, since package 'wheel' is not installed.
Installing collected packages: pyobjc-core, pyobjc-framework-Cocoa, pycparser, cffi, pyglet, pyserial, pillow, webencodings, tinycss2, defusedxml, cairocffi, cssselect2, cairosvg, psutil, lxml, numpy, wxPython, printrun
    Running setup.py install for cairocffi ... done
    Running setup.py install for psutil ... done
Successfully installed cairocffi-1.1.0 cairosvg-2.4.2 cffi-1.14.2 cssselect2-0.3.0 defusedxml-0.6.0 lxml-4.5.2 numpy-1.19.1 pillow-7.2.0 printrun-2.0.0rc7 psutil-5.7.2 pycparser-2.20 pyglet-1.5.7 pyobjc-core-6.2.2 pyobjc-framework-Cocoa-6.2.2 pyserial-3.4 tinycss2-1.0.2 webencodings-0.5.1 wxPython-4.1.0
WARNING: You are using pip version 20.1.1; however, version 20.2.3 is available.
You should consider upgrading via the '/Users/syky/.pyenv/versions/3.7.7/bin/python3.7 -m pip install --upgrade pip' command.
╭─syky at aluminum in ~/Fekal using
╰─○ ll
total 0
drwxr-xr-x  11 syky  staff   352B Jun  4 12:33 BI-BEZ
drwxr-xr-x  39 syky  staff   1.2K Jul 12 22:14 openapi-generator
╭─syky at aluminum in ~/Fekal using
╰─○ pronsole.py
Welcome to the printer console! Type "help" for a list of available commands.
offline> help

Documented commands (type help <topic>):
========================================
bedtemp             exit     home     move   resume            set      upload
block_until_online  extrude  load     off    reverse           settemp
connect             gcodes   ls       pause  run_gcode_script  shell
disconnect          gettemp  macro    print  run_script        slice
eta                 help     monitor  reset  sdprint           tool

Undocumented commands:
======================
extrude_final

offline>
offline>
Not connected to printer.
Disconnecting from printer...
Exiting program. Goodbye!
╭─syky at aluminum in ~/Fekal using
╰─○ pronterface.py
This program needs access to the screen. Please run with a
Framework build of python, and only when you are logged in
on the main display of your Mac.

[rockstorm101]

I'm not able to reproduce what's described in #1156 on Debian Sid either. Though I don't have any fancy screens around available to test whether it's a matter of big resolutions. Now that we are on it, I still suffer from #615. It'd be interesting to know whether macOS and Windows can reproduce it too.

[DivingDuck]

@rockstorm101, yes for windows, if it is this:
2021-02-01 19-28-14.zip

[kliment]

Okay, so #615 appears to be the only blocker at the moment. Unless someone has an approach to fixing it, I would be inclined to ignore it for now and go ahead for release, as #1156 is now fixed.

[kliment]

@hroncok did you generate the summary listing for the release changelog manually or do you have some script to do it?

[hroncok]

Manually, carefully reviewing the individual commits. It is tedious :/

[kliment]

@hroncok no problem, I can deal with tedious :) Thank you for doing it before!

[rockstorm101]

@rockstorm101, yes for windows, if it is this:
2021-02-01 19-28-14.zip

Yes, that's exactly it.

Okay, so #615 appears to be the only blocker at the moment. Unless someone has an approach to fixing it, I would be inclined to ignore it for now and go ahead for release.

Happy with that.

[kliment]

Here we go! https://github.com/kliment/Printrun/releases/tag/printrun-2.0.0rc8
Please test!
If nothing terrifying is reported by users, this will become 2.0.0

[hroncok]

Ok. Let me package that to Fedora.

[kliment]

@hroncok can you find out why it didn't publish packages to pypi?

[kliment]

Does anyone have an objection to me making this a full release (in github terms)? I think this might be the reason the github actions for release failed to run

[kliment]

I set it to a full release, but it still failed to run the release actions. Anyone have any idea why?

[DivingDuck]

Hi @kliment, I just took a look at create release.
is it maybe '... On every push to a tag matching the pattern v*, create a release:' ?

[kliment]

@DivingDuck thanks for looking into it, but it seems that's the opposite of what we're missing. The thing you linked lets you create a release from an action. What we're missing is triggering an action from a manually created release.

[hroncok]

Damn, we don't have wxpython 4.1 in Fedora. How dare we call ourselves the leading edge?

[DivingDuck]

@hroncok, live is hard. For Windows it's there and works :)

[rockstorm101]

Damn, we don't have wxpython 4.1 in Fedora.

Same issue here at Debian. We'll have to wait to package this release I'm afraid.

[hroncok]

I'll most likely just revert 6d8dcd2#diff-4d7c51b1efe9043e44439a949dfd92e5827321b34082903477fd04876edb7552 we don't have the mentioned problems in Fedora AFAIK.

[kliment]

@hroncok let us know if it works well with 4.0

[hroncok]

This solves problem with splitter resize garbage and ignoring of Refresh() in other cases in GTK backend.

I wonder how to check exactly this, but I'll try to resize extensively :D

[hroncok]

It seems to work fine.

[volconst]

This solves problem with splitter resize garbage and ignoring of Refresh() in other cases in GTK backend.

I wonder how to check exactly this, but I'll try to resize extensively :D

The incremental rendering during file loading could also be affected by the downgrade.

[kliment]

So it's been a week, other than #1160 and #615 I'm not aware of any major outstanding issues, and #1160 is not a regression. I'd like a go/no-go poll for release of 2.0.0. @hroncok @DivingDuck @rockstorm101 @volconst @a2k-hanlon you all have the right to veto release if you think there's a blocking issue or if you want to delay for further testing. If none of you object, I would recommend we finally release this. If you have no objection, just +1 this message. If you do have an objection, please state it.

[DivingDuck]

I think it is going well so fare with RC8.
#1160 was already there before and isn't a point that cause an issue for printing. Maybe worth an remark for the new release as known issue and a restart as workaround.
#615 seems to be manageable with different wx4.0x versions as workaround.

For Windows I found only a problem with Projector for which I not make a issue report so far. This problem also seems to be existent since longer. I manage it to run from source by adding an external GTK3 library that provide the needed DLL's for cairosvg. An other workaround is adding library pycairo. Both solution work for running from source with my comuter. I wasn't able to get it running for the compiled version so fare. At least this is an workaround. I think I will update the release.bat with the second variant adding pycairo.

@kliment, you ask me about differences between release_windows.bat and and the github action script. I have two additional libraries: simplejson (pronterface.py line 29) and polygon3 (I add it in the past because it was missed by pyinstaller some when). simplejson is maybe worth to add in the workflow.

Over all I would happy to see release 2.0.0.
+1

[kliment]

@DivingDuck yes please add the libraries to the github action if you can, and check whether the build that it produces works correctly

[rockstorm101]

Hi everyone, what's the status of this? I guess it is closely related to the status of #1171. Debian is still at wxPython < 4.1, but if we go ahead with #1171 I see no (major) issues to release 2.0.0.

[rockstorm101]

Closing as superseded by #1308.