Ever wanted to export your QGIS symbols as images? Yes. Well here is some Python code that will let you do just that:

from PyQt4.QtCore import QSize
from PyQt4.QtGui import QImage, QPainter

style = QgsStyleV2.defaultStyle()
names = style.symbolNames()
size = QSize(64, 64)

for name in names:
    symbol = style.symbol(name)
    if not symbol.type() == QgsSymbolV2.Marker:
        continue

    image = QImage(size, QImage.Format_ARGB32_Premultiplied)
    image.fill(0) 
    painter = QPainter(image)
    symbol.drawPreviewIcon(painter, size)
    painter.end()
    image.save(r"C:\temp\{}.png".format(name), "PNG")

Or in 2.6 it's even easier:

from PyQt4.QtCore import QSize
from PyQt4.QtGui import QImage, QPainter

style = QgsStyleV2.defaultStyle()
names = style.symbolNames()
size = QSize(64, 64)

for name in names:
    symbol = style.symbol(name)
    if not symbol.type() == QgsSymbolV2.Marker:
        continue

    image = symbol.asImage(size)
    image.save(r"C:\temp\{}.png".format(name), "PNG")

Bam!

Why? Because we can.

Ever wanted to export your QGIS symbols as images? Yes. Well here is some Python code that will let you do just that:

from PyQt4.QtCore import QSize
from PyQt4.QtGui import QImage, QPainter

style = QgsStyleV2.defaultStyle()
names = style.symbolNames()
size = QSize(64, 64)

for name in names:
    symbol = style.symbol(name)
    if not symbol.type() == QgsSymbolV2.Marker:
        continue

    image = QImage(size, QImage.Format_ARGB32_Premultiplied)
    image.fill(0) 
    painter = QPainter(image)
    symbol.drawPreviewIcon(painter, size)
    painter.end()
    image.save(r"C:\temp\{}.png".format(name), "PNG")

Or in 2.6 it's even easier:

from PyQt4.QtCore import QSize
from PyQt4.QtGui import QImage, QPainter

style = QgsStyleV2.defaultStyle()
names = style.symbolNames()
size = QSize(64, 64)

for name in names:
    symbol = style.symbol(name)
    if not symbol.type() == QgsSymbolV2.Marker:
        continue

    image = symbol.asImage(size)
    image.save(r"C:\temp\{}.png".format(name), "PNG")

Bam!

Why? Because we can.

QGIS is now in feature freeze for the 2.4 release, that means no more features are going in and we need to focus on fixing any outstanding issues that are still hanging around before the release. 2.4 is going to be a good release, adding cool things like: multithreaded rendering; legend code refactor; colour blind previews; and a whole heaps of other cool stuff. We need your help finding and squashing bugs. This is where you come in.

Finding bugs

Grab the RC builds of QGIS from the downloads page. If you are on Windows I would recommand grabbing the OSGeo4W installer and installing the package called qgis-dev using the Advacned option. A new build will show up nighly and you can test the lastest version.

If you find a bug you need to log it at hub.qgis.org, if you don't we can't fix it. Don't post a tweet about it and hope that we pick it up because we may not, this happened recently and the person didn't file tickets when I asked them too and now it's forgotten.

We track everything at hub.qgis.org. We close tickets as we fix them so keep an eye out for ones that you open. Remember to always add as much information as possible, and answer questions if asked. We are aware that everyone is busy, as are we, however if you don't responed it can be hard to track down issues at times. It can take a bit of time to get used to what is a good or a bad ticket but it doesn't take long. Next time you see a bug file it at hub.qgis.org.

Squashing bugs

This is where the help really matters and is the best thing you can do for the project. If you're a developer and keen to try your hand at some bugfixing you can find the most important ones here.

Not a developer?

The next best thing you can do is fund some bug fixing. There are many ways to do this and this is the most effective way to get stuff done.

Your main options are:

• Donation to the QGIS fund - we use some of this money to pay for bug fixing.
• Hire a developer directly. This is a good way to go as it is focused development. You can find some of the devs here
• Rob a bank and send the money to us - No!11! Don't do that.
• Encourage your company - who maybe is now saving a lot of money - to sponser or hire a developer.
• Run a user group and charge a small fee to donate to the project - minus costs of course.

It's not just code.

There is more to QGIS then code and some application at the other end. With each release comes other non developer work.

These things include:

• Updating the manual
• Updating translations
• Helping with PR stuff like posters
• Ticket clean up

If you're not in a position to help in the other areas of the project these things need love to so don't forget you can help here.

We love that QGIS is free, that it opens GIS to a whole range of people who would never have been able to use it. It's a great feeling. It's also a great feeling when others get invovled and help us along to make it better for everyone.

QGIS is now in feature freeze for the 2.4 release, that means no more features are going in and we need to focus on fixing any outstanding issues that are still hanging around before the release. 2.4 is going to be a good release, adding cool things like: multithreaded rendering; legend code refactor; colour blind previews; and a whole heaps of other cool stuff. We need your help finding and squashing bugs. This is where you come in.

Finding bugs

Grab the RC builds of QGIS from the downloads page. If you are on Windows I would recommand grabbing the OSGeo4W installer and installing the package called qgis-dev using the Advacned option. A new build will show up nighly and you can test the lastest version.

If you find a bug you need to log it at hub.qgis.org, if you don't we can't fix it. Don't post a tweet about it and hope that we pick it up because we may not, this happened recently and the person didn't file tickets when I asked them too and now it's forgotten.

We track everything at hub.qgis.org. We close tickets as we fix them so keep an eye out for ones that you open. Remember to always add as much information as possible, and answer questions if asked. We are aware that everyone is busy, as are we, however if you don't responed it can be hard to track down issues at times. It can take a bit of time to get used to what is a good or a bad ticket but it doesn't take long. Next time you see a bug file it at hub.qgis.org.

Squashing bugs

This is where the help really matters and is the best thing you can do for the project. If you're a developer and keen to try your hand at some bugfixing you can find the most important ones here.

Not a developer?

The next best thing you can do is fund some bug fixing. There are many ways to do this and this is the most effective way to get stuff done.

Your main options are:

• Donation to the QGIS fund - we use some of this money to pay for bug fixing.
• Hire a developer directly. This is a good way to go as it is focused development. You can find some of the devs here
• Rob a bank and send the money to us - No!11! Don't do that.
• Encourage your company - who maybe is now saving a lot of money - to sponser or hire a developer.
• Run a user group and charge a small fee to donate to the project - minus costs of course.

It's not just code.

There is more to QGIS then code and some application at the other end. With each release comes other non developer work.

These things include:

• Updating the manual
• Updating translations
• Helping with PR stuff like posters
• Ticket clean up

If you're not in a position to help in the other areas of the project these things need love to so don't forget you can help here.

We love that QGIS is free, that it opens GIS to a whole range of people who would never have been able to use it. It's a great feeling. It's also a great feeling when others get invovled and help us along to make it better for everyone.

qgis2img is a new tool that I created, in a bit of friendly competition with the boss, which I lost but we will not speak of that again, for benchmarking QGIS layer rendering. The goal is simple. Take a project file(s), or QLR file(s), render the output, time the results, and dump a summary. Simples. The tool does 3 passes by default to get the average but can do more. It's nothing fancy. Written in Python so it can be evolved quickly.

qgis2img will render each image by itself to give single timings then it will render the whole project as you see in QGIS.

It uses QGIS 2.4 (qgis-dev) in order to use the new rendering methods. I don't have any plans to port it to work with QGIS 2.2, however feel free to send a pull request.

The usage is pretty simple:

usage: qgis2img [-h] [--size SIZE] [--passes PASSES] [--types TYPES] file

Benchmark QGIS project file and layer loading times

positional arguments:
  file             Project file to load into QGIS

optional arguments:
  -h, --help       show this help message and exit
  --size SIZE      Image output size
  --passes PASSES  Number of render passes per layer
  --types TYPES    What to render. Options are layer|project, layer, or project.
                   layer|project will render all layers as the if the project
                   is open in QGIS.

with the results:

$ python.exe qgis2img parcels.qgs --passes 5
Project Loaded with: [u'PARCEL_region - Shp', u'PARCEL_region - Spatialite']
Rendering images with 5 passes
Layer: PARCEL_region - Shp      4.907 sec
Layer: PARCEL_region - Spatialite       3.66 sec
Layer: Project     5.3378 sec

Easy.

It will generate an image for each layer and the project:

You can find the project at https://github.com/DMS-Aus/qgis2img

Pull requests and ideas welcome

qgisbench

There is a tool called qgisbench in the QGIS source tree that does this kind of thing too, however:

• It's in C++
• We don't ship it
• It's in C++
• <3 Python
• These things are good examples for others
• Using the Python API in this ways lets me see gaps

qgis2img is a new tool that I created, in a bit of friendly competition with the boss, which I lost but we will not speak of that again, for benchmarking QGIS layer rendering. The goal is simple. Take a project file(s), or QLR file(s), render the output, time the results, and dump a summary. Simples. The tool does 3 passes by default to get the average but can do more. It's nothing fancy. Written in Python so it can be evolved quickly.

qgis2img will render each image by itself to give single timings then it will render the whole project as you see in QGIS.

It uses QGIS 2.4 (qgis-dev) in order to use the new rendering methods. I don't have any plans to port it to work with QGIS 2.2, however feel free to send a pull request.

The usage is pretty simple:

usage: qgis2img [-h] [--size SIZE] [--passes PASSES] [--types TYPES] file

Benchmark QGIS project file and layer loading times

positional arguments:
  file             Project file to load into QGIS

optional arguments:
  -h, --help       show this help message and exit
  --size SIZE      Image output size
  --passes PASSES  Number of render passes per layer
  --types TYPES    What to render. Options are layer|project, layer, or project.
                   layer|project will render all layers as the if the project
                   is open in QGIS.

with the results:

$ python.exe qgis2img parcels.qgs --passes 5
Project Loaded with: [u'PARCEL_region - Shp', u'PARCEL_region - Spatialite']
Rendering images with 5 passes
Layer: PARCEL_region - Shp      4.907 sec
Layer: PARCEL_region - Spatialite       3.66 sec
Layer: Project     5.3378 sec

Easy.

It will generate an image for each layer and the project:

You can find the project at https://github.com/DMS-Aus/qgis2img

Pull requests and ideas welcome

qgisbench

There is a tool called qgisbench in the QGIS source tree that does this kind of thing too, however:

• It's in C++
• We don't ship it
• It's in C++
• <3 Python
• These things are good examples for others
• Using the Python API in this ways lets me see gaps

NOTE Just to clarify. This is not adding the ability to open ArcGIS .lyr files.

One of the reasons that I love working and being part of the QGIS project is how quickly you can take it from not having a needed feature to having said feature. A good example of this is a recent addition I added related to having a ArcGIS .lyr like feature. For those who don't use Arc, the .lyr file is a pretty much a file that points to the data, contains all the styling, and other information, you can then just add this file and it will do all the other magic for you.

A quote from the ArcGIS page on the topic

A layer can exist outside your map as a layer file (.lyr). This makes it easy for others to access the layers you've built. You can share layers over the network and by e-mail. When users add a layer file to their maps, it will draw exactly as it was saved as long as they can get access to the data referenced by the layer. A common way that users help support this is to use relative paths to each layer's data source.

A question came up on GIS.SE asking Does QGIS have the equivalent of ArcGIS's Layer (*.LYR) file?. To which the answer was. "Not really". Which of course was true. At the time.

That got me thinking. Why couldn't we have a feature like this? It would be handy to have as it would let you create layer shortcuts and the ability to a load layers quickly from a single place without worrying about were the data comes from. The XML that we need to recreate the layer on project load was already stored in the project file under the maplayer node. It already has everything we need we can just write that out to disk and create a new file type. After some digging into the API I found QgsMapLayer::writeLayerXML() and Bingo! .qlr was born.

Because I personally, and some others I talked to, didn't really like just "Save as Layer File.." as it sounds a bit vauge, we picked "QGIS Layer Definition file".

A QGIS Layer Deinition File is simply the XML maplayer node, with the id removed, saved to disk as a .qlr format.

Saving one is as simple as Right Click Layer -> Save As Layer Definition File..

and loading Layer -> Add from Layer Definition File...

Simple!

The layer file will store any of the styles, labels, edit widgets, etc, that you have defined for that layer so it's just a matter of adding the file and you are good to go.

Like I said at the start it's simply the XML maplayer node, so if you move the data or want to change the datasource just open the file in a text editor and change it.

<!DOCTYPE qgis-layer-definition>
<maplayer minimumScale="-4.65661e-10" maximumScale="1e+08" simplifyDrawingHints="1" minLabelScale="0" maxLabelScale="1e+08" simplifyDrawingTol="1" geometry="Polygon" simplifyMaxScale="1" type="vector" hasScaleBasedVisibilityFlag="0" simplifyLocal="1" scaleBasedLabelVisibilityFlag="0">
  <datasource>F:/gis_data/cadastre.shp</datasource>
  <title></title>
  <abstract></abstract>
  <keywordList>
    <value></value>
  </keywordList>
  <layername>cadastre</layername>
  ... {style, etc}
</maplayer

This will work with any layer supported in QGIS, expect special plugin layers.

I will add loading from the browser dock before the release aswell once I get some time.

Can we get it in an older QGIS version?

All the methods that I used for this feature are exposed to the Python API. Once I get some free time I plan on making a plugin that is aimed at QGIS <2.3 to give those users the same feature. Keep an eye out for it in the plugin installer.

NOTE Just to clarify. This is not adding the ability to open ArcGIS .lyr files.

One of the reasons that I love working and being part of the QGIS project is how quickly you can take it from not having a needed feature to having said feature. A good example of this is a recent addition I added related to having a ArcGIS .lyr like feature. For those who don't use Arc, the .lyr file is a pretty much a file that points to the data, contains all the styling, and other information, you can then just add this file and it will do all the other magic for you.

A quote from the ArcGIS page on the topic

A layer can exist outside your map as a layer file (.lyr). This makes it easy for others to access the layers you've built. You can share layers over the network and by e-mail. When users add a layer file to their maps, it will draw exactly as it was saved as long as they can get access to the data referenced by the layer. A common way that users help support this is to use relative paths to each layer's data source.

A question came up on GIS.SE asking Does QGIS have the equivalent of ArcGIS's Layer (*.LYR) file?. To which the answer was. "Not really". Which of course was true. At the time.

That got me thinking. Why couldn't we have a feature like this? It would be handy to have as it would let you create layer shortcuts and the ability to a load layers quickly from a single place without worrying about were the data comes from. The XML that we need to recreate the layer on project load was already stored in the project file under the maplayer node. It already has everything we need we can just write that out to disk and create a new file type. After some digging into the API I found QgsMapLayer::writeLayerXML() and Bingo! .qlr was born.

Because I personally, and some others I talked to, didn't really like just "Save as Layer File.." as it sounds a bit vauge, we picked "QGIS Layer Definition file".

A QGIS Layer Deinition File is simply the XML maplayer node, with the id removed, saved to disk as a .qlr format.

Saving one is as simple as Right Click Layer -> Save As Layer Definition File..

and loading Layer -> Add from Layer Definition File...

Simple!

The layer file will store any of the styles, labels, edit widgets, etc, that you have defined for that layer so it's just a matter of adding the file and you are good to go.

Like I said at the start it's simply the XML maplayer node, so if you move the data or want to change the datasource just open the file in a text editor and change it.

<!DOCTYPE qgis-layer-definition>
<maplayer minimumScale="-4.65661e-10" maximumScale="1e+08" simplifyDrawingHints="1" minLabelScale="0" maxLabelScale="1e+08" simplifyDrawingTol="1" geometry="Polygon" simplifyMaxScale="1" type="vector" hasScaleBasedVisibilityFlag="0" simplifyLocal="1" scaleBasedLabelVisibilityFlag="0">
  <datasource>F:/gis_data/cadastre.shp</datasource>
  <title></title>
  <abstract></abstract>
  <keywordList>
    <value></value>
  </keywordList>
  <layername>cadastre</layername>
  ... {style, etc}
</maplayer

This will work with any layer supported in QGIS, expect special plugin layers.

I will add loading from the browser dock before the release aswell once I get some time.

Can we get it in an older QGIS version?

All the methods that I used for this feature are exposed to the Python API. Once I get some free time I plan on making a plugin that is aimed at QGIS <2.3 to give those users the same feature. Keep an eye out for it in the plugin installer.

Here is a quick tip from a GIS.SE post that I answered the other day.

The topic was keeping the WMS settings in sync over different operating systems and machines. Normally QGIS will store it settings in the registry on Windows and in different locations on Linux and OS X. So then comes the question of how do you keep them in sync if you are using different machines.

Well the answer is simple. QGIS provides --optionspath and --configpath command line options in order to move the .qgis2 and settings files. Using these two options, or just the one depending on what you need, will allow you to store the QGIS settings in a different location. Rather then storing the settings in the registry, or .config and .plist files, it will create a .ini file and save everything there.

All in all this means you can redirect your QGIS settings to a folder on dropbox and tell your QGIS installs to load the settings from a single place keeping everything in sync. When you change a setting it will sync with Dropbox and onto your other machines.

The simple way on Windows to add the --optionspath and --configpath options is to copy the shortcut to QGIS and append it to the end of the Target.

--optionspath "F:\mydropbox\qgis" --configpath "F:\mydropbox\qgis"

QGIS IN THE CLOUD!!11! ok not really but still cool

Here is a quick tip from a GIS.SE post that I answered the other day.

The topic was keeping the WMS settings in sync over different operating systems and machines. Normally QGIS will store it settings in the registry on Windows and in different locations on Linux and OS X. So then comes the question of how do you keep them in sync if you are using different machines.

Well the answer is simple. QGIS provides --optionspath and --configpath command line options in order to move the .qgis2 and settings files. Using these two options, or just the one depending on what you need, will allow you to store the QGIS settings in a different location. Rather then storing the settings in the registry, or .config and .plist files, it will create a .ini file and save everything there.

All in all this means you can redirect your QGIS settings to a folder on dropbox and tell your QGIS installs to load the settings from a single place keeping everything in sync. When you change a setting it will sync with Dropbox and onto your other machines.

The simple way on Windows to add the --optionspath and --configpath options is to copy the shortcut to QGIS and append it to the end of the Target.

--optionspath "F:\mydropbox\qgis" --configpath "F:\mydropbox\qgis"

QGIS IN THE CLOUD!!11! ok not really but still cool

tl;dr

The API had to change. We don't like breaking plugins. It makes us sad. We did it now to save pain in the future. You will like the new version better. Trust me.

What happened to my cheese?

When updating to QGIS 2.0 you might have noticed two things. (Apart from all the new awesome stuff!)

1. All your settings have been set back to defaults
2. Some of your plugins are gone, or missing in the installer.

Resetting of settings is caused by QGIS now storing its 2.0 settings in a different folder then we used for 1.8. In 1.8, all your plugins, etc, were stored in the ./qgis folder in your home directory, in 2.0 these are now stored in ./qgis2. The reason will become evident later. All user settings, the UI layout, database connections, etc, are now stored in a QGIS location. In windows this in the registry key HKEY_CURRENT_USER\Software\QGIS\QGIS2. So this explains why your settings are missing when you first load QGIS 2.0.

Why did we have to move the settings location?

Good question.

2.0 is very different from 1.8. There has been a lot of work to make this the best version we have ever made, new features, more bug fixes, a bigger dev team, and a even bigger community. Being the next major release we had to make some calls to remove some of the old code and features that were weighing us down. Features such as the old labelling engine, old symbol engine, the old vector API. Carrying old code and old out dated features into the future can sometimes really hurt a project and they have to be cut loose. Because of the massive amount of changes in 2.0 people needed to be able to run 2.0 and 1.8 on the same machine without causing any issues. If they both store settings in the same location this would have had bad results.

Why move the settings. Part 2

Moving the settings was also a result of having non backwards compatible plugins between 1.x and 2.x. If we kept both plugins in the same folder it just wouldn't work. You would install a 1.8 version of a plugin, I would update my plugin to 2.0, you then install the same plugin in 2.0, and now you 1.8 version is broken. Fun!. To avoid this we moved all QGIS 2.0 stuff into ./qgis2.

Why did my plugins break anyway. Why not just leave them be.

In 1.x we were using SIP v1. This meant the framework we used, PyQt, felt more like C++ then it did Python. If you are a Python developer then this isn't a very fun thing to deal with. In SIP v1 you need to tell PyQt, and our QGIS API, what to convert the type to. feature['mycolumn'].toInt() that is pretty gross. In V2 you can just do feature['mycolumn'] and SIP will auto convert the type for you. This makes our API feel more like Python and less like C++. There are other changes when using SIP V2 but you get the idea. Unfortunately SIP v1 and v2 do not work together so we couldn't make the code backwards compatible. This was also a forced change for us. Once we switch to Python 3 at some stage in the future V2 would be the default and we have to change then. The bright side of this change is most of the time you are removing code. Consider it a good time to go though your code, give it a bit of a polish, and remove anything that is no longer needed.

There was another major API change that needed to happen. Vector API update. In order to allow for multithreading in the future, and we all know everyone is looking forward to that, we needed to change how code can ask for features from a layer. The old method would never work in a multithreaded structure and had to go.

What can I do if I need a plugin?

Having a plugin missing from the plugin installer when you really need it can be a bit of a pain. Plugin authors are working hard to update there plugins. I approve about two a day into the plugin repository. While most plugins might be updated at some stage. There are some things that you can do if you need a plugin update to work with 2.0.

1. Email the author of the plugin to see where they are at with the update

2. Email the author and offer your help to update the plugin. Remember a lot of plugins are written by volunteers who just need the plugin to get their work done and wanted to share it with everyone.

3. If the author has no intention of updating the plugin, or can't be contacted. You are free to update you local copy and offer it back to the community as the updated copy. If you are going to upload it back to the plugin repository please try to contact the author and seek permission first. I will be watching for copies of plugins to make sure we don't end up with 10 versions of the same plugin. The GPL allows for you to modify and share your updated version but it's nice to keep the original author in the loop. If the author no longer wants to maintain the plugin and you are able to then contact me and I will make you the owner of the plugin. Overall be nice not evil, we are all friends here.

4. If you don't have, or know someone with, the skills to update the plugin. You can contact a developer to help update the plugin for you. Companies like mine, or Faunalia, or a whole range of other open source devs, can normally be contracted to update a plugin if needed.

Moving forward

We like the new API. It makes the Python side of QGIS much cleaner. There is still more work to do, it's never ending, but this is a good step. We don't like breaking plugins, but breaking a few now is better then breaking heaps as the popularity of QGIS continues to grow.

tl;dr

The API had to change. We don't like breaking plugins. It makes us sad. We did it now to save pain in the future. You will like the new version better. Trust me.

What happened to my cheese?

When updating to QGIS 2.0 you might have noticed two things. (Apart from all the new awesome stuff!)

1. All your settings have been set back to defaults
2. Some of your plugins are gone, or missing in the installer.

Resetting of settings is caused by QGIS now storing its 2.0 settings in a different folder then we used for 1.8. In 1.8, all your plugins, etc, were stored in the ./qgis folder in your home directory, in 2.0 these are now stored in ./qgis2. The reason will become evident later. All user settings, the UI layout, database connections, etc, are now stored in a QGIS location. In windows this in the registry key HKEY_CURRENT_USER\Software\QGIS\QGIS2. So this explains why your settings are missing when you first load QGIS 2.0.

Why did we have to move the settings location?

Good question.

2.0 is very different from 1.8. There has been a lot of work to make this the best version we have ever made, new features, more bug fixes, a bigger dev team, and a even bigger community. Being the next major release we had to make some calls to remove some of the old code and features that were weighing us down. Features such as the old labelling engine, old symbol engine, the old vector API. Carrying old code and old out dated features into the future can sometimes really hurt a project and they have to be cut loose. Because of the massive amount of changes in 2.0 people needed to be able to run 2.0 and 1.8 on the same machine without causing any issues. If they both store settings in the same location this would have had bad results.

Why move the settings. Part 2

Moving the settings was also a result of having non backwards compatible plugins between 1.x and 2.x. If we kept both plugins in the same folder it just wouldn't work. You would install a 1.8 version of a plugin, I would update my plugin to 2.0, you then install the same plugin in 2.0, and now you 1.8 version is broken. Fun!. To avoid this we moved all QGIS 2.0 stuff into ./qgis2.

Why did my plugins break anyway. Why not just leave them be.

In 1.x we were using SIP v1. This meant the framework we used, PyQt, felt more like C++ then it did Python. If you are a Python developer then this isn't a very fun thing to deal with. In SIP v1 you need to tell PyQt, and our QGIS API, what to convert the type to. feature['mycolumn'].toInt() that is pretty gross. In V2 you can just do feature['mycolumn'] and SIP will auto convert the type for you. This makes our API feel more like Python and less like C++. There are other changes when using SIP V2 but you get the idea. Unfortunately SIP v1 and v2 do not work together so we couldn't make the code backwards compatible. This was also a forced change for us. Once we switch to Python 3 at some stage in the future V2 would be the default and we have to change then. The bright side of this change is most of the time you are removing code. Consider it a good time to go though your code, give it a bit of a polish, and remove anything that is no longer needed.

There was another major API change that needed to happen. Vector API update. In order to allow for multithreading in the future, and we all know everyone is looking forward to that, we needed to change how code can ask for features from a layer. The old method would never work in a multithreaded structure and had to go.

What can I do if I need a plugin?

Having a plugin missing from the plugin installer when you really need it can be a bit of a pain. Plugin authors are working hard to update there plugins. I approve about two a day into the plugin repository. While most plugins might be updated at some stage. There are some things that you can do if you need a plugin update to work with 2.0.

1. Email the author of the plugin to see where they are at with the update

2. Email the author and offer your help to update the plugin. Remember a lot of plugins are written by volunteers who just need the plugin to get their work done and wanted to share it with everyone.

3. If the author has no intention of updating the plugin, or can't be contacted. You are free to update you local copy and offer it back to the community as the updated copy. If you are going to upload it back to the plugin repository please try to contact the author and seek permission first. I will be watching for copies of plugins to make sure we don't end up with 10 versions of the same plugin. The GPL allows for you to modify and share your updated version but it's nice to keep the original author in the loop. If the author no longer wants to maintain the plugin and you are able to then contact me and I will make you the owner of the plugin. Overall be nice not evil, we are all friends here.

4. If you don't have, or know someone with, the skills to update the plugin. You can contact a developer to help update the plugin for you. Companies like mine, or Faunalia, or a whole range of other open source devs, can normally be contracted to update a plugin if needed.

Moving forward

We like the new API. It makes the Python side of QGIS much cleaner. There is still more work to do, it's never ending, but this is a good step. We don't like breaking plugins, but breaking a few now is better then breaking heaps as the popularity of QGIS continues to grow.