Not always about new features

I love a good feature just as much as the next person but sometimes it’s great to fix a small workflow issue that has bugged you for the longest time.

If you have ever seen this kind of dialog you will know what I mean


The good old Python error dialog in QGIS.  The dialog is there to tell you that an exception was raised in Python somewhere and would dump out the error for you to debug it.   One big issue with this dialog though.  It’s blocking.  Blocking dialogs are really bad.   As a user, the blocking dialog means a broken workflow. Worst of all, there really is nothing you can do about it because the only thing you can do is close.

This dialog has now been replaced with a message bar if something goes wrong in Python code.  The message bar is non blocking and lets you continue working even if something didn’t work correctly.


The message bar has two buttons.  One will open the stack trace dialog to see the error in more detail. The other button opens the log window.


The message bar will only show a single error message for each type of error even if there are multiple exceptions in a row. A good example of this is an error in a mouse move event handler causing a error on each mouse move.

UI theme support now core in QGIS

I enjoy using the dark UI theme for QGIS so much I figured why not make it a core feature. In the next version of QGIS if you head to the options screen you can now find a UI Theme option.

Options | General_037

The default dark theme is called Night Mapping for all those late night mapping jobs that you do, or if you just like dark UI themes.

QGIS b789fab_029



Something you will notice with this theme is the custom icons for the layer visibility. Pretty nifty! Here is how it is done

Creating new themes

To create a new theme simply make a new folder in .qgis2\themes\ with the name of the theme you want and create a style.qss file inside there. Check out the default themes for an example

Follow the Qt style sheet guides to see what can be styled.

Something I have added on top of the normal style sheets is variable support. Variables can be declared in a variables.qss file in the theme folder.

Here is an example of some variables:

@background: #323232
@text: #aaa
@selection: #507098
@menuback: #444
@highlight: #ffaa00

Now in style.qss we can do this:

color: @text;
background-color: @background;

Great for not having to repeat your self or quick updating in a single place. When the theme is applied via the Options dialog or via the API it will replace the variables in style.qss using variables.qss. The result file is called

Needs some tweaks

The default dark theme is a collection of stuff I have found around the net and stuff I have added myself. It’s far from prefect and I would love help to make it the best dark theme for QGIS. If you have another theme you think would make a good default one open a pull request on GitHub


Mixing a bit of Excel into QGIS – conditional formatted table cells

I was using Excel the other day and used the conditional formatting rules to style some cells based on a condition. If you have never seen or used them they look like this:

They are pretty handy for a quick idea on the state of your data.  Looking at QGIS I thought to myself “Wait!? Why not do that in QGIS too. That would be pretty neat”.  And with that here it is, finally!. Conditional formatting rules for QGIS attribute table.



You can control the font style, color, background color, even custom icons based on QGIS symbols. The buttons at the top give you access to quick styles which you can tweak more with the other options.

The conditions are just normal QGIS expressions. Use the special variable @value to refer to the current cell value. As they are normal QGIS expressions you can reference the other fields in the expressions.

(Click the GIF for a better view)


So go nuts. I would love to hear any feedback if you use it. Try it out in the next nightly dev build.

QGIS UI themes plugin

Scrap that idea. Seems there is already a  plugin to do this called Load QSS.  I’m not going to duplicate effort. Use that one and we can all make it better.

Want to have a dark theme, or even your own custom theme, for QGIS?  No worries. The UI Theme plugin has your back. Grab it from the plugin installer.  

Change the theme using Plugins -> UI Themes -> Theme It!


Just select a theme and the interface will change styles.  Here is the dark theme called “Much Dark. Such Goth” :)


I will let you try the “Oh my eyes” theme.

Themes can be added by creating a {name}.css file in plugin folder themes folder and edited __init__.pyfile to list the theme.  I’m working on this to make it better but I wrote this in about half an hour so it’s not all there yet.

The active themes is saved in the settings and restored on QGIS load.

If you make a cool theme feel free to make a pull request or ticket so it can be added to the plugin for others to use.  There is heaps that can be done with the Qt stylesheets so go nuts and make something cool.

Note: It’s a work in progress and things might not always look right.

Hat racks; or appreciating people for what they do.

The biggest thing with open source work is that it can be pretty thankless. There is a lot more that goes into a open source project then just some lines of code, there is events, documentation, API documentation, PR material, more documentation, websites, build setups, etc. It’s quite easy to just look at a project on GitHub, check out the graphs and see the top contributors and never think about it again. Because the code is all that matters right?


All hail Jürgen and Nyall!

Getting back to the point.  There is a lot of stuff that goes into an open source project that can go unnoticed and under appreciated.  Stuff that isn’t code is hard to track.  Do you know who maintains the QGIS website? What about who translates the UI? What about who ran the last dev meetings? These projects are non code related but are normally things that go unnoticed or under appreciated simply because it’s not a fancy chart in GitHub.  Making people feel welcome and appreciated in a project normally leads to a higher retention rate and a better overall feel for the project.  I remember when I was first thanked for the work I added to QGIS and how it made me feel, still here doing the same thing so it must have worked pretty well.

At PyCon AU 2015  Katie McLaughlin gave a talk about welcoming contributions to a project and being generally being nice to people. Not just being nice but actively thanking people for what they do and how it makes you feel. People generally put a lot of time into the projects they involve themselves in knowing you are appreciated makes you feel good.

Katie got the idea for the project from the talk and post titled A Place to Hang Your Hat by Leslie Hawthorn.  It seems like a silly title but read it and it will all make sense.

Her sub text makes the perfect summary:

On getting many good things done. And no one knows you’re doing any of it.

I’m not going to copy the post here but I will steal her tl;dr part:

  • If someone has volunteered to help your project, take the time to write a 2-3 sentence summary of what they did to help.
  • You can send it to them, along with a thank you note, or offer to post it on their LinkedIn profile. (Remember, users can approve recommendations before they’re added to their profile.)
  • Let’s spend some time celebrating our successes and all of our contributions! Let folks know you’re celebrating that success using #LABHR as a hashtag.
  • #LABHR stands for Let’s All Build a Hat Rack. For why its an awesome acronym, you have to read the post.

And here is the example post she makes:

Sample Recommendation

Deb Nicholson, Board Member, Open Hatch
While not strictly related to her work as an OpenHatch board members, Deb has given me invaluable counsel on fundraising for various non-profits I’ve been affiliated with. She’s also trained numerous community members on how to perform in-person advocacy for free and open source software projects, and software patent reform. As part of that training, she’s also convened numerous meetings and round tables to help people get things done in the open source world. She performs all this work with grace and patience for our sometimes difficult personalities. She’s brilliant and utterly unflappable. Cannot recommend her work highly enough.

So go ahead. Write something nice about someone and what they have done. Send it to them, blog about it, put it in Twitter, LinkedIn, etc.

Accessing composer item properties via custom expressions in QGIS

So here is a neat trick. Lets say you wanted to access the scale of a composer map to make it part of a label. The scale bar can already be set to numeric to show the number value but what if it needs to be part of an existing label with other text. Not to fear, expression functions are here.

  • Create a new composer. Add the map frame and a label.
  • Set the item ID of the map frame to something you can remember, lets just use themap
  • Select the label and add some text
  • Click Insert Expression

Now for the cool part

  • Select Function Editor
  • Click New File. Give the file a new name and hit save. I called it composer functions.

In the code editor paste this code:

from qgis.utils import iface
from qgis.core import *
from qgis.gui import *

@qgsfunction(args="auto", group='Composer')
def composeritemattr(composername, mapname, attrname, feature, parent):
    composers = iface.activeComposers()
    # Find the composer with the given name
    comp = [composer.composition() for composer in composers 
                if composer.composerWindow().windowTitle() == composername][0]
    # Find the item
    item = comp.getComposerItemById(mapname)
    # Get the attr by name and call 
    return getattr(item, attrname)()
  • Click Run Script


Now in your label use this text:

Scale: [% composeritemattr('Composer 1', 'themap', 'scale')%]

Update the Composer 1 to match your composer name, and the themap to match your item ID.

and like magic here is the scale from the map item in a label:

2015-05-21 22_00_09-Composer 1

Check the expression error section if the label doesn’t render


PSA: Please use new style Qt signals and slots not the old style

Don’t do this:


It’s the old way, the crappy way. It’s prone to error and typing mistakes. And who really wants to be typing strings as functions and arg names in it. Gross.

Do this:


Much nicer. Cleaner. Looks and feels like Python not some mash up between C++ and Python. The int argument is the default so it will use that. If you to pick the signal type you can use [type].

Don’t do this:

self.emit(SIGNAL("changed()", value1, value2))

Do this

class MyType(QObject):
   changed = pyqtSignal(str, int)

   def stuff(self):
       self.changed.emit(value1, value2)

pyqtSignal is a type you can use to define you signal. It will come with type checking, if you don’t want type checking just do pyqtSignal(object).

Please think of the poor kittens before using the old style in your code.