Archive

Tag Archives: plugin development

As I’m sure you have already heard, QGIS 2.0 will come with a new Python API including many improvements and a generally more pythonic way of doing things. But of course that comes with a price: Old plugins (pre 2.0) won’t work anymore unless they are updated to the new version. Therefore all plugin developers are encouraged to take the time and update their plugins. An overview of changes and howto for updates is available on the QGIS wiki.

TimeManager for QGIS 2.0 will be available from day 1 of the new release. I’ve tested the usual work flows but don’t hesitate to let me know if you find any problems. The whole update process took two to three hours … sooo many signals to update … but all in all, it was far less painful than expected, thanks to everyone who contributed to the wiki update instructions!

About these ads
  1. Since the release of QGIS 1.8, Plugin Installer no longer includes the “add 3rd party repositories” button. This was an intentional design choice!
  2. The new official plugin repository at plugins.qgis.org keeps everything in one place making it easier for users to find documentation and report issues. It will also provide many long-wanted features such as a rating system for plugins. You can already sort by number of downloads to discover the most popular plugins.
  3. Last but not least: New users will not be able to discover your plugin if it is not in the repository.

Go ahead to plugins.qgis.org and upload your plugin now!

Starting from scratch can be painful. Luckily there’s a tool out there that can help: PyQGIS Plugin Builder. The form will build a minimal plugin for you. You’ll get a ready QGIS 1.0 plugin that implements an empty dialog with Ok and Close buttons. You can find a step-by-step description on how to create and modify this dummy plugin at linfiniti.com – “A simple QGIS python tutorial”.

From there, I suggest moving to the PyQGIS Cookbook – a great resource for everything related to QGIS with Python – especially the part about “Developing Python Plugins”. Tim also created a PDF version of the Cookbook (original post) if you prefer it in hard copy.

The following code snippet contains the constructor of a GUI control class for QGIS plugins. It’s job is to initialize the plugin GUI (a dock widget in this case) and create signal connections:

import os
from PyQt4.QtCore import *
from PyQt4.QtGui import *
from PyQt4 import uic
from qgis.core import *

class MyGuiControl(QObject):
    """This class controls all plugin-related GUI elements."""

    def __init__ (self,iface):
        """initialize the GUI control"""
        QObject.__init__(self)
        self.iface = iface

        # load the form
        path = os.path.dirname( os.path.abspath( __file__ ) )
        self.dock = uic.loadUi( os.path.join( path, "mywidget.ui" ) )
        self.iface.addDockWidget( Qt.RightDockWidgetArea, self.dock )

        # connect to gui signals
        QObject.connect(self.dock...
        ...

Using uic.loadUi is a convenient way to create a user interface with minimum effort. Of course the performance might be better if we compile the .ui code to python first, but during development phase this saves us an extra step.

For some plugins it’s necessary to save the settings inside the QGIS project file. Saving is done with this simple one-liner:

QgsProject.instance().writeEntry(pluginName, setting, value)

Then you just need to save the project.

Reading is performed with one of the following functions:

QgsProject.instance().readEntry (pluginName, setting) # for strings
QgsProject.instance().readNumEntry (pluginName, setting)
QgsProject.instance().readDoubleEntry (pluginName, setting)
QgsProject.instance().readBoolEntry (pluginName, setting)
QgsProject.instance().readListEntry (pluginName, setting)

You’ll find the corresponding API documentation at: http://doc.qgis.org/stable/classQgsProject.html. As you can see, you can only read/write simple data types. To allow the plugin developer to save more complex plugin settings, I filed an enhancement request.

To handle all those different read functions in a convenient way, I created the following functions:

def readSetting(self,func,setting):
    """read a plugin setting from QgsProject instance"""
    value,ok = func('pluginName',setting)
    if ok:
        return value
    else:
        return None
            
def readSettings(self,setting,value):
    """read plugin settings from QgsProject instance"""
    # map data types to function names
    prj = QgsProject.instance()
    functions = { 'str' : prj.readEntry,
                  'int' : prj.readNumEntry,
                  'float' : prj.readDoubleEntry,
                  'bool' : prj.readBoolEntry,
                  'pyqtWrapperType' : prj.readListEntry # QStringList
                }
        
    dataType = type(value).__name__
    return = self.readSetting(functions[dataType],setting)

readSettings() has to be supplied with the name of the setting and an example or default value for the setting (from which we can determine the data type of the setting). Of course this can be done in many different ways. In Time Manager plugin, readSettings() receives a dictionary of all settings that have to be read. The function then loops through the dictionary and reads the available settings.

Follow

Get every new post delivered to your Inbox.

Join 2,602 other followers

%d bloggers like this: