Added a "User parameter:BaseApp/Preferences/PythonConsole/ProfilerInterval" int
property which sets how often (in milliseconds) the Python profiler runs while
Python code is running. Setting this value to zero will totally disable it.
Also added a preference in the Python console screen which allows the user to
set the value of this property to between 0 (disabled) and 5000 (once every 5
seconds). (+1 squashed commits)
Squashed commits:
[cca88ac633] Made the Python profiler only run when the console is running code
This has two purposes. First, it prevents a performance impact from running the
profiler whenever Python code is running. Second, it prevents crashes caused by
Qt's process events function being called too frequently. When the Python code
is running in the console, it monopolizes the main thread and prevents events
from being processed. Therefore, causing events to be processed in the callback
should not force events to be processed too frequently, because the normal loop
is being prevented by the Python code. (+1 squashed commits)
Squashed commits:
[45f86917e6] Made long-running Python code not freeze the GUI without multithreading
Removed the background thread running Python code and replaced it with a custom
profiler which the Python interpreter runs frequently (at every Python opcode I
believe) on the main thread whenever Python code is running. The profiler will
make Qt process any new events every 200 ms, preventing "App not responding"
messages and making sure any Ctrl+C keypresses will be processed. This prevents
the previous issue where running anything GUI-related from Python would crash
the program (because Qt isn't thread-safe). (+1 squashed commits)
Squashed commits:
[0ef7d810b3] Made the process of getting thread IDs cross-platform compatible
Instead of using <threads.h>, now the standard <thread> header from C++
11 is used to find the thread ID, since <threads.h> is apparently not
available on Windows. (+1 squashed commits)
Squashed commits:
[74c7b867f2] # This is a combination of 2 commits.
Python from the console now runs in the background
In a nutshell, all Python code which is input from the interactive console
now runs in a seperate QThread which runs in the background, instead of
on the UI thread. This means that long operates operations will no longer
cause the app to display an "App not responding" message, because the UI
thread is now free to keep running unencumbered.
However, it is still not possible to run multiple Python statements at
the same time. If the user tries to run some Python while a previous
statement is still being processed, instead it will display an error
message in the console stating that the previous command is still
being processed.
I also added a seperate QTimer which runs once every 100ms to flush any
output from the Python code back to the console. I can't flush the output
to the console from the background thread because the relevant Qt5 code
is not thread-safe (it causes random segfaults). So I added this timer
as a work-around, since it runs in the main UI thread.
Implemented Ctrl+C keyboard interrupts in the console
This is implemented by detecting a Ctrl+C key event in the Python
console in the main Qt UI thread, and sending a keyboard interrupt
to the background thread that runs the Python code.
patches for #10459 and #10426...
a few small details escaped attention need to be fixed
😉
Removing unnecessary strings from Crowdin and improving typos.
Currently the GroupCommand by default sets the action group as non-exclusive, checkable and having a drop-down menu which isn't always the desired behaviour in sub-classes.
Thus, some new methods are added to let a sub-class in its constructor decide how it should behave.
When setting the selection filter below and hovering over an object causes a segmentation fault:
filter = Gui.Selection.Filter('SELECT Part::Feature')
Gui.Selection.addSelectionGate(filter)
A SoNode* is not necessarily a SoFCSelectionRoot*, and when this
assumption breaks the code causes UB (the comment related to one of the
chunks explicitly says that it is safe, but unfortunately it is not).
Instead of storing `SoFCSelectionRoot*` and blindly cast a generic
`SoNode*` to that, we can do the opposite. In this way it is obviously
necessary to use a dynamic cast when trying to reach for
`SoFCSelectionRoot` specific features, but in this way the abstraction
should be sound.
Co-authored-by: Chris Hennes <chennes@pioneerlibrarysystem.org>
* if 2nd argument of getActiveObject() is False and the requested object doesn't exist then return (None, None, "")
* remove the exact same implementations from View3DInventorPy
* [Stylesheets] Fixed and added more accent colors.
Added accent colors to Behave dark ProDark and Dark contrast.
Used accent color 3 to the button gradients.
Added Gradient to the Modern styles, because you can disable the gradient by giving 2 accent colors the same color.
* changed to so accent color 3 is text.
