As part of my work on Arkose, trying to make desktop application containing easy, I’ve been working over the last month or so on a protocol aware DBUS proxy.
I based my work on Alban’s DBUS proxy for N900, made the proxy work with multiple connections and added support for logging and filtering of the connections.
The result is profiles like this one:
Which in this case will allow the applications using the proxy to access the global menu DBUS API and receive events from the Global menu, but not for example dump your gnome keyring.
Here’s the output you’d get when running gedit using the above profile:
Now that the proxy works as expected, I’ll work on integrating it into Arkose itself and expose it in the wrapper GUI.
To try the proxy, you can grab Arkose’s trunk branch at:
bzr branch lp:~arkose-devel/arkose/trunk/
Build the proxy (you’ll need glib and dbus) and then run it with:
./proxy /tmp/arkose_dbus profiles/dbusmenu.conf
Starting clients like this:
Have you any plan to propose Arkose in Ubuntu ?
Arkose has always been in Ubuntu since its first release in Ubuntu 11.04.
stgraber@castiana:~/data/code/arkose/dbus-proxy$ apt-cache search arkose
arkose – Desktop application sandboxing – core
arkose-gui – Desktop application sandboxing – gui
arkose-nautilus – Desktop application sandboxing – nautilus
It’s shipping by default with Edubuntu and can easily be installed on Ubuntu from the Software Center or using apt-get.
Yes , i mean installed by defaut in ubuntu, like Android with all apps.
It certainly won’t ship with 11.10 by default as we’re too close to feature freeze and there’s no space left on the CDs, but Edubuntu will ship with it by default (as it’s a DVD) and some additional software provided post-release might use arkose (by pulling it as a dependency).
Ok, Thanks 😉
Nice work. Just a technical question. What was the reasoning behind using fork for child processes for D-Bus connections? Are there some restrictions for using threads instead?