Looking Back on Review Board

Just over 3.5 years ago, David Trowbridge and I spent some time discussing the annoyances of the typical patch submission and code review processes in the open source projects we participated in and at companies, and decided to play with some ideas for improving this. At the time, we knew very little about what we intended to do. We had a name for it pretty early on, but that was about all we had. We didn’t even know whether we’d get past an early prototyping stage. But here it is, over 3 years later, and we have the leading open source code review tool with an active support and development community, hundreds of companies using it, and exciting new innovations for aiding in the code review process.

I was thinking a few days ago about how far we’ve come and some of the decisions we made along the way. I went digging through our commit history in order to relive some of the past of our little project. Since so few people were even aware of Review Board’s existence at the time, I thought I’d share some of our history with you. Particularly the interesting and funny bits.

“Add the reviewboard.”

Commit #1. The very first thing we put in our Subversion tree on September 27, 2006. I don’t even remember what was in this change now. We transitioned to Git last year and this commit is now just plain empty. Maybe it was jut the directory structure? Who can say.

Early on, we didn’t refer to “Review Board” as a proper name. It was generally “the reviewboard” or something similar. The codebase was young. We didn’t actually do code review on the project at this point (and it shows!). The first few months are littered with odd or nonsensical commit messages, small breakages, and bad decisions.

A few of my favorite commit messages are:

  • “I suck. Make submitting of reviews.”
  • “Don’t stuff the list of files in the bug list. It’s impolite.”
  • “Avoid failing out with Christian’s wacko form”
  • “Gum.”
  • “Holy apple pancakes. It worked!”
  • “I suck… The array was empty… The tests never had a chance to fail. :(“
  • “‘This is a summary’ sucks. Now we use fortune for the summary, description, and testing done. ‘You’re ugly and your mother dresses you funny.'”
  • “Unbreak things before ChipX86 notices”
  • “I’m just… garhgh”

Nowadays, our commit messages look nothing like that, but that’s the fun of a new project. You get to go commit-crazy while you try to figure out what you’re building.

Dashboard, quips and fortunes

The UI of old looked quite different than the UI of today.

We had a dashboard from the very beginning (before the review request pages, even) but it wasn’t anything like the dashboard we had today. It was a simple page with a table containing all outgoing review requests and a table containing incoming review requests. But it also had one more thing: quips.

The beginning of quips functionality was being built. Quips are just little random quotes that are inserted in the UI. I think the plan was to put quips on certain pages, making Review Board a little more fun. We were using them in the dashboard for empty lists, with variations all saying something about the dashboard being empty. Quips are a neat feature that just never survived the early days of development.

Fortunes are similar. On Linux/Unix systems, there’s a little program called “fortune” that just displays a random quote. Since we at first had to test review request functionality without actually having a repository backend of any sort, and we didn’t want to input all the information each time, we just used fortune to generate the summary, description and testing done text. This made for some really funny review requests early on, but this is of course something that had no reason to survive initial development.

Sometimes we would create a bunch of review requests just to see what kind of quotes we’d get. 🙂

Multiple repositories? Almost didn’t happen.

One of the really critical parts of Review Board today is the ability to talk to a variety of different types of repositories in one instance. But, it turns out, this almost didn’t happen.

The initial goals were not that ambitious. Review Board talked to one repository per instance. Everything was basically hard-coded with one repository in mind. That type of repository, as well as its information, was customizable. You just couldn’t have more than one. At the time, this wasn’t a problem, but it didn’t take long until we had a need to talk to two repositories.

We discussed this and at first decided that if we needed to talk to two repositories, we could just set up two instances. It would have been a lot of work to update it for multiple repositories, after all. And really, this was a small project. Who would really need more than a couple repositories? This started to nag at me, though, and so I spent a couple nights rewriting all of the code as an experiment. It ended up working pretty nicely, and we were able to ditch the multi-instance model.

The importance of rewards

It’s always nice to have a little reward for milestones. Developers sometimes compete over cool bug numbers, revisions, etc. Initially, we were going to use quips to add some fun to the site, but we ended up settling on our current trophy system.

One of our first Review Board instances started to approach review request #1000, which was a huge milestone for us. I decided to commemorate the event by staying up and quickly hacking in a hidden feature for showing a trophy for review request #1000. The way we implemented it, you’d see the first ever trophy at 1,000, and from there you’d see it at every milestone number (1,000, 2,000, 3,000, 10,000, etc.). I didn’t want to stop there, though, so I added support for a second type of trophy, one that has confused people with its appearance to this day. Mission complete.

Of course, when we updated the server and someone finally hit 1000, it triggered a bug in the new trophy code and broke his review request. Oh well, I tried.

Diff viewers are hard

If I could pick one point during the whole history of Review Board where I was ready to completely give up, it would be during the creation of our diff viewer. All three diff viewers.

See, the first diff viewer was a complete and total hack. We generated a side-by-side diff using the diff tools and just parsed the output, basically generating a table of that. It was ugly, though, and limiting. It also caused problems where text on a row would either be truncated or would break the parser. I spent a long time working on this before I totally gave up and went on to try a new approach.

My second approach was closer to what we have today, but also limiting and very, very buggy. We were using Python’s built-in diff generation module, which implements a basic diff algorithm. It gave us insert and delete information, but not replace information. We had to hack that in ourselves, and it was really a hack. Try taking a bunch of inserts and deletes and find out which of those are really changed lines. No, really, try it. It’s harder than you think, and it’ll often be wrong.

Still, we stuck with this for a long time. It was slow, buggy, and didn’t generate the sort of output people expected from diff tools. Most people see diffs from GNU Diff, which implements the Meyers Diff Algorithm (with a few additions and tweaks). These Meyers diffs are much nicer to view than what Python gave us. Another problem we hit was that we didn’t have real line number information, so we had to output fake line numbers. They weren’t really line numbers so much as row numbers in the table. Ugh. Even getting this far was really hard and frustrating, and the result still wasn’t good.

Attempt #3. I decided to build our own diff parser and generator from scratch. What a project. I knew nothing about diff generation and hardly knew where to start. I spent probably a good month or so just trying to work on this new diff code, and was so close to giving up so many times. It ended up being completely worth it, though, as we ended up with a very nice, extensible diff parser.

Without that third attempt, we’d be in the stone age. Review Board would not be as nice to use. We wouldn’t have inter-line diffs (where we highlight what changed in a replace line), syntax highlighting, move detection (coming in 1.5), or function/class headers (where we show which function/class the part of the diff is in — also coming in 1.5).

What else…

Well, there’s a lot more I could talk about. Our initial attempts at JavaScript code for the UI, our trials and challenges with database migration, or our early problems storing diffs with different encodings in databases. This is getting long, though, so I’ll cover these in another post on lessons learned.

Infect your application with Parasite!


Ever find yourself stuck debugging an application because the UI is just doing something weird that you can’t track down? Maybe a widget isn’t appearing correctly, or you just need more information about the overall structure and logging statements aren’t doing you much good. Debugging complex UIs can be a pain.

We’ve had some real challenges at VMware, due to the complexity of our applications. It was enough to drive me mad one day, so rather than write more logging statements, I wrote Parasite.

Parasite is a debugging tool that David Trowbridge and I have been working on to give developers an interactive view of their entire application’s UI. It provides a number of really useful features, including:

  • See the entire widget hierarchy of your UI.
  • Watch properties update live.
  • Modify existing properties on a widget.
  • View all registered GtkActions.
  • Toggle GTK+’s debugging of graphic updates.
  • Inject custom code while the application is running.

Yes, you can inject new code into an application. With Python. Parasite runs in-process as a GTK+ module, so it has access to some internals of your application. We provide a Python shell equipped with PyGTK support for creating and modifying your UI on-the-fly, regardless of the language it was written in. Handy when you want to test out new concepts for a UI without writing new C code.

David has a nice screencast available showing some of what Parasite can do.

For more information on Parasite, including screenshots, a mailing list, and where to get the source code, see the Parasite homepage.

Review Board 1.0 alpha 1 released

Roughly two years ago, David Trowbridge and I began development of Review Board for use in our open source projects and our team at VMware. During that time, we’ve turned Review Board into a powerful code review tool that works with a variety of version control systems. Most of VMware has moved over to it, as have an estimated 50-100 companies world-wide. We’ve had over 100 contributors to the project, people providing volunteer support on the mailing list, and people have developed third party tools for integrating with Review Board.

After all this time in development, with this many people contributing, we decided it’s probably time to get a release out there. Sure, we could have done this a long time ago, but there’s a number of large things we were hoping to get in (a recently-committed UI rewrite, for instance). Now that we have most of the major features we want for our 1.0 release, we decided it was time for an alpha.

Over the coming months, we’ll be working on stabilizing the codebase, fixing a few large remaining usability quirks, enhancing performance, and writing some proper documentation (which is coming along nicely).

We’re eager to get a quality product out there and to begin development on the next release. There’s a lot of neat things planned:

  • Support for writing extensions to Review Board.
  • A fully-featured API covering every operation you’ll need to perform.
  • Some degree of policy support (specifying which users/groups can see which parts of a repository, for instance).
  • Reviews with statuses other than “Ship It”. This will probably be customizable to some degree.
  • Possibly some theme customization to allow Review Board to blend in better with corporate sites, Trac installs, etc.

Along with this, I plan to roll out a new website for the project that will have a browseable list of third party extensions, apps, Greasemonkey scripts, and more.

We have more information on our release on our release announcement.

Review Board: The Past 5 Months

It’s been about 5 months since I last gave a Review Board status update. Way too long, given how much has changed. So once again, let’s start off with a few stats.

  • Total bugs open: 25
  • Total bugs fixed: 186
  • Feature requests open: 43
  • Companies known to be using Review Board: at least 23

Review Board has matured in recent months and has a very nice feature set. More and more we’re seeing and hearing about companies using it in one or more teams. I was even lucky enough to talk about it in the official Django Book.

Development shows no sign of stalling. Our feature request list is a mile long, and our personal TODO lists are longer still. We’ve implemented so many new features and fixed so many bugs that I can’t even list them all, but let’s take a look at the highlights.

New Top-Level Features

  • iPhone support. Basic read-only iPhone support was added. It’s more of a proof of concept and to make sure our codebase handles different UIs on top of it, but if your Review Board server is accessible from your iPhone, point Safari to /iphone/ for some fun.
  • Status Reports. Basic support for status reports have been added. While we don’t have a fleshed out UI in place, the /reports/ URL will give you simple reports showing which review requests you’ve reviewed, and other bits of information. This can even be presented in Wiki format!

Revision Control Systems Integration

  • Mercurial support. One of our contributors has written support for doing review requests against Mercurial repositories. This supports local and remote repositories.
  • Git support. Basic Git support was written as well. It only works with local Git repositories (as it has to have access to .git directories).

Diff Viewer

  • Improved diff parser. We no longer require third party tools in order to parse diff files. We can do it ourselves faster and with greater flexibility. This has given us some speed advantages, reduced the hacks needed, and improved diff compatibility.
  • Interdiffs. Review Board can now display the differences between two revisions of a diff. This makes it much easier to review several iterations of large changes spanning many files.
  • Fixed diff line numbers. Line numbers in the diff viewer used to be artificial. They were essentially table row numbers. Now line numbers on the left-hand side of the diff viewer represent the actual line numbers in the original file, and line numbers on the right represent the new file.
  • “Review” link. Added a “Review” link on the diff viewer and screenshot page for bringing up the Review dialog. Previously users had to click a link on the diff viewer regardless of whether they were leaving a comment on the diff.


  • Show commented screenshots on reviews. Portions of a screenshot that the user has commented on will appear in the review body, much like diff fragments do. This greatly improves the review process when it comes to screenshots.
  • Updated diffs create a new draft. Newly updated diffs used to instantly appear and send out an e-mail, which was annoying if you realized you needed to change and re-upload the diff again. Now updating the diff just creates a draft, if one doesn’t already exist. The diff won’t show up or spam users until you’re ready for it to.
  • Auto-completion for reviewers. The reviewer lists now have support for auto-completion of group names and usernames. As you’re typing, a list of choices based on the current text will appear. Navigating with the arrow keys or hitting Tab will auto-complete the selected entry.
  • Default reviewers. Administrators can now specify default reviewers for file paths (as defined by a regular expression). This allows certain groups to “own” files or paths and to be included on the reviewers list any time a diff touching those is uploaded.
  • Improved page banners. The draft banner at the top of the review request page has been improved and is now more clear. No longer do you have to save a draft and then publish it. It’s now one single button on the banner. We also added “discarded” and “submitted” banners.
  • Alpha-numeric bug numbers. Not all bug trackers use numeric-only bug identifiers. We now support alpha-numeric bug numbers.

Dashboard and Review Request Lists

  • Starred review requests and groups. Users can now “star” a review request they wish to keep track of in their dashboard. They’ll be placed on the CC list and see changes in the dashboard. Users can also star a group in order to add it to their “Watched Groups” list in the dashboard.
  • Toggle display of submitted review requests. The “All Review Requests” page can now filter out submitted review requests via a toggleable “Show/Hide Review Requests” link.
  • Customizable columns. The various lists pages and the dashboard now support customizable columns. There are non-default columns that can be added to the view to show extra data, and existing columns can be removed. If you prefer all dates to be relative or absolute, just add the right columns. Furthermore, columns can be reordered simply by dragging them into the desired order.
  • New dashboard column types:
    • New Updates. This column shows a speech bubble icon when new discussions have taken place on a review request since the user last visited it.
    • Ship It. This column makes it easy to see if anybody has marked the review request as “Ship It!”
    • Absolute/relative timestamps. Users wishing to see only relative or absolute timestamps in the dashboard can add the Last Updated/Posted Absolute or Relative timestamp columns.
    • Number of Reviews. Sometimes it’s handy to see how many reviews have been made to a review request. This column provides that number.
    • Starred. Allows users to star/unstar a review request or group. This is like adding yourself to a CC list.


  • Upload diffs from a revision range. --revision-range has been added to allow for uploading diffs from a range of revisions on the server. This is currently only implemented for SVN.
  • Specify a default summary. --summary has been added to provide a default summary for the review request.
  • Open a browser after uploading. --open has been added to open a browser to the new review request.


  • make install. It’s now trivial to create a Review Board tarball or to install it on your system. We integrate with autoconf/automake to generate the Makefiles and sample/default configuration files. This brings us a giant step closer to putting out releases.

What’s Next?

We have several things in the works. A couple of the major highlights would be a search interface and support for 3rd party extensions to Review Board. Stay tuned!

Review Board Status Update

It’s been just over a month since the last Review Board status update. I thought this time I’d start off with a few stats.

  • Bugs open: 19
  • Bugs fixed: 97
  • Feature requests open: 27
  • Contributors: 10
  • Companies using Review Board: at least 13

If you’re part of an open source project or company using Review Board, we’d love to hear from you and your experience. We’d like to make a list of who’s using Review Board, so if you’re able to list your project/company, please let us know!

Now on to the feature updates.

  • Internet Explorer compatibility. Internet Explorer should now work properly with Review Board. A lot of work was recently done to make this happen and it hasn’t been as extensively tested as we’d like just yet, but things do appear to be working. Firefox is still the preferred (and targetted) browser, but do feel free to try IE and let us know if anything breaks.
  • CVS support. Review Board now supports CVS repositories. Right now there’s only :pserver support, though, but patches are welcome.
  • Improved post-review script. post-review, the script of choice for creating and updating review requests from the command line, now supports both Perforce and Subversion, with support for more systems on the way. A single post-review script can now handle a variety of repositories for different projects, and projects can be set up to point post-review to the right Review Board server.
  • Column sorting and list paging. Columns in the dashboard and review request lists can now be sorted by summary, submitter, posted time or last updated time. There’s also an improved pager at the bottom for skipping to other pages in the list.
  • Collapsed diff sections can now be expanded. The brown “n lines hidden” boxes in the diff viewer can be individually expanded without reloading the page by clicking a little “Expand” link on the box. This makes it easy to get more context when needed without expanding the entire diff and having to reload the page.
  • Cross-platform CRLF support. Diffs generated on Windows will now apply correctly on Review Board instances running on Linux, and vice-versa.
  • Improved diff loading times. Large diffs take a while to load, but we’ve improved this slightly by caching much of the resulting diff so that it doesn’t have to be regenerated again. More work is planned in this area to improve loading times, but it’s a lot more usable now.
  • More reliable database migration. The database migration scripts didn’t scale very well due to the existing Django libraries we were making use of being problematic for large database sizes. We’ve now fixed this, and they should be more reliable and hopefully a bit faster as well. There’s now a percentage complete indicator when loading back in.
  • Anonymous access to Review Board. It’s no longer necessary to have an account in order to view review requests and diffs. This is desirable for most open source projects. The old behavior of requiring an account for site-wide access can still be enabled, but is disabled by default.

In the works is a much improved diff parser that won’t require lsdiff on the server hosting Review Board. This should make things a little easier for people installing on Windows, and it also cleans up the code quite nicely. This should be in sometime this week.

Review Board

Reviewing code can suck

The open source world has given developers great tools to make their lives easier. We have editors, bug trackers, source code management tools, repository viewers. Bugzilla, for example, is a very popular bug tracker used by many open source projects and companies alike.

While the life of a developer has in many ways been improved by these tools, there’s one key area of software development that people still do the hard way: Code reviews.

You’re probably familiar with this. A contributor puts a patch up on Bugzilla, Trac, or your project’s listserv. It’s large and spans several files. Eventually you get around to it (if you haven’t lost it in your inbox yet). You open an e-mail or the Bugzilla page to respond, put the diff where you can see it, and start going through the changes, line by line, making comments as you go. It’s tedious. You have to make it clear what function you’re talking about, make references to the general area in the diff. It’s a pain for the contributor too, because they have to figure out what you’re referring to. This leaves room for error.

We’ve been working this way for years in open source projects and at VMware. Code reviews are important to us, and help to keep our code clean and our products stable. It keeps us honest prevents us from cutting corners unnecessarily. However, the process is a bit time-consuming and not at all optimal.

  1. Generate an htmldiff showing the old code and the new code side-by-side, highlighting the changes.
  2. Write an e-mail to the target reviewers/listservs explaining what changes we made, the testing that was done, links to screenshots we put up on a file server, a link to the diff, and whatever else.
  3. Wait for someone to go through the htmldiff and comment on the changes in a new e-mail.
  4. Go through the comments, try to find the lines they referred to in the diff, and fix them up.
  5. Make another diff if necessary, repeat.

David Trowbridge and I finally got tired of it. We spent too long preparing review requests and we lost too many of them in our e-mail. As our personal projects and our team grew in size, it became harder to keep track of all the open review request e-mails on the listservs. So we fixed that.

Review Board

We built a code review system called Review Board. Like most projects, it started out simple, but grew to be pretty powerful and useful quickly. It was designed to automate and simplify the process of creating review requests and actually reviewing code.

Management at VMware was excited about this from the beginning. We weren’t being asked to write it, and it was a personal project and all, but when they found out we were doing this, they fully supported us. It didn’t take long for the excitement to spread across many teams, and we had 40 people signed up and playing before we were even ready to announce our phase 1 beta.

One of the things we decided from the beginning is that this must be open source and it must work with other version control systems. For example, we use Perforce internally, but there’s no reason not to include Subversion or anything else.

So we worked and worked in our spare time. After weeks of trial runs and lots of dogfooding, we decided it was time to announce what we had so far.

Enough yapping, details already!

Details? Alright.

Review Board is an open source program licensed under the MIT license. It was designed using Python and Django. It’s compatible with Subversion and Perforce, and can be extended to support other version control systems.

Review Board has a lot of useful features…

Multiple Repositories and Projects

Review Board can generate and display diffs against multiple repositories on multiple servers, each with their own version control system. At VMware, we have a repository for each Perforce server we use, and will soon be adding a Subversion repository for our libview project.

This would be particularly useful for umbrella projects where some parts are available in one repository and others in other repositories.

Writing version control system backends is easy. They’re simple Python modules that can be referenced in the Review Board database entry for the particular backend. We currently ship Subversion and Perforce backends, as well as a subclass of the Perforce backend making use of special extensions we use at VMware.

Review Requests

Posting review requests is fairly easy. If you use Perforce, it’s especially easy. A post-review tool is provided that allows you to post a review request with nothing other than a change number as a parameter.

If you use Subversion, a little more work is required, though we’re working on a tool to automate this as well. You’ll need to generate a unified diff. Click “New Review Request,” select the repository, enter the base path (the path relative to the root of your Subversion repository where you generated the diff), and then select the diff. Click “Create Review Request.”

You’ll be taken to your review request page where you can fill in description and other information. Click “Publish” when you’re done.

Review Request

Powerful Diff Viewer

Diff Viewer
  • Inline commenting: Instead of jumping to your bug tracker or e-mail client and describing where you’re commenting on, just comment directly on the line! Click the line number or click and drag to select multiple line numbers and a comment dialog will pop up allowing you to type. When you finally publish your review, the lines in the diff you commented on will be shown inline with the rest of your review.
  • Inter-line diffs: Sometimes a small change is made to a line and it’s not readily apparent what the change was. In these cases, we highlight the regions between two lines that have changed.
  • Revisioned Diffs: Each revision of the diff is saved and can be accessed. In the future, we will make it possible to show differences between two revisions, to ease review of incremental patches.
  • Whitespace highlighting: Trailing whitespace is automatically highlighted. Trailing whitespace is a pet peeve of many developers and this helps to catch it early.
  • Collapsing/expanding of files: By default, only the changed chunks and some lines of context around them are displayed. This can be quickly changed to show the entire file, in case there’s something you want to look at or comment on elsewhere.
  • Keyboard shortcuts: Convenient shortcut keys allow quick navigation around the diff. For example, pressing “n” will jump to the next changed chunk, and pressing “p” will jump to the previous chunk. This will be further improved and documented soon.

Comment Dialog

Interactive Screenshots

  • Screenshots can be easily added to the review request page, and will show up as thumbnails.
  • Screenshots can be commented on by clicking and dragging an area on the image. A comment box will pop up, like in the diff viewer. While the clipped part of the screenshot does not yet appear on the review, it will soon.

Contextual Discussions

Review Discussions

  • Commented lines in the diff are displayed with their comments on the review page.
  • Commented areas of a screenshot will be displayed with their comments on the review page.
  • Discussion of reviews take place on the reviews themselves, making it possible to read the whole discussion of a change from top to bottom.

E-mail Support

All discussions and updates get sent automatically to the individual reviewers and listservs. This makes it easy for people to see any and all changes. This is configurable and can be disabled if it doesn’t fit in with your setup.

NIS Support

Review Board can use an NIS server as an authentication backend, making it easy to integrate into companies that use NIS. Everyone’s accounts will Just Work in Review Board without any registration required.

User Dashboard


All incoming and outgoing reviews can be seen on the Dashboard page. You can look at incoming reviews sent directly to you, sent to a group, or to either (all incoming reviews).

In the future, this will show more information on what’s going on with the review requests in your list. Recent discussions and updates will be shown, making it easier to keep track of things.


Review Board has a JSON-based API for accessing nearly every aspect of the system. This makes it easy to build tools around Review Board. Our post-review tool uses this, as does much of the web UI.

Hopefully in time, developers will make use of this to better integrate with existing systems such as Eclipse, vim, emacs, or other IDEs.

Looking Forward

There’s a lot we have planned. Review Board is still just an early beta and a lot will happen.

  • Improved tools: We’ll soon be working on a single tool that understands how to post review requests to both Perforce and Subversion. It will also be able to integrate with multiple projects. For example, if three projects you’re contributing to all use Review Board, post-review will ask once for the Review Board servers and use them from then on when run in the project directories.
  • Interdiffs: We plan to include the ability to show changes between revisions of diffs, aiding in reviewing incremental changes to patches.
  • Statistics: Information will be available showing how many review requests, reviews, and comments have been made between specified time periods, complete with fancy graphs. We’re working on ideas for what can be displayed here.
  • Status Reports: This is perhaps more useful inside companies. At VMware, we’re supposed to submit weekly status reports discussing what we’ve done. Often this consists mostly of review requests made and bugs fixed. Review Board will be offering a page showing this information in several forms so that it can be easily copied and pasted into a weekly status report.
  • Integrated Help: To simplify usage for first-time users, we’d like to add help information to all pages explaining simply how to use the interface.
  • “Effective Lines” Display Many diffs are easier to review than they seem, as there could be hundreds of lines with nothing more than a function or variable name change. We would like to make this clear before even opening the diff by showing the number of effective lines changed, factoring out the simple redundant changes.

Wrapping Up, and Contributing

This was a bit long, but I hope it gave a good overview of what we’re putting together here. You can see it in action or visit the project page. If you decide to use it in your project, please let us know! Check the Wiki for install instructions.

Hopefully this will become useful to others as well. We’ll post periodic updates as this project progresses.

New libnotify and notification-daemon releases are out!

I’ve just put out libnotify 0.4.4 and notification-daemon 0.3.7 releases. I highly advise that everybody upgrades, as several memory leaks, rendering glitches and other bugs have been fixed.

Along with these releases is some basic support for accessibility in the notifications and a nice, subtle transparent effect on the notifications when running on a system using a compositing manager. Don’t worry, it’s not bad at all, and it doesn’t make the notifications any harder to read. I’ve been running this for some time at this point 🙂 I would show a screenshot, but it’s probably best to see it on your own setup.

The downloads are available on the downloads page, and full release notes are below:

libnotify 0.4.4 changes

  • Fixed a bug where a notification’s ID could be reset when a different notification was closed. Patch by jylefort. (Bug #94)
  • Fixed a crash when the D-BUS proxy was not being freed on notify_uninit, which was problematic when used in a loadable module. (Bug #92)
  • Fixed a crash when a signal handler for the notification’s closed signal caused the notification to be destroyed. (Bug #116)
  • Fixed memory leaks when creating notifications. (Bug #112)
  • Fixed potential memory leaks where the function passed to notify_notification_add_action to free the user data was not being called. (Bug #119)

notification-daemon 0.3.7 changes

  • Fixed a compatibility issue with dbus-glib 0.72. Patch by Pawel Worach. (Bug #95)
  • The background of the window in the standard theme is now just slightly transparent when compiled against GTK+ 2.10 and when using a composite manager. Patch by Matt Walton. (Ticket #110)
  • Fix several rendering glitches with the borders in the standard theme.
  • Fix a memory leak when removing a notification. Patch by Sven Wegener. (Bug #105).
  • Added initial accessibility support with the standard theme engine.
  • Clicking anywhere in a notification should now close the notification. This was happening only on the body text sometimes.