initAlgorithm() method
This allows 2 benefits:
- algorithms can be subclassed and have subclasses add additional
parameters/outputs to the algorithm. With the previous approach
of declaring parameters/outputs in the constructor, it's not
possible to call virtual methods to add additional parameters/
outputs (since you can't call virtual methods from a constructor).
- initAlgorithm takes a variant map argument, allowing the algorithm
to dynamically adjust its declared parameters and outputs according
to this configuration map. This potentially allows model algorithms which
can be configured to have variable numbers of parameters and
outputs at run time. E.g. a "router" algorithm which directs
features to one of any number of output sinks depending on some
user configured criteria.
destroyed by the python garbage collector
The code generated with the /Factory/ annotation was not sufficient
to correctly transfer the ownership of objects created in Python
back to c++ (despite mailing list messages which hint that it
is).
Anyway, this awful abomination works. Let's all move on to more
useful ways to spend our time...
instead of adding an extra CMakeLists in .ci/travis/code_layout to build API doc, astyle and run tests (indentation, spelling, sip, doc coverage), the top CMakeLists has been adapted to allow not building core libraries and possibly just the static code layout
* astyle has been moved from /src/astyle to /lib/astyle (I would propose to move all external libraries, and possibly add git submodules)
This implements the proposal from @SrNeto:
- new toolbar with the new dialog button and
all the "new" data soource buttons
- old layer toolbar hidden by default
- new dialog open from first item in layer menu
