=> FreeCAD crashes with this message on console. On next restart the language settings have changed. Switching back produces the same crash.
Can you run FreeCAD inside a debugger so that we get the call stack? Maybe it gives us a hint of the reason of the failure.
Besides I noticed that the complete menu is unavailable if I start from console. I have to switch to another application and back to get it. This does not happen if I start by clicking the icon.
hmm, there is definetly something wrong. I am not able to create a cube in Part. And any line drawn with draft will crash the programm. This doesn't happen when I launch FreeCAD from the conda-environment. And I also think I tested such basic stuff before uploading.
edit: and suddenly it works again? Now I am totally confused.
wmayer wrote: ↑Mon Apr 01, 2019 8:06 am
=> FreeCAD crashes with this message on console. On next restart the language settings have changed. Switching back produces the same crash.
Can you run FreeCAD inside a debugger so that we get the call stack? Maybe it gives us a hint of the reason of the failure.
not a debugger output, but this is what is reported after the crash.
According to this information the function MainWindow::changeEvent is called and the event type must be QEvent::LanguageChange. This invokes Command::languageChange() that internally calls Command::applyCommandData().
Now for one of the commands an exception is raised.
If you can build the macOS binaries yourself you can try this suggestion:
Put the code of Command::applyCommandData() inside a try-catch block which would look like this
wmayer wrote: ↑Mon Apr 01, 2019 10:38 am
According to this information the function MainWindow::changeEvent is called and the event type must be QEvent::LanguageChange. This invokes Command::languageChange() that internally calls Command::applyCommandData().
Now for one of the commands an exception is raised.
If you can build the macOS binaries yourself you can try this suggestion:
Put the code of Command::applyCommandData() inside a try-catch block which would look like this
Regarding py2 / py3 and which should be the default, my rather conservative view would be that where py2 is still the default on a distro, we should use the same for 0.18, as its objective is to be stable, not have people find and report problems. But we should switch in 0.19.
But it's not a strong opinion... Many apps don't follow this anymore.
yorik wrote: ↑Wed Apr 03, 2019 3:31 pm
Regarding py2 / py3 and which should be the default, my rather conservative view would be that where py2 is still the default on a distro, we should use the same for 0.18, as its objective is to be stable, not have people find and report problems. But we should switch in 0.19.
But it's not a strong opinion... Many apps don't follow this anymore.
I think this sentiment is to risk averse for nothing more than a switch of default. It's time to move on, after all this was suppose happen in 0.17.
We are talking about the release version of FreeCAD. Therefore believing forcing all users to use Py3/Qt5 version will somehow help FreeCAD moving forward. When some string related issue will emerge or Save picture tool won't be working on Linux, nothing will move forward. FreeCAD 0.18 will stay as is, issues included! As for the next development version, that will for sure be Py3/Qt5 oriented. Around a month or two back, majority of developers said, they moved to using Py3/Qt5 toolchain. Therefore next version of FreeCAD will likely have mature Py3/Qt5 support and on Py2/Qt4 side there will for sure be issues introduced.
From FreeCAD 0.18 point of view it therefore makes sense to provide both Py2/Qt4 and Py3/Qt5 builds, whenever feasible, as for the AppImage, best to discuss further in the dedicated thread: