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.
Steps to verify the issue:
1. Open FreeCAD.
2. Switch to Std_ViewTop.
3. Click one of the curved arrows of the Navigation Cube.
4. Switch to the Draft WB.
5. Make sure Draft_SelectPlane is set to "Auto".
6. Start Draft_Arc and click 2 points (for the radius and the start angle).
7. Result: The displayed arc does not match the start angle or the current point.
Additonally:
* Removed the normal argument from `__init__`. The tracker does not work properly with just a normal. AFAICT there is no code that specifies this normal.
* Minor improvement to `getAngle`: Switched the vectors.
Presumably due to an copy/paste error, carbonCopy used to verify the
referenced object via `isExternalAllowed` (just like addExternal).
Now using `isCarbonCopyAllowed`, the resulting error message is the
expected one for wrong objects, not a generic one after the operation
failed.
The part behind the column represents the function name itself, not an
error message. So previously, an argument error looked like this:
("Give an object" is not the method name)
```
>>> obj.carbonCopy()
Traceback (most recent call last):
File "<input>", line 1, in <module>
TypeError: Give an object() takes at least 1 argument (0 given)
>>> obj.carbonCopy(123)
Traceback (most recent call last):
File "<input>", line 1, in <module>
TypeError: Give an object() argument 1 must be str, not int
```
While the format string also supports a text for the complete error message
(using a semicolon instead), I decided against this: Pythons standard text
is more precise than this:
(the type error here is not "Give an object")
```
>>> obj.carbonCopy()
Traceback (most recent call last):
File "<input>", line 1, in <module>
TypeError: Give an object
>>> obj.carbonCopy(123)
Traceback (most recent call last):
File "<input>", line 1, in <module>
TypeError: Give an object
```
