Now that our minimum VS studio version allowed supports std::round,
we should use that in place of Qt's qRound method.
Because:
- it doesn't truncate to int, resulting in unpredictable
behaviour (refs #16925)
- better to stick to standard c++ methods wherever possible,
since they're likely better supported and optimised by the
compilers
- it's a tiny reduction to the barrier for entry to QGIS
development (I'm sick of pointing out the need to use
qRound during PR reviews!)
And use it when we need to clone parameters (instead of more fragile
conversion to and from variants)
This fixes model loading which use algorithms which create python
subclasses of parameter definitions
because using this more consistently throughout the codebase makes it
easier to maintain code.
We also do not want to call the copy constructor on them, using pointers
just makes this more obvious. Further, casting is also something
that's commonly done on pointers and not references.
And if you want a value or a reference, just use QgsGeometry, it's meant
to be handled like this.
1. endless loop when a sqlite-based layer is opened, and
wal+shm files are created. This triggers a loop because
the directoryChanged signal is emitted again and again ...
This was the real blocker.
2. when a new files appears in a directory
the directoryChanged is emitted and OGR/GDAL may fail
to open the file because the file copy was not yet
finished.
This commit fixes 1 but the fix for 2 is only a best effort using
a 100 ms timer: I could not find a definitive solution to this issue,
a file could be legitimately opened in streaming mode and it will
always triggers an error, there is apparently no way to get
the QFileSystemWatcher emit a signal when new files are closed
flusehd and not when they are just created.
Previously grids would always take precedence when both a grid
and guide were within tolerance of a point.
Now, guides will always take precedence - since they have been
manually set by users we make the assumption that they have
been explicitly placed at highly desirable snapping locations,
and should be selected over the general grid.
Additionally, grid snapping was previously only done if BOTH
x and y could be snapped to the grid. We now snap to the nearest
grid line for x/y separately. This means if a point is close
to a vertical grid line but not a horizontal one it will still
snap to that nearby vertical grid line.
to all other pages
This allows resetting all other pages to use the guide configuration
for the current page. Since guides are now single page only (required
to handle mixed page size/orientation layouts), this is a shortcut
to allow guide configuration to be setup on a single page and then
easily transferred to all other pages in the layout.
