What is X-Bus?
It’s a personal project I’ve been working on (among other things) since I joined Canonical. It’s a daemon which handles input devices through the XInput protocol. In the future I hope to add support for outputs too.
What’s the purpose of X-Bus?
Its main purpose is to provide developers with a common (and simplified) way to access XInput from languages which have DBus bindings (Python, Ruby, C, C++, Java, Perl, etc.). It is not specific to any desktop environment, even though it uses C++ and QT4 (see below).
Wouldn’t it be nice if we could have KDE, Gnome, Xfce, etc. applications which make use of the same backend with different frontends (as opposed to having different backends and frontends)?
Current features:
- Exposes XInput (listing/setting properties, catching signals, etc.) through Dbus with a simplified API.
- Stores the (per-user) current inputs configuration in an XML file and applies it at startup or when requested.
- Emits signals (through Dbus) when new devices are plugged in or unplugged (so that, for example your client application can refresh its UI to reflect the new situation).
- Tracks keyboard activity so as to disable your touchpad when you’re typing.
It’s an attempt to combine the features in syndaemon and xinput (the command line tool), from both of which X-Bus borrows code.
3 examples of what X-Bus can be used for:
- User interfaces to configure touchpads (which is the 1st thing I would like to work on).
- User interfaces to configure touchscreens whose drivers support XInput (I still need to expose the calibration functions provided by XInput though).
- Automatic rotation of your touchpad (figuratively speaking) when your screen is rotated (after this is implemented).
Why QT?
Because of its DBus and XML modules and because it’s a pleasure to work with QT in general.
Example: if you add the Q_SCRIPTABLE macro to the function in the header file, this function will be made available in your DBus interface. This applies to signals too. This makes maintenance a lot easier.
In my opinion it would be overkill to use the DBus low-level API and I don’t think the glib (DBus) bindings can offer what I described in the example (feel free to prove me wrong on this). Furthermore I would have to use an external xml module to perform validation and the things that I currently do with the xml file.
Doesn’t it duplicate efforts? Why don’t you work on $INSERT_DAEMON_HERE instead?
Yes, it does (partially) but my point is: can we use $INSERT_DAEMON_HERE on KDE, Gnome, Xfce, etc. ?
Furthermore, if you have a look at X-Bus’ API you’ll see that (currently) there’s very little duplication.
Where’s the code?
Source code (have a look at the examples which are written in Python)
Packages
NOTE: this is just a first release and users won’t benefit from it without a user interface (unless they want to edit the xml file manually).
I’am a bit worried you contaminate the Ubuntu’s default desktop GNOME with QT/C++. It does not feel right at all!
I’ll not install extra QT libraries because GNOME is a GTK/GDK product.
Keep your QT off my desktop.
Why do you want to make XInput devices available through another IPC systems. There’s already the X protocol doing that. Adding support for XInput2 to widget sets would be a better use of your time.
@Bastien
the fact that X-Bus makes XInput accessible from languages other than C and C++ is just a (useful) feature. The daemon is also meant to allow you to store your settings for input devices so that they are loaded when the session starts.
As regards a “better use of my time”: “there will likely be a fairly big API change in how XI2 clients can deal with events”.
Um, Ubuntu doesn’t come with Qt by default. So yes, it is sort of specific to the KDE desktop – not many will want to add another $toolkit for one program.