Logging - simple mistake

I recently ran into a problem where my logging started to duplicate each log message, but in a different format after one particular logging call.

I could not track down the error, until I actually read what I wrote:

import logging

logger = logging.getLogger("a.logger")

class Something:
    ...
    logging.debug("a message")

I'd accidentally called debug on the logging module, not my logger. Everything I was googling was pointing towards enabling the default logging config (e.g.

logging.basicConfig()

) but I hadn't done so.

Easy mistake to make, thought I'd briefly write about it.

Adding logging to Whyteboard

I've been undertaking quite a large change to the program: logging. Now, the program prints out a log of debug, information and warning logs to help see what's going on. I'm perhaps 25-30% complete in adding the logging, and it's already helping immensely. Just when loading a file for example, I can now see the steps the program takes in figuring out whether to convert a PDF, load a .wtbd file and then the step-by-step actions being performed there. It's great


I'm just not too sure about the best strategy for debugging things like events - e.g. in the mouse motion event handler, which gets called hundreds of times for the Pen tool, we don't want to flood the console.

Also, not too sure about what to do with logging the debug messages to file by default? One of the whole points to all of this is that I can view a user's debug log to see what they did before triggering some exception in an error report.

hmm.

Article on Whyteboard in Dec 2010 Linux Journal

An article has been published in Issue 200, December 2010 of the Linux Journal magazine, in the "new projects" section. Praise was given for its simple UI, PDF annotating abilities, the history replay view and being able to embed multimedia into a sheet.

Having a simple website

The Whyteboard home page is simple. Very simple. I was going to create a "modern" site, with some nice javascript goodness and whatnot, but I have trouble creating a website from blank. I'm not much of a design guy - I do a little CSS at work, but not in a few months, and it's always been making changes to existing sites.

So, I've gone the complete opposite and done the most basic site I could. It's pretty much one page with some summarised information about the program.

Whyteboard 0.41 released!

Hurrah - finally got a release by the end of the month as I was hoping to do.

This version should finally kill off all unicode related bugs - in total, over 15 bugs have been fixed. I'm embarrassed that they slipped through my radar - but at least they're now fixed.

What's new in this release?

- Program now reads in your system language at startup and sets the default locale based on that. No more setting preferences!
- Many enhancements to the "Shape Viewer" dialog
- Misc. UI improvements such as little * shown in the program title when there's unsaved changes.

- Massive code overhauls and changes to make the program easier to develop on



Wow! Looking back it seems like there's not much new...

Download at http://code.google.com/p/whyteboard/downloads/list

Packaging her up

I've decided to try and package my classes into more appropriate locations instead of containing everything into one directory. I've just committed a repackaging of my GUI classes. I'd like to go further and split each file into smaller modules, with one classes each, especially for my "Tools".

However doing this will definitely break older save files and I'll have to monkey patch around it. I think I should move away from using Pickle as my save format, and perhaps use JSON instead. I just need to find a way to make a save converter for existing files...

Refactoring, refactoring

I've spent some time refactoring the program's code lately. The GUI class is getting really bloated with features and functionality that should be handled by a separate class. Thus, I've created a Menu class to create, bind and query the menu. Pretty good...

Also in the utility class, my save method was growing to over 100 lines, with many temporary variables being used. I managed to extract this into its own class, and split up the method into several smaller ones, passing parameters between them as needed. My temporary variables from the giant class became instance variables in the extracted class.

The end result is more code, but ultimately an easier to read, more abstract higher level save method - you just read the method calls it makes, as opposed to having to iterate over objects, save values etc inside the method.

I need to apply this to many more places in the program. I want to refactor out tab control to its own class, so that it can be shared by the Notes, thumbs and gui classes; these all share common data but it's duplicated per-class. Also the code is really hard to test - refactoring it out will definitely help.