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


Don’t do this:

self.connect(self.widget, 
             SIGNAL("valueChanged(int)"), 
             self.valuechanged)

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:

self.widget.valueChanged.connect(self.valuechanged)
self.widget.valueChanged[str].connect(self.valuechanged)

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.

Advertisements

A interactive command bar for QGIS


Something that has been on my mind for a long time is a interactive command interface for QGIS.  Something that you can easily open, run simple commands, and is interactive to ask for arguments when they are needed.

After using the command interface in Emacs for a little bit over the weekend – you can almost hear the Boos! from heavy Vim users :) – I thought this is something I must have in QGIS as well.  I’m sure it can’t be that hard to add.

So here it is.  A interactive command interface for QGIS.

commandbar

commandbar2

The command bar plugin (find it in the plugin installer) adds a simple interactive command bar to QGIS. Commands are defined as Python code and may take arguments.

Here is an example function:

@command.command("Name")
def load_project(name):
    """
    Load a project from the set project paths
    """
    _name = name
    name += ".qgs"
    for path in project_paths:
        for root, dirs, files in os.walk(path):
            if name in files:
                path = os.path.join(root, name)
                iface.addProject(path)
                return
    iface.addProject(_name)

All functions are interactive and if not all arguments are given when called it will prompt for each one.

Here is an example of calling the point-at function with no args. It will ask for the x and then the y

pointat

Here is calling point-at with all the args

pointatfunc

Functions can be called in the command bar like so:

my-function arg1 arg2 arg2

The command bar will split the line based on space and the first argument is always the function name, the rest are arguments passed to the function. You will also note that it will convert _ to - which is easier to type and looks nicer.

The command bar also has auto complete for defined functions – and tooltips once I get that to work correctly.

You can use CTRL + ; (CTRL + Semicolon), or CTRL + ,, to open and close the command bar.

What is a command interface without auto complete

autocomplete

Use Enter to select the item in the list.

How about a function to hide all the dock panels. Sure why not.

@command.command()
def hide_docks():
    docks = iface.mainWindow().findChildren(QDockWidget)
    for dock in docks:
        dock.setVisible(False)

alias command

You can also alias a function by calling the alias function in the command bar.

The alias command format is alias {name} {function} {args}

Here is an example of predefining the x for point-at as mypoint

-> alias mypoint point-at 100

point-at is a built in function that creates a point at x y however we can alias it so that it will be pre-called with the x argument set. Now when we call mypoint we only have to pass the y each time.

-> mypoint
(point-at) What is the Y?: 200

You can even alias the alias command – because why the heck not :)

-> alias a alias
a mypoint 100

a is now the shortcut hand for alias

WHY U NO USE PYTHON CONSOLE

The Python console is fine and dandy but we are not going for a full programming language here, that isn’t the point. The point is easy to use commands.

You could have a function called point_at in Python that would be

point_at(123,1331)

Handling incomplete functions is a lot harder because of the Python parser. In the end it’s easier and better IMO to just make a simple DSL for this and get all the power of a DSL then try and fit into Python.

It should also be noted that the commands defined in the plugin can still be called like normal Python functions because there is no magic there. The command bar is just a DSL wrapper around them.

Notes

This is still a bit of an experiment for me so things might change or things might not work as full expected just yet.

Check out the projects readme for more info on things that need to be done, open to suggestions and pull requests.

Also see the docs page for more in depth information

QGIS 2.0: Dealing with Null values in pyqgis


Nothing in life ever comes free. Each time you make a desision there can sometimes be long a lasting effect. This is exectly the case with the new QGIS 2.0 pyqgis API. Changing to the new api was a big step in order make the API clear and more Pythonic. But there was a small detail to fix.

In QGIS 2.0 we can now just do this to read the attribute value for a field:

>>> feature['yourcolumn']
"Hello World"

What would you expect to get if the value was NULL (not empty string). Would you expect to see None? You would think so. Right? However lets just check that.

>>> feature['yourcolumn']
NULL

NULL? What the heck? That isn’t None! What is NULL?

>>> type(NULL)
<class 'PyQt4.QtCore.QPyNullVariant'>

QPyNullVariant WA! WHAAAT! Why didn’t we get None? Turns out by removing QVariant from PyQt it had some impact on methods that expected a NULL QVariant – A QVariant with no value. Passing None didn’t work because those methods needed the type information that QVariant holds, even when NULL.

When using SIP V2, which is what QGIS 2.0 is using, PyQt will auto convert any Null QVariants to QPyNullVariant.

The NULL you see is a variable masking the QPyNullVariant so that the output is nicer and it’s easier to work with. We have also added a bunch of methods to QPyNullVariant in order to make it act as much like None as we can.

If you see a NULL this is how you can deal with it:

>>> feature['yourcolumn']
NULL

>>> if not feature['nullcolumn']:
>>> print "Was null"
Was null

>>> if feature['nullcolumn'] == NULL:
>>> print "Was null"
Was null

NULL will also return False if boolean checked:

>>> value = NULL
>>> if value:
... print "This value wasn't null"
... else:
... print 'This value was null'
This value was null

It will also be equal to any other NULL aka QPyNullVariant variable

>>> value = NULL
>>> value2 = NULL
>>> value == value2
True
>>> value = 100
>>> value2 = NULL
>>> value == value2
False

Does None is NULL work? No.

One way to check if something is Null in Python is to use value is None however this will not work with our NULL type. Overloading the is operator in Python is not supported and there is no way we can support this – trust me I have tried. is is really doing id(object) == id(object) under the hood:

DO NOT do the following if you are checking for null values in pyqgis unless you know the return type is None:

>>> value = NULL
>>> value is None
false