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

error

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.

message

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.

dialog

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.

Advertisements

10 thoughts on “Not always about new features

  1. Maybe add a . to separate the exception and the instructions? Also you could just have one button that provides the message window, and then allow stack trace access from that.

  2. Although it could mean that it will require more clicks to debug errors in code. Additionally there are many cases in which I would rather the code be blocked before committing more invalid code/ data.

    1. I’m not sure this is going to really change anything in regards to invalid code or data. The code would still continue when you hit cancel. If you expect something bad to happen you should handle the exception before it gets to this point.

  3. This is going to be great for end users!
    Just curious, is it possible to have a “debug” option available, so that when we’re building Python plugins and doing testing, we can turn this on so that we have the current dialog displayed as it currently is?

    1. Personally I would rather not. IMO the better option is to open the log window and the errors will show there. You can leave it open and QGIS will remember the position, etc.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s