These classes are used for storing measurements for a layout
(QgsLayoutMeasurement), sizes for a layout (QgsLayoutSize)
and points in a layout (QgsLayoutPoint)
They support storing a measurement unit alongside a measurement
length/size. A new class QgsLayoutMeasurementConverter handles
conversion between different units, including converting to and
from pixels via a specified DPI property.
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 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 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.
Splits the rendering component of annotations out from map
canvas item component.
A new core abstract base class QgsAnnotation handles the
management of the common properties associated with an
annotation, and handles rendering the annotation onto a
QgsRenderContext destination.
Existing annotation classes have been ported to this, and
with the exception of the form annotation moved into core.
Form annotations are dependant on editor widgets and must
remain in GUI.
A new QgsMapCanvasAnnotationItem item class implements
a QgsMapCanvasItem which draws an annotation inside the
canvas, and handles synchronising the position and size
of the canvas item with the QgsAnnotation position/size.
This allows annotations to be safely used in a multi-canvas
environment, with a single QgsAnnotation being displayed
in multiple canvases (even if the canvases have different
extent/crs/etc).
Additionally it allows annotations to be directly rendered
to a map (eg in composer) without going through the
gui based Qt graphics scene framework.
Also removes lots of duplicate code, and adds some basic
unit tests for annotations.
Nothing particularly exciting here yet, but this commit
moves the definition of the provider base class to a c++
QgsProcessingProvider abstract base class.
As part of this some existing python methods were renamed
to make their use clearer and to fit with the QGIS c++
api conventions:
- getName was renamed to id
- getDescription was renamed to name
- getIcon was renamed to icon
These API breaks are documented
* Added sponsors generated from changelog site
* Use a single rule for including sponsor images rather. Remove terrelogiche duplication. Remove old sponsor images
* Fix indentations and remove sponsors from images.qrc
This adds a new cmake option GENERATE_QHP. If the api docs are
set to being built (ie doxygen is available and WITH_APIDOC is true)
then setting GENERATE_QHP to true will cause doxygen to create
a compiled Qt help file from the QGIS docs.
This QHP file can then be used by QtCreator to show the QGIS
api directly within the QtCreator help (ie, press F1 on a class
or member to see the docs).
To do this, you need to:
- make sure doxygen is installed, WITH_APIDOC is true and
GENERATE_QHP is true
- build to generate the docs
- In QtCreator, go to Tools -> Options -> Help, switch to the
"Documentation" tab and click "Add". Point it to your generate
QHP file (should be in the build folder doc\api\qch folder)
- Restart QtCreator, wait a bit, and then you should have the
api docs available under the "Help" tab and by pressing F1
on a QGIS class/method
This is done using the new QT_TAG_FILE and QT_DOC_URL cmake options.
QT_TAG_FILE should be set to the path of the qt.tags tagfile. In ubuntu
this file is provided by the qt4-doc-html package, and is located at
/usr/share/qt4/doc/html/qt.tags
QT_DOC_URL should be currently set to http://doc.qt.io/qt-4.8/
replace AUTHORS, CONTRIBUTORS, DONORS, SPONSORS and TRANSLATOR with t2t version
in doc, run txt2tags within the build and install documentation. Optionally
build and install api documentation
git-svn-id: http://svn.osgeo.org/qgis/trunk@15348 c8812cc2-4d05-0410-92ff-de0c093fc19c
