Associating Firefox Profiles with KDE Activities

As a heavy user of the Activities feature, I’ve always had two major itches. One was addressed when KDE 4.9 finally brought the ability to set activity window rules. The other was how only some applications had the necessary (XSMP) compliance to work properly with activities and its session restoring – in particular, a lack of compliant web browsers.

In fact, to date, the only apparently fully XSMP compliant web browser I know of is Konqueror, full stop. And while Konqueror is a pretty decent browser, its lack of a Firebug-esque DOM inspector made it increasingly inadequate for my purposes now that I do a lot of web development for my day job.

Being reduced to keeping one giant unmanageable lump of tabs in one central Firefox instance gave me plenty of incentive to think hard about the problem. Since it doesn’t look like Firefox or any other browser was gonna go compliant on its own anytime soon, the thought occurred to me if compliance might be hacked in by proxy: if I could manage the browser instance via an external program, I could deal with the session manager from my program and proxy the desired behavior onto the browser instance. So I spent some free time looking up how I might be able to externally control Firefox or Chrome or whatnot. Not surprisingly, the browsers aren’t very open to external controlling, but Firefox’s profiles feature provided just enough command line controls to be exploitable for my purposes. You could run different profiles simultaneously, with each profile being it’s own single process and conveniently remembering it’s own state/session information. So all I needed to do was write an XSMP-compliant program that keeps a Firefox profile name as state information, launches the Firefox instance so it knows its PID, killing the correct Firefox process when the activity closes and the session manager tells it to save state, and reading the profile name and relaunching the Firefox instance for it when the session restores.

So I went ahead and wrote that program, and dubbed it ‘activityfox’. It works quite well :) The proxy program needed to be a GUI application because it seems like the session manager doesn’t save and restore console ones, but with a little Kwin window-rule magic we could completely hide away the proxy program’s GUI window. Here’s a short screencast showing it in action:

The way it works is you launch activityfox in an activity, which by proxy launches a Firefox instance with your chosen profile. activityfox will be automatically associated with the current activity, and when you stop the activity, activityfox will be asked to save state and close, and it’ll save the profile name and close it’s child Firefox process too. When you relaunch the activity, the session mechanism automatically calls up activityfox again, which reads the profile name from its saved state information, and uses that to restore the right Firefox profile instance. Since every Firefox profile instance is its own process, you can have as many Firefox profiles running in as many activities as you want, and they’ll all behave. Stopping an activity only closes it’s associated Firefox profile instance, leaving the rest alone, and restoring it restores the instance.

Source code, with build and usage instructions, can be downloaded here (Edit: it’s now on my github here). I’m afraid it’s a C++ program you need to compile: I tried to make it a python script, but for some reason it always crashes after KMainWindow::saveProperties is called, whereas the equivalent C++ program worked fine.