In some cases canceling render jobs can take a long time. Eg when
using database layers over a sloooooow connection, canceling a job
can be blocked by minutes while waiting for the first batch of feature
fetching to finish. (Since eg postgres features are fetched in batches
of 2000 with no opportunity to abort mid-way through this).
This meant that while the first render allows the GUI to remain
responsive, any subsequent render operations which occured before
the first render completes locks up the whole ui until the first
render can finish cancellation.
With this change, the render cancelation happens with blocking.
It means that you can pan and zoom around a map over of slow
connection without any ui locks.
In a post-OTF-disabled world these are no longer required. The
map units are dictated by the map units for the destination
CRS.
It's dangerous to separate these two properties as setting
the incorrect map units for a given CRS will result in
incorrect scale calculations.
Because
- OTF reprojection is mature and stable
- Should be no cost when not required - transforms are shortcut
when not required
- Reduces code complexity
- Canvas OTF support was being incorrectly used as a flag for
whether measurements should be made in ellipsoidal mode. Instead
the project's ellipsoid setting should be checked for this.
- Should simplify behavior for new users
* [feature] QgsSettings QGIS QSettings replacement
This is the new QgsSettings class that adds an (optional)
Global Settings additional ini file where a system administrator
can store default values for the settings and provide
pre-configuration.
If an ini file named qgis_global_settings.ini is found
in the pkgDataPath directory it is automatically loaded,
this path can be overriden by a command line argument
( --globalsettingsfile path ) and through an environment
variable (QGIS_GLOBAL_SETTINGS_FILE).
This change is being driven by:
- need for consistent terminology in the api. Currently there's
a confusing mix of border/outline used
- need for consistent terminology in the gui - we have a mix
of "border"/"outline"/"pen"
- bringing QGIS into line with the standard terminology used
in other graphic editing programs
features assigned to same color
This is the most cartographically pleasing color arrangement in my
opinion as it creates a nicely distributed set of colors.
When a new color is required, repeat the color assignment process.
This is the fastest part of the algorithm, so there's no noticable
speed drop. Repeating the whole coloring ensures that newly added
colors are properly balanced with respect to other colors, and avoids
the situation where one of the last features to be colored requires
a whole new class to be created, which will only have a few possible
members.
Overall this results in more balanced color assignment.
This mode attempts to assign colors in such a way that the total
area of features assigned to each color class is balanced. It helps
avoid larger features causing a single color class to appear more
dominant on a colored map.
This ports to old (pre 2.0!!) topocolor plugin to processing. It's based
off my beta 2.x fork (never publicly released) which implemented
a bunch of improvements to the algorithm allowing for minimal number
of required colors and also balanced counts of features assigned
each individual color.
** Pretty sure this plugin was highlighted in Victor's presentation
about plugins-which-shouldn't-be-plugins-and-should-be-processing-algs
instead. It's a prime example of a plugin where the amount of code
required for gui+setup exceeded the actual "guts" of the plugin by
a huge factor, and which is much more useful when it can be
integrated into a larger processing model.
This adds a new interactive "curve" to the assistant widgets.
It allows you to fine tune exactly how input values get
mapped to output sizes/colors/etc.
Think GIMP or Photoshop curves, but for your data...
Handles scaling of input values to output values by using
a curve created from smoothly joining a number of set
control points.
This assists in creation of curve type transforms, typically
seen in raster image editing software (eg the curves dialog
in GIMP or Photoshop). Transforms are created by passing a
number of set control points through which the transform curve
must pass. The curve is guaranteed to exactly pass through
these control points. Between control points the curve is
smoothly interpolated so that no disjoint sections or
"corners" are present.
And add a new CLANG_TIDY_EXE cmake option. If this is set to the
path to the clang_tidy executable then a bunch of clang-tidy
checks will be run during compilation.
