Occasionally it fails to join lines even if the lines
visually share a point.
This is a rounding error in the comparison of the shared point;
a small distance will result in the points being considered
different and thus the lines not joining.
The solution is to test properly the two points using
`DraftVecUtils.equals` which considers the value of
the `precision` set in the Draft preferences.
Also fix an error in determining the objects of type group.
Also call `finish` to properly terminate the command,
otherwise it stays active and behaves incorrectly.
This is the base class of most Draft Gui Commands,
particularly those which were developed a long time ago.
It is inherited by `Creator` and `Modifier`
to set some specific options for some tools.
Newer Gui Commands do not use these classes and thus
are independent of `DraftTool`.
Nevertheless, in the future we expect to organize further
the commands so that they all derive from a few classes,
so that they all share some common properties and behaviors.
These small functions and utilities are placed in another
module, so they can be imported and called
by the individual Gui Command classes as necessary.
When these Gui Command classes are moved to their respective
modules, they will be able to import this auxiliary module as well.
`Draft_ToggleConstructionMode` and `Draft_ToggleContinueMode`.
They call a base class `BaseMode` which also uses the base
`gui_base.GuiCommandSimplest` class.
Also add a new icon for continue mode.
The commands `FinishLine`, `CloseLine`, and `UndoLine`
are moved from the huge `DraftTools.py` to `gui_lineops.py`
to reduce the complexity of the former file.
These GuiCommands aren't actually used presently
in the Draft Workbench. They were used in the past
particularly from the context menu when editing a Line object.
Those unit tests that are registered in `Init.py` will always run,
while those that are registerd in `InitGui.py` will only run
when the graphical interface is available.
This allows us to more clearly distinguish functions that
should be able to run always, from those that may run only
when the interfce is available.
Properly import the tracker classes. Avoid star imports,
and use the classes prefixed with the name of the module.
The BIM Workbench also has to be updated to use the new
module.
```
import draftguitools.gui_trackers as DraftTrackers
```
And do not load the `Snapper` in `DraftGui`.
The Snapper should be initialized by the module
that imports `DraftGui`, most probably `DraftTools`
or even by the `InitGui` of the workbench.
The test script can be run by the program's executable
or run as a macro.
```
freecad draft_test_objects.py
```
It can also be used as a Python module within the program
to create a test file on demand.
```
import drafttests.draft_test_objects as dt
dt.create_test_file()
```
The produced test file will be added in a different commit
once this commit is merged.
The idea is to have a test file created by a certain
stable version of the master branch. Then as the code
continues to change and grow, this file can be opened
with future versions of the program to test for compatibility
and regressions.
