main window statusbar
QStatusBar gives almost no control over display and placement
of child widgets. It's not possible to subclass and reimplement
either, due to how QMainWindow works internally, and also due to
the special handling for the size grip and other platform specific
handling in QStatusBar.
Instead, we embed a single QgsStatusBar covering the whole real
status bar. All child widgets and temporary messages instead
are pushed to the QgsStatusBar instead - giving us as much control
as we desire over how these widgets are placed and their behavior.
As a result the locator widget has been moved to its logical placement
on the left of the status bar.
All plugins must ensure that they use the status bar interface
available via iface.statusBarIface() instead of directly interacting
with the status bar (e.g. iface.mainWindow().statusBar()...)
This adds a new "locator" bar to the QGIS status bar. If you're not
familiar with QtCreator's locator, it's a quick search bar
(activated by Ctrl+K) which displays matching search results
from any number of registered search filters.
Search filters are subclassed from QgsLocatorFilter, and
added to the app's locator via iface.registerLocatorFilter(...)
Searching is handled using threads, so that results always
become available as quickly as possible, regardless of whether
any slow search filters may be installed. They also appear
as soon as each result is encountered by each filter, which means
that e.g. a file search filter will show results one by one
as the file tree is scanned. This ensures that the UI is always
responsive even if a very slow search filter is present (e.g.
one which uses an online service).
This framework is designed to be extended by plugins, such as
OSM nominatim searches, direct database searching (i.e. Discovery
plugin), layer catalog searches, etc...
This is a completely wrong use of an algorithm that is meant to be used with *integer* values,
e.g. when dealing with pixels on screen, but not for coordinates that are floating point numbers.
The algorithm has a fixed tolerance of 1 unit.
QgsPoint(5,0.9).onSegment(QgsPoint(0,0), QgsPoint(10,0)) would return 2 (i.e. point is on line segment)
See the original code: https://github.com/erich666/GraphicsGems/blob/master/gems/PntOnLine.c
Historically the configuration used to be stored in layer's custom properties, but that does not scale
beyond simple rendering and so rule-based labeling introduced storage of configuration natively in XML elements.
That left us with two different ways of reading/writing labeling configurations. This work makes all configuration
to use native XML elements.
To keep compatibility of 2.x projects, reading of configuration from custom properties is preserved.
This commit also adds Python APIs for direct manipulation of labeling configuration through vector layer's
setLabeling() and labeling() calls.
Since the majority of users of this class will be exporting
an existing map layer to a data provider, the QgsVectorLayerImport
name is misleading and suggests that this class is designed
just to bring layers "into" QGIS.
Explicitly naming the class "Exporter" should help API users
discover this class.
Also cleanup API and improve docs
And use wherever custom widgets were being created. Reduces
duplicate code and allows specialised handling for raster
band display/selection to be centralized.
Make maps invalidate cache whenever layer order changes. Cache mode
is now identical to Render mode, so all mode switching has been
removed from composer maps. This should greatly simplify the learning
curve and usability of composer maps.
No longer required - the Cache mode is now performant enough
that we don't have to rely on the old rectangle preview
when desiring responsive composers
The geometry cache was only used for few geometry editing operations anyway. In earlier versions
of QGIS the geometry cache was also used by old snapping classes which have been replaced
by QgsPointLocator that also keeps a spatial index of geometries and it is not rebuilt on every re-render.
Reasons for removal:
- geometry cache was repopulated on every redraw of layers in editing mode, slowing down rendering
- data structure for the cache was a simple map with features accessed by their ID (no spatial index)
- the cache was only getting refreshed for the current view of the main map canvas (not a generic cache)
- not used for snapping anymore where caching was important to avoid roundtrips to data provider
- provider() was renamed to createProvider()
- selectWidget() was renamed to createSelectionWidget()
- providerLibrary() was renamed to createProviderLibrary()
This commit introduces basic support for non-library based
data providers, and moves the memory provider from a library
based provider to a core provider.
The memory provider is used so frequently throughout QGIS that
it has become integral to QGIS functionality and must be
available wherever the QGIS core library is used.
The changes here (while not exposed yet to Python) could potentially
be built on to allow creation of pure Python data providers.
Move all scalebar rendering code out of composer and ensure that
all scalebar rendering is done independant of QgsComposerScaleBar
This allows scalebar rendering code to be reused by plugins
and by non-composer code.
Also rename QgsScaleBarStyle -> QgsScaleBarRenderer, (and all
subclasses too). This name better reflects what these classes do.
Also cleanup API for addFeature(s) in QgsVectorLayer, by removing
the unused extra argument from addFeature() and be removing the
makeSelected argument from addFeatures() (code should be adapted
to manually select added features after adding if desired - this
was only used in a single place in the QGIS code and I suspect
this was unintentional in any case)
