Matthew Barnes

Evolution is 100% GConf-free!

Fri, 15 Jun 2012 20:30:19 GMT

We're a little late to the party but we made it nonetheless!

Big thanks to Rodrigo Moya for getting the bulk of the work done in Evolution 3.4, and to Milan Crha for finishing the remaining pieces in time for Evolution 3.5.3. I chipped in on a few GConf keys as well, but made a bigger mess of things.

Updates from the Evolution/WebKit front

Tue, 05 Jun 2012 01:25:34 GMT

The newest member of the Evolution Team at Red Hat, Dan Vrátil, has been making exciting progress in transitioning Evolution from our aging HTML renderer, GtkHTML, to the more modern and full-featured WebKit/GTK+. He's still trying to get his blog added to Planet GNOME so I wanted to highlight a couple of his recent posts:

Evolution meets WebKit

Evolution gets a new e-mail formatter

You can already try out the new WebKit integration in Evolution 3.5.

It currently uses WebKit/GTK+ to render received emails for display and printing, but not yet to compose emails for sending. That's a whole nother barrel of monkeys. But that's next on Dan's list, and then we can finally retire GtkHTML!

Major Evolution-Data-Server API breaks about to land

Thu, 31 May 2012 22:00:07 GMT

I mentioned in my previous blog post a few months ago that I've been overhauling Evolution-Data-Server's account format and APIs. I've been doing all this work on a very long-running branch (18 months old now!) which was not ready in time for GNOME 3.4. But it's ready now, and I'll be merging it this weekend just after the Evolution 3.5.2 tarballs are released.

I'm announcing this to a wide audience because the API breaks are going to affect a number of other projects in the GNOME community and perhaps beyond. I already have patches prepared for several key GNOME components, and I stand ready to assist any other projects which will need to port their code to the new Evolution-Data-Server APIs. Please contact me if you maintain one of these projects so I can help make the transition as smooth as possible. (mbarnes@redhat.com or #evolution on IRC).

In short, Evolution-Data-Server will migrate account data from the XML blobs we've historically stuffed into GConf to plain text files which live under the XDG-compliant $XDG_CONFIG_HOME directory. Evolution-Data-Server will also introduce a new D-Bus service to serve these account files to client programs and to take over certain account management responsibilities so that Evolution-Data-Server becomes more of an autonomous desktop service that does not rely so heavily on Evolution.

I've written a fair amount of documentation, so just to get the links out of the way...

Immediate benefits to users and to GNOME are:

Much easier to backup account data or copy it to other machines. Having account data locked in a configuration database makes this pretty painful at present. This has been an ongoing problem for at least as long as I've been involved with Evolution (circa 2006). Evolution-Data-Server will monitor the user directory containing the account files, which means restoring an account is simply a matter of dropping files into that folder. Evolution-Data-Server will notice the new files and (assuming they're valid) activate them immediately without having to restart any programs.

The new D-Bus service will centralize interactive authentication prompts. This means client programs will no longer have to deal with authentication at all. Internally, the new D-Bus service will use GcrSystemPrompt to show a system-modal password prompt whenever a mail, calendar or address book backend needs to authenticate and a password is not readily available. In a GNOME Shell session, GNOME Shell will take over and display a dialog window consistent with the shell's overall look and feel.

The new D-Bus service will monitor GNOME Online Accounts and automatically add or delete equivalent Evolution-Data-Server accounts. Previously Evolution handled this, which unfortunately meant Evolution had to be already running or at least started for new Google accounts to be noticed and propagated to services like the GNOME Shell calendar. That issue is now solved.

As part of this effort I've also converted Evolution-EWS to the new Evolution-Data-Server APIs and have added support for GNOME Online Accounts' new Exchange option. This is a major feature for GNOME 3.6.

The new account management system also opens the door to all kinds of cool new enhancements to Evolution and Evolution-Data-Server. I have lots of ideas and could easily spend another year chasing them all, but the order of the day is to get this branch finally merged so we can shake out the bugs and help other projects adapt in time for GNOME 3.6.

Coming Soon in Evolution 3.4

Sun, 09 Oct 2011 15:03:12 GMT

I’m overdue for an update on what the Evolution team has been up to lately. This development cycle should be interesting, as we have several projects converging for the next major release in March: Evolution 3.4. It’s still pretty early in the 3.3 cycle, so everything is still tentative at this point. But here’s some of the major features we have cooking, in addition to our steady stream of bug fixes and incremental enhancements.

New D-Bus Service for Email

Srinivasa Ragavan is working toward breaking email handling out of Evolution and moving it out to a separate D-Bus service as we do currently for address books and calendars. That will allow for things like new mail notifications without having to have Evolution running, and also provide a more formal way for other Evolution-Data-Server clients to access mail stores.

Evolution, Meet WebKit

Dan Vratil has taken on the task of porting Evolution’s email rendering from our old and outdated HTML engine (“GtkHtml”) to the more modern WebKit/GTK+. Dan tells me he’s taking advantage of WebKit’s full support for JavaScript and CSS (which GtkHtml lacks) to make rendering more efficient and to unify the email, contact, task, and memo previews with a shared style.

We’re treating email rendering and email composing as separate projects. Right now it’s looking like we’ll continue using GtkHtml for email composing in Evolution 3.4, but fear not -- we’ll get to it. We’re as eager to drop GtkHtml as anyone.

Automated Account Setup

Punit Jain is merging the automated mail account setup feature from “express” mode into the regular Evolution Account Assistant. This is the feature where you give Evolution your email address and it checks the address’s domain against a database of known service providers and can often populate all the server details for you, making account setup quick and easy.

Goodbye GConf

Rodrigo Moya has been porting all of Evolution’s simple GConf keys to dconf and fixing up our code to access the new keys via GLib’s own GSettings API. So one less package dependency for Evolution 3.4. As for the not-so-simple GConf keys, see below.

New Backend for Microsoft Exchange

David Woodhouse and his team at Intel, along with Chenthill Palanisamy at Novell, have developed a new Evolution backend that can talk to Microsoft Exchange 2007 and 2010 by way of Microsoft‘s “Exchange Web Services”, a publicly documented SOAP-based API.

The new backend package is called “evolution-ews”.

In order to avoid all the craziness of the GNOME 2-to-3 transition, the backend was originally developed exclusively for Evolution 2.32. Chenthill has been busy porting it forward to 3.2 so it can start syncing up with GNOME’s regular release schedule.

Hopefully Microsoft will stick to its Web Services interface for a good long while so we can stop having to write new Exchange backends every few years. :)

New Backend for Kolab Groupware

Christian Hilberg and his team at kernel concepts and tarent GmbH have developed a brand new Evolution backend for Kolab Groupware servers.

The new backend package is called “evolution-kolab”.

As with “evolution-ews”, the initial development was targeted at a fixed and now older version of Evolution, and Christian is ready to begin forward porting it and eventually syncing up with GNOME’s regular release schedule.

Saner Account Storage

As for me, I’ve been toiling away for most the year on those not-so-simple GConf keys I mentioned earlier -- the ones that we stuff account information into in the form of XML blobs.

Evolution’s account storage will soon move to plain text files in a simpler .ini-style syntax. Account data will be easier to read, easier to edit, easier to back up, easier to copy to other systems.

We’ll also introduce another new D-Bus service to manage these account files and also centralize some account-related background jobs that Evolution currently handles (but shouldn’t) such as GNOME Online Accounts monitoring.

I could ramble on about this but I’ll save it for a separate blog post.

As you can see, quite a lot going on at once. Any questions, feel free to email me, or email Evolution’s development mailing list, or jump on Evolution’s IRC channel: #evolution on GIMPNet (irc.gimp.org).

Evolution is rocking on Windows

Tue, 25 May 2010 16:37:15 GMT

Fridrich Štrba has been doing an awesome job of integrating the latest Evolution release on Windows. We have a new Windows installer!

Since he's not on Planet GNOME, I'm acting as his proxy. Check out his latest blog post for details and lots of pretty screenshots.

A handy sidebar trick in Evolution

Fri, 05 Mar 2010 18:59:12 GMT

In Evolution, you can display multiple calendars, task lists or memo lists at once by check marking their names in the sidebar. I'm not a heavy calendar or memo list user myself, but I do practice the Getting Things Done methodology with Evolution's task lists. Here's my current set of lists:

Earlier today, Nick Jenkins filed a bug complaining about how cumbersome it is to just focus on one list (or calendar). And he's right. You basically have two choices: 1) go through the sidebar and manually un-check everything you don't want to see, which is ridiculously cumbersome, or 2) right-click on the item you do want to see and select "Show Only This whatever" from the pop-up menu, which check marks that item and clears all others.

Handy, right? Well, not so much if you use it frequently enough. Nick was asking for an easier way, so I suggested we make triple-clicking on a sidebar item a shortcut for the "show only" menu item. (Triple instead of double-click so it's not so easy to trigger by accident.)

Took about a half hour to hack together and I have to say I'm startled at how much easier this simple enhancement allows me to manage my task lists! I like it enough that I snuck it in at the last minute for Evolution 2.30.

Using GStreamer to sample arcade music

Mon, 15 Feb 2010 03:03:36 GMT

Recently I discovered the online Arcade History database has added music samples for some games. For example, they now have music for the mid-80's racing game Out Run.

I thought it would be cool to integrate that into my MAME front-end, GNOME Video Arcade, and wound up blowing the whole weekend on it. I'm happy to say it's finished already, and works great!

My foray into basic GStreamer programming was suprisingly pleasant. The API is nicely designed and well-documented, and simple use cases like mine are made easy. The "playbin" plugin pretty much did all the work. I just fed it Arcade History URIs and wired up a simple user interface to follow state transitions from the audio stream.

GStreamer is an example of the kind of high-quality software engineering that I strive to emulate in my own work.

Evolution is 100% Bonobo-free!

Sat, 19 Sep 2009 00:55:04 GMT

A couple years ago I wasn't sure I'd ever see the day, but today I'm delighted to announce that Evolution has finally dropped not only its Bonobo dependency but also its libgnome and libgnomeui dependencies (see for yourself)! This will debut as 2.29.1.

Quick recap of recent events:

We created our gnome-2-28 branch earlier than usual to get a head start on Evolution 2.29 development.
We merged the kill-bonobo branch that I talked about awhile back.
We ported the address book side of Evolution-Data-Server from Bonobo to D-Bus, and are currently finishing up the calendar side.
We are tracking both Evolution regressions and Evolution-Data-Server regressions. If you're the bleeding-edge / early-adopter type please help us test the new code and report any more regressions!
Bonobo-free Evolution packages for Fedora 12 are available from my Fedora People page. The package versions are relabeled as 2.27.99 for easier integration with Fedora 12 but it's actually the 2.29 code in disguise.

Next project for me is to get Evolution-Exchange back on its feet. With Bonobo gone the poor thing is all confused now and refuses to build.

Still a Kid at Age 33

Mon, 27 Jul 2009 01:33:01 GMT

As a child of the 80's I was just old enough to get swept up in the craze of what has come to be known as the golden age of arcade games. I have fond memories of pouring my weekly allowance into those old coin-operated machines at our local grocery store, mall, laundromat, bowling alley... practically every place I went had at least one or two. I credit my fascination with those games for getting me started with computers and programming at an early age. For me, the nostalgia has never really worn off.

For my 33rd birthday this weekend, Candace and I made our annual pilgrimage to Funspot Family Fun Center in Weirs Beach, New Hampshire. Funspot is home of the largest video arcade in the world. If you're at all a fan of classic video games and you live in or are visiting New England, you really must see this place. While sporting the usual fare for these "fun center" type places, the real treasure is up on the third level (yeah, it's that big), away from the mainstream crowds, where you'll find the The American Classic Arcade Museum. The museum holds over 250 video game and pinball machines of yesteryear, and is where much of the hilarious yet highly engrossing documentary The King of Kong was filmed.

Suffice it to say I had a blast. Set the day's high score on a number of machines, including a 263,000 point game of Donkey Kong. Also had to play a few rounds on their famous Pac-Man machine, but I swear I was better at that game when I was eight. Can't wait to go back.

Fedora Packages for Kill-Bonobo

Sat, 20 Jun 2009 23:08:55 GMT

Fedora 12 ("Rawhide") packages for Evolution's kill-bonobo branch are now available. Install this repo file to get updates through yum. The branch is currently synced with Evolution 2.27.3.

As stated previously, not everything is functional yet. Please file bugs for the parts that are. I'll try to post updates at least weekly.

Evolution Will Soon Bid Farewell to Bonobo

Wed, 17 Jun 2009 13:09:10 GMT

This is a combination announcement, history lesson, status report and call for help.

For nearly a year I've been laboring over an Evolution branch named kill-bonobo, whose goal is exactly that: eradicate Bonobo from Evolution once and for all. According to the GNOME release schedule, I'm due for a status report. (Note, this only pertains to the application itself. The data server is already being ported from Bonobo to D-Bus by Ross Burton. The two projects are independent.)

The kill-bonobo branch is strictly an internal cleanup effort, albeit a massive one. It's not about adding features or radically changing the end-user experience. It's about making Evolution easier to maintain and enhance as we enter into the GNOME 3 era. So if I've done a good job, users will hardly notice any difference when the branch is finally merged.

Those who are interested in testing the branch can skip to the "How to Help" section.

Why We Need It

I was not present for the early evolution of Evolution, so this account is based on historical research and discussions with some of the old-timers. Hopefully they won't clobber me for getting the details wrong, or for calling them old-timers.

Evolution's original design consisted of a simple skeletal "shell" which served as the framework for out-of-process Bonobo components. Each component managed different types of information: one for email, one for calendar events, one for contacts, etc. The components talked amongst themselves via CORBA, which handled all the IPC. Ettore Perazzoli, in his paper for the 2001 Ottawa Linux Symposium, wrote:

It is interesting to note that the various pieces of Evolution are currently out-of-process components, and that CORBA deals with the inter-process communication nicely and transparently; it would be possible to turn these components into shared libraries without any substantial changes to the code.

And that's exactly what happened. The components were turned into shared libraries sometime later to help address some design issues and to make the application more debuggable. Evolution then became — and has remained — one monolithic process. Most of its functionality is still supplied by in-process Bonobo components loaded at run-time. Bonobo was kept around in part for the menu merging capabilities of libbonoboui, but also because it was already very deeply ingrained in the application by then. To this day, Bonobo still handles all the inter-component communication, even though it's all one process.

Fast forward to present day. Bonobo has fallen out of favor with the rest of the GNOME community and its libraries are now deprecated (or planned to be deprecated — the distinction is unclear). GTK+ has gained a menu merging capability in GtkUIManager, GObject has gained a module loading system in GTypeModule, and developers are scrambling to migrate code away from deprecated libraries and API in preparation for GNOME 3.

Moreover, the inability of Evolution components to interact directly with the central shell continues to be a major design impediment. Certain bugs cannot be fixed and enhancements cannot be implemented with Bonobo in the way. Even something as simple as setting the proper relationship between a dialog window and the main application window can't be done under the current design without breaking the component/shell abstraction.

In short, Bonobo's time has passed and it needs to get gone.

What's Finished

A New Shell

I have rewritten Evolution's shell from scratch. While still adhering to the original design principles, it now loads components (I'm calling them "shell backends" just to get away from the CORBA nomenclature) at startup via GTypeModule. Each main shell window provides a central GtkUIManager instance for shell backends to merge and un-merge their menus and tool bars. The new shell provides a bunch of other convenient services that it didn't, or couldn't, before. The API is now mostly stable, and it's documented! (A trend I hope to continue.)

The shell itself is a subclass of UniqueApp from libunique, so Evolution is still a single instance application. In fact, that feature has improved. Starting a second Evolution instance with no command-line options will now raise and focus the current window instead of opening a new one; a behavior greatly preferred by users. Also, Evolution will now terminate when it's finished handling a command-line URI and there are no other Evolution windows running.

Infrastructure

Beyond the shell, it's mostly been a matter of slogging through the rest of the code and adapting it to the new shell API and the more modern GTK+ APIs. Turns out, Evolution has a lot of code, and a lot of infrastructure that piggybacks on Bonobo. Needless to say, that's why it's taking so long.

All of the menus and tool bars, and many of the stand-alone buttons and combo boxes, are now proxy widgets for GtkActions. EMenu and EPopup — the mechanisms that allow plugins to extend menus — are being phased out in favor of EPluginUI, which works with GtkUIManager. In fact, many of the plugins themselves are being phased out — their features being properly integrated into the application.

Asynchronous activity tracking — that's those percent-complete and error messages in the status bar — is now more object-oriented. The shell even lends a hand in routing and tracking these activities. I have a number of ideas for leveraging this new framework. Eventually I'd like to eliminate pop-up error dialogs altogether in favor of something less obnoxious, such as "inline" alert messages similar to those in Firefox, gedit, Sound Juicer and Evince. Also, better shutdown management — where Evolution tells you what network activities are keeping it from shutting down and allows you to cancel them.

Just getting the thing to build was another challenge. What I assume was once a nice layered design with clean separation of concerns has grown into a tangled mess of circular dependencies. I've managed to resolve most of the linking issues by shuffling source code around and routing application-wide events through the shell. But there's still the issue of library modules linking to library modules (plugins linking to shell backends and shell backends linking to one another), which is not portable and in fact prevents Evolution from building on Mac OS X.

Shell Backends

The contact, memo and task backends are done, and I'm currently wrapping up some loose ends on the mailer. All are usable and ready for testing. I personally have been using the kill-bonobo branch for daily email and task management since February.

Calendars, however, are another story. See below.

What's Unfinished

The branch is about 75% complete. It's usable, but there's still significant work to be done.

The Calendar

The calendar is half-finished and is not yet usable. This is the last major piece left.

I was attempting to split up the massive GnomeCalendar class into smaller, more manageable pieces. But I got burnt out and had to set it aside for awhile, and then never got back to it. At this point I'm in favor of just getting it working as quickly as possible. I can take another shot at refactoring it later when I'm feeling masochistic again.

Plugins

Many of the plugins still have to be adapted to EPluginUI and the new shell. This is a highly parallelizable area where I could use some help from volunteers. The working and non-working plugins are listed in "configure.ac" (search for PLUGINS NOT BUILDING YET).

Evolution Exchange

Evolution Exchange (formerly the "Ximian Connector for Microsoft Exchange Server") presents an interesting problem. The evolution-exchange-storage process is the last out-of-process Bonobo component that talks to the shell. Ximian originally released this software under a non-free license, and used the split process design to bypass the linking restrictions imposed by the GPL. Later, after Ximian was acquired by Novell, it was released under an open-source license. But the design remained unchanged, even after Evolution was collapsed into a single process application.

I'm uncertain of what to do with this. To me, the best solution would be to convert the storage process to shared library modules for the Evolution and Evolution Data Server processes. But that could take some doing, and time is short. Plus, Evolution Exchange is being phased out by Evolution MAPI anyway. Another option is to hack together a quick and dirty D-Bus API for the shell, which the storage process can use. But I'm hesitant to expose a poorly thought out D-Bus API just for a corner case.

Third-Party Extensions

Third-party extensions such as evolution-rss, evolution-brutus, and evolution-jescs will likely require some re-design. I will lend a hand here as much as possible.

How to Help

The best way to help right now is to test drive the kill-bonobo branch and file Evolution bug reports at http://bugzilla.gnome.org/. Since this is an unofficial branch I have my own little system for tracking reports in Bugzilla. But really, if you do file a bug just mention that you're running the kill-bonobo branch and I'll take care of the rest.

Existing bugs that the branch may be able to address are tagged with evolution[kill-bonobo] in the Status Whiteboard field. (Bug List)

Existing bugs that the branch has successfully addressed are tagged with evolution[kill-bonobo] in the Status Whiteboard field and the Summary field prefixed with [KB-Fixed]. (Bug List)

Regressions that the branch has introduced get tagged with evolution[kill-bonobo] in the Status Whiteboard field and the Summary field prefixed with [regression]. These are what I'm looking for. (Bug List)

Evolution developers and contributors looking to hack on stuff could start by picking a non-working plugin and getting it back on its feet (see the previous section). That would probably acquaint you with the new shell API, and possibly expose bugs or shortcomings in the design. Catch me on GimpNet (channel #evolution) if you're interested in this.

For Fedora users, I will attempt to publish a kill-bonobo RPM repository for Fedora 12 / Rawhide in the near future. Stay tuned.

Credits

Finally, I have to give props to my employer for humoring me through this ordeal, especially since I've consistently underestimated the workload. While the work has been largely exploratory and at times overwhelming, in the end it's been highly educational and satisfying.

Evolution Attachment Rewrite

Wed, 15 Apr 2009 16:56:58 GMT

Today I finished a rewrite of Evolution's attachment handling code. What was supposed to be a short detour from a much larger ongoing project (more on that later) ballooned into a month-long overhaul. I had already sketched out plans for a rewrite a year ago. This was just preparation meeting opportunity.

The goals of the rewrite were primarily internal code cleanup, but there's some UI bling too:

Attachment handling code is currently scattered throughout Evolution, with lots of duplication. The rewrite collects everything in one place.

Migrate from GnomeIconList (deprecated) to GtkIconView, with a custom GtkTreeModel specifically for attachments. And throw in a GtkTreeView option just for kicks.

Better utilize GIO for file operations, thumbnails, emblems, etc. Abstract away the distinction between local and remote files. Stop using threads, and make sure all blocking calls are asynchronous.

Migrate the attachment popup menus to GtkUIManager.

Kill off a couple frivolous attachment-related plugins and support the functionality directly. We ship way too many plugins as it is and I'm gradually killing off the silly ones.

Make the whole thing extensible, to help resolve some cyclic dependencies within the application. The mailer now handles the mail-related parts, the calendar handles the calendar-related parts, and so on.

Here's a few screenshots. The first two show off the new icon and list views when composing email, and demonstrate simultaneously loading from or saving to remote stores (I used some big audio files here for better illustration of the progress bars). Both file operations are cancellable. The third screenshot shows off the attachment UI for received emails.

GNOME Video Arcade has moved to GitHub

Fri, 27 Feb 2009 03:45:28 GMT

To better acquaint myself with the way of the future, I've moved my GNOME Video Arcade project from SourceForge to GitHub, and also set up a horribly amateurish website for it.

GNOME Video Arcade is a simple MAME frontend written to suit my own aesthetic taste better than other UNIX-based frontends, most of which I find too clunky and cluttered. And it's something to hack on when I'm burnt out from my real job.

ExoBinding and Settings Management

Mon, 17 Nov 2008 18:41:56 GMT

Over the weekend I learned about Xfce's excellent ExoBinding extension for GObject properties, a feature I've been wishing for for quite a long time. It allows you to bind two object properties together, with optional transformation functions, so their values automatically stay in sync.

A simple use case is desensitizing a portion of a dialog when a check button is inactive. With ExoBinding, you can do this by simply binding the GtkCheckButton's "active" property to a GtkContainer's "sensitive" property, both of which are boolean values. Done. No callbacks, no manually setting widget sensitivity, just one call to exo_binding_new(). I like to think of it as wiring objects together.

So I had an idea.

Last year I learned of and raved about a little utility library named GConfBridge, which binds GObject properties to GConf keys and automatically keeps them in sync. Combining these features seemed like a pretty powerful way to implement a user preferences dialog, but then there's the problem of providing access to these settings to the rest of the application. In Evolution, at least, the settings values are kind of scattered all over the place. Centralization seems like the right way to go.

Again looking for existing solutions, I took a closer look at GtkSettings which, if I understand it correctly (the documentation is a bit sparse), allows widgets to install their own configuration settings that desktop themes can tweak. GtkSettings centralizes these settings and exposes them as GObject properties.

Perfect. Now we're on to something.

I wrote a simplified version of GtkSettings which dumps the parser but keeps the property registration, and added it to an Evolution branch I'm working on. This singleton object serves as a repository for application settings, accessible via GObject properties, complete with "notify" signal emissions when a settings value changes.

Then, for each application setting, I register a new property with the GtkSettings-like singleton, bind that property to the appropriate GConf key using GConfBridge, bind it again to the appropriate widgets in the preferences window using ExoBinding, and (ideally) bind it yet again to some object property deep in the application where the setting will take effect.

I prototyped all this last night with some of Evolution's settings and, I'll be darned, it seems like a viable approach. Just a bit of wiring during initialization and that's that.

All this magic mimics much of what dconf and GSettings promise to make easier, and taking advantage of GConfBridge and ExoBinding now might help set the stage for a smoother transition to GSettings when the time comes.

In the meantime, I'm rooting for this bug to get some attention.

GObject-based Camel

Sun, 09 Nov 2008 18:24:30 GMT

Over the weekend I hit a milestone with a science experiment I started earlier in the year to turn Camel into a GObject-based library with minimal API breakage. The short-term goal of this effort is to make it easier to generate language and D-Bus bindings for Camel.

I now have running code which I've posted to a new evolution-data-server branch called "camel-gobject". The branch contains a couple very small patches (evolution.patch and evolution-exchange.patch) that must be applied before building Evolution against the GObject-based Camel library.

Evolution seems to be working just fine with my standard setup, but I haven't tested all the built-in Camel providers and various third-party extensions. If others want to chip in with the testing I'd be grateful.

Techie Details

My approach was basically to pull off the same stunt that was done to GtkObject when GObject was introduced: turn the base CamelObject class into a GObject subclass, and convert the CamelObject API into a set of thin wrappers for equivalent operations in GObject. For example:

camel_object_ref() now calls g_object_ref()
camel_object_unref() now calls g_object_unref()
camel_type_register() now calls g_type_register_static()

...etc...

Obviously this breaks Camel's ABI. There's no way around that.

The (intentional) API breakage is very minimal:

CamelType is now an alias for GType. It is no longer a pointer to the class structure. That was supposed to be an implementation detail anyway, but Camel (and Evo, and Evo-Exchange) exploits that in a number of places. The class structure can be properly accessed using camel_type_get_global_classfuncs(), which is now an alias for g_type_class_peek().

The corollary to that is when to fetch the parent class structure. Most classes define a static "parent_class" pointer for chaining up in class methods. The "parent_class" pointer should be set in the class initialization function, NOT before the type registration in get_type(). Just like you would in normal GObject code. There were LOTS of places in Camel were that needed fixing.

Camel interfaces are dead, but they were never really used anyway.

The other half of the problem was CamelObjectBag. It formerly shared a mutex with CamelObject's reference counting, I think because CamelObject ref's and unref's were non-atomic. GObject's reference counting is atomic, so with that issue out of the way I gave each CamelObjectBag its own mutex, cleaned up the code a bit, and split it off into a separate source file (camel-object-bag.c). After an evening's worth of debugging it seems to be working fine now.

Now What?

So with the "interesting" part now done, next comes the long and tedious part: rewriting all the internal CamelObject boilerplate into GObject boilerplate and making sure we're not using any newly deprecated API. But that can be done gradually and with help from others.

In time I'd also like to explore taking greater advantage of GObject signals and properties in Camel, and also deprecating CamelArgV and CamelArgGetV.

I haven't discussed this with the other Evolution/Camel developers yet, so there are currently no plans to include it in 2.26. That may change, but for now it remains purely experimental.

GNOME Video Arcade 0.5.2

Wed, 07 Nov 2007 02:27:47 GMT

Has this happened to you? You upgrade to the latest and greatest MAME release and suddenly a bunch of your favorite games stop working. Now I do understand that the MAME project is primarily concerned with documenting the ins and outs of old video game hardware, and the fact that you can actually play the games is a mere side-effect of the process. But you also can't ignore the fact that a rather large community has grown up around this "side-effect" over the past decade. Yet almost every MAME release continues to break ROM sets and (especially) front-ends without warning. I think the MAME developers could do a better job of alerting the community about changes that break backward compatibility. Expecting users to sift through change logs and individual developer blogs to learn what broke just doesn't cut it.

Until now GNOME Video Arcade has also been guilty of not alerting users about games that have broken due to a MAME upgrade. But as of version 0.5.2, this is no longer true.

This dialog now appears when GNOME Video Arcade detects errors during its analysis of your ROM files. The Save As button allows you to save the analysis results to a text file for later viewing.

GNOME Video Arcade 0.4.4

Sun, 16 Sep 2007 05:10:48 GMT

Released a GNOME Video Arcade update that finally adds basic search functionality to the application. I scaled back my grand plans for an advanced search window and instead implemented a simple Google-style entry box. With the game database and automatic conversion of query results to a GtkTreeModel already in-place and working, and for as long as the "Search Results" button has been non-functional, I'm a bit embarassed to admit that it only took about an hour to glue the components together to get search working.

GNOME Video Arcade 0.4.3

Sat, 01 Sep 2007 20:47:46 GMT

I released a minor update to GNOME Video Arcade today with a few bug fixes and user interface tweaks, among which is the main window size being preserved across sessions, courtesy of libgconf-bridge. It also adds all available game data from MAME to the game database now, so the database construction phase takes longer once again. But this is necessary for implementing the advanced search functionality I have planned for 0.5.

Blogging again

Fri, 31 Aug 2007 02:01:08 GMT

I'm trying out the blogging thing again, hoping I can stick with it this time. Now that I have a job that allows me to talk about the interesting things I work on, perhaps I'll fare better at it. Prior to my current job, I spent eight years working on various military projects at Boeing such as the ill-fated X-32 Joint Strike Fighter.

These days I work at Red Hat maintaining Evolution, an open source mail and calendaring application for the GNOME Desktop Environment.

Outside of work I like to hack on a pet project of mine called GNOME Video Arcade, a simple xmame and sdlmame front-end, because I still haven't outgrown those old golden-era arcade games that I spent all my allowance money on growing up. And they make for good five minute mental breaks while hacking.