d2d570f875
The wrapper allows to call resetTrackers in the main module after the callback to the GuiTools is executed. This is the last commit, many thanks to @matthijskooijman for having menthored me :) I think it's helpful to have @matthijskooijman explanation on this use of the wrapper: This defines a new wrapper function, that calls the original callback and then calls resetTrackers. Note that this creates a new function for every loop iteration, so each of these wrapper functions captures potentially different callback, self and obj values so things work as expected. Note I did something weird with the callback value there: Since functions like these capture a variable, not its value at the time of function definition, and loop variables like label and callback are a single variable shared between all loop iterations, capturing callback directly ends up with all wrappers calling the last callback (i.e. they all capture the same variable and by the time the wrappers are called, that variable will contain the last of the callbacks). This is commonly solved by using a default value in the function definition, since such a default value uses the value of the (in this case) callback variable, not capturing the variable.
General
2020 May
These files define the "GuiCommands", that is, classes called in a graphical way through either buttons, menu entries, or context actions. They don't define the graphical interfaces themselves, but set up the interactions that allow running Python functions when graphical data is provided, for example, when points or objects are selected in the 3D view.
There is no need to check for the existence of the graphical interface (GUI)
when loading these classes as these classes only work with the GUI
so we must assume the interface is already available.
These command classes are normally loaded by InitGui.py
during the initialization of the workbench.
These tools were previously defined in the DraftTools.py module,
which was very large. Now DraftTools.py is an auxiliary module
which just loads the individual tool classes; therefore, importing
DraftTools.py in InitGui.py is sufficient to make all commands
of the Draft Workbench accessible to the system.
Then the toolbars can be defined with the command names.
The classes defined here internally use the public functions provided
by Draft.py, which are ultimately defined in the modules
under draftutils/, draftfunctions/, and draftmake/.
Those GUI commands that launch a "task panel" set up the respective widgets in two different ways typically.
- "Old" commands set up the task panel from the
DraftGui.pymodule. - "New" commands call the respective class from a module in
drafttaskpanels/, which itself loads a.uifile (created with Qt Designer) fromResources/ui/.
For more information see the thread: [Discussion] Splitting Draft tools into their own modules
To do
In the future each tool should have its own individual task panel file,
and its own .ui file.
This should be done by breaking DraftGui.py, creating many .ui files,
and making sure these GUI commands use them properly.