and show detailed settings in a stacked panel widget
Because:
1. The settings belong next to the placement settings, because they
affect label placement directly (and are closely associated with the
label priority setting in this tab)
2. The label settings widget is ridiculously complex and overwhelming
even for experienced QGIS users. By moving detailed settings into
stacked panels we can avoid the initial complexity of the label settings
whilst also allowing us more flexibility to expose additional settings
in future without adding to the mess. So in future, I propose we move
all detailed settings to sub panels, and leave only the initial "enable"
setting at the top level (e.g. [x] "Repeat levels" -> click settings -> see
all repeat settings).
Because GEOS prepared predicates are "stubbed out" for many relation types,
such as overlaps and touches, we can get a HUGE speedup by reworking
the obstacle boundary check to utilise an intersects and within check instead
(with the same results)
* [FEATURE] Static particle traces for rendering mesh vector dataset
This PR permits to display directly in QGIS static particle traces for vector datasets in mesh layer without any plugin.
The user can choose in the mesh layer properties window :
- the color
- the size of the traces (line width)
- the count of particles
- the maximum length of the particle's tail
they collide with an obstacle feature of greater weight when compared
to the label's priority
Previously, obstacle weight was used ONLY to rank a features' label
candidates relative to each other, but was never used to actually prune candidates
completely. This meant that the labeling obstacle functionality was
confusing and frustrating for users to work with -- because despite
setting layers as the maximum possible blocking weight, you'd still
see labels being placed over these features (e.g. where the labeling
engine had no other choice).
Now, (when a project is set to v2 labeling engine mode), labels will
NEVER be placed over obstacles of greater weight. This means that
labels will potentially be omitted if the only choice is to place
them over a high weighting obstacle. But ultimately, that's much
more understandable for users -- they've manually set a particular
layer to a high obstacle factor, so we should respect that and
never place labels on these features.
In the end, this change makes the labeling placement much simpler
to understand for users, and should give power users a much
nicer experience all round.
Funded by the QGIS grants program
It is obvious that the constructor was a no-op.
Regarding the destructor, taking a mutex around an object doesn't
make sense because both the mutex and the object are member variables,
so if the pal object is used correctly, the destructor should only
be called after any other use of the object. And explicit clearing of
a unordered_map is unnecessary.
