Busy Day

1st April 2011

Today is clearly a busy day in the world of technology.  Several major projects have been unveiled, including:

Know about any other exciting new developments announced this morning?  Post in the comments!

(Also of interest: invisibility cloak stolen from lab).

The Ada Initiative

17th February 2011

LWN has an interesting article on a new startup: The Ada Initiative (“Supporting women in open technology and culture”), and about how it is taking a different approach to similar initiatives.

The link above is to an article on the LWN that is subscriber-only for the next week.  Being a subscriber, I can provide a link that you can use – if you are interested in what’s happening in Linux, and FOSS in general, I highly recommend subscribing.

There is also other press coverage.

Also, I would suggest that the founders do Ada Lovelace a disservice in calling her “the world’s first woman open source programmer” – she is arguably the world’s first programmer, full stop.

Harassment at FOSS Conferences

10th December 2010

I recommend you go and read Valerie Aurora’s article on harassment at FOSS conferences on LWN.net.  It’s grim stuff, but also a positive piece – looking at how to improve things.

I’d like to think that this sort of thing doesn’t happen at KDE events, but I guess everyone like to think well of their own community.  And I don’t mean that I’d like to think no harassment happens at an event as large as Akademy, say – I’m not that naïve.  But I would like to think that KDE’s atmosphere is one that welcomes everyone, not just men, and doesn’t tolerate such behaviour.

Is this really the case, though?  I don’t think that I’m in a position to answer that, being a man and not having attended many KDE events.  It’s not something I’ve ever experienced or come across, but there’s no reason I should have.  The antipathetic response to Stallman’s “EMACS virgins” quip at GCDS 2009 didn’t really inspire me with confidence on this front, however.  There was outrage, sure, but it certainly wasn’t universal.

What is clear is that the wider software industry and community has issues attracting and retaining women.  While this is a larger problem that we can’t solve on our own, what we can do is make sure that everyone is welcome in our FOSS communities, providing they are willing to get involved, and that we don’t make anyone feel uncomfortable.

So I’m asking some questions: what do we need to do to make this a reality, at least within KDE?  How far away from this are we?  Where do we need to focus our efforts?  I’d be especially interested in hearing from women in KDE on this, as you will have first hand experience of the issues.

DeviceKit: How to Replace HAL

16th November 2010

Following on from my last blog post, I’m trying to assemble information about what, exactly, is supposed to replace HAL on the FDO DeviceKit page.  If you know anything, please add it!

What Brave New World Is This?

16th November 2010

As most of you are probably aware, HAL is dead.  So let us all cry out: HAL is dead, long live… what, exactly?

If you’re wondering what on earth HAL is, it is (or was) a daemon that sat on your computer and told interested parties (such as KDE applications, via Solid) about various bits of the hardware.  This went beyond abstracting away kernel interfaces, however, and included information about laptop batteries that have been recalled, for example.

However, it was decided that HAL was getting too big for its boots and was failing to acheive its stated goal of “making hardware just work”.  But it was filling a need.  So what is sweeping into the void to replace it?

Well, there’s UPower, for all your power management needs.  It replaces those parts of HAL that dealt with screen brightness, the power button, the lid closing and entering various power-saving modes.  It even goes further than HAL ever did, allowing applications to request latency targets, for example.

Then there’s UDisks.  You may be thoroughly unsurprised to learn that it deals with the various bits of storage you may at various times attach to your computer: anything that appears as a block device, basically.

For many other services, you are expected to deal with either higher-level services like NetworkManager (or WICD, or other solutions) or with lower-level ones like PulseAudio or ALSA.  And for everything else, there’s direct interaction with udev, via libudev.

This is all very well, but what about all that extra information that HAL provided?  Well, UDev provides a device database that allows extra information to be stored with devices.  UPower provides battery recall information using this mechanism, for example.  There is a media-player-info project that provides UDev rules and some desktop files that furnishes interested applications with information about supported protocols and media formats of various portable media players.

But after that, I get stuck.  I guess that many of the video power management quirks that HAL documented are expected to be dealt with by the kernel.  But this is just an educated guess.

The major problem with this “kill off HAL” project is the sheer lack of documentation.  UPower has a useful website.  UDisks has an almost entirely unhelpful one.  media-player-info doesn’t even have a website, and you wouldn’t really know to go looking for one anyway unless you follow the right development mailing lists.

Solid is currently having problems with developing replacement backends for HAL.  What is the correct way to get the processor information that HAL previously exported?  LibMTP used to augment HAL’s media player information store with its own information, but there is no clear way for it to extend the information provided by media-player-info.  How should libMTP provide that information now?

All this should really be documented somewhere.  Maybe it is, and I just can’t find it, but that means it’s not documented in a sensible place.  The sensible places being the HAL website and the DeviceKit website (DeviceKit being the overarching term for the “stuff to replace HAL” – UPower and UDisks in particular).

I really hope someone knows what’s going on, and I wish they would communicate it to the rest of us.

EDIT: I realised that, freedesktop.org being largely composed of wikis, I could do some improvements myself.  The udisks site now has some useful information on it, and there is a media-player-info site.

The Magic of QtDBus, and the PropertyChanged signal

7th September 2010

I’ve had reason recently to delve into the inner workings of QtDBus.  It does more for programmers than I (and probably many of you) realised.

For example, when you tell qdbusxml2cpp to generate a proxy for you, it creates a subclass of QDBusAbstractInterface, and populates it with properties, signals and slots that correspond to the D-Bus properties, methods and slots.  But there’s more going on under the hood than it seems.  In particular, all those annotations for input and output types are used for more than just simple casting of QVariants.

Consider, for example, what happens when you fetch the value of a property of D-Bus type a{sv}.  This is a map from strings to variants.  The natural representation in Qt is a QVariantMap, but it could just as easily be in a QHash<QString, QVariant>, or even something based on std::map.  Qt doesn’t know.  So you can put an annotation in your D-Bus interface specifications, indicating what type it should be represented as:

<annotation name="com.trolltech.QtDBus.QtTypeName" value="QVariantMap"/>

OK, so what does qdbusxml2cpp do with this information?  Well, in this case, we’re annotating a property.  qdbusxml2cpp will produce the following code in the proxy class:

Q_PROPERTY(QVariantMap Foo READ foo)
inline QVariantMap foo() const
{ return qvariant_cast< QVariantMap >(property("Foo")); }

As you can see, it casts a property (which is a QVariant) to a QVariantMap.  But that surely demands that the QVariant already contains a QVariantMap and not, say, a QHash<QString,QVariant>?  Well, there’s some magic in QDBusAbstractInterface to deal with this for you.

Basically, when you request a property (QObject::property()), QDBusAbstractInterface requests it over D-Bus.  If it’s something simple, like a string (D-Bus type s), it gets demarshalled automagically in the internals of QtDBus, giving you a QString in this example.  But if it’s something more complex, like the above a{sv} type, QDBusAbstractInterface looks up the type information in Qt’s meta-object system, and uses that to demarshall it into the correct type – if the property type is QVariantMap, it will be demarshalled into a QVariantMap.

A similar trick is done for signals (note that if you get the signal signature wrong, you will simply never receive the signal).  Sidenote: if you add a QDBusMessage parameter as the last parameter of the slot you connect to a D-Bus signal, you’ll get a copy of the signal message.  You can even just have the QDBusMessage parameter, although you’ll be creating more work for yourself.

So, this is all very nice, but why am I telling you about stuff that “just works”?  Well, you have to watch out for the times when it doesn’t “just work”.  I’ll illustrate just such a case with an implementation of the PropertyChanged signal.

The PropertiesChanged signal is a recent addition to the org.freedesktop.DBus.Properties interface in the D-Bus specification that allows you to receive notifications when a property value changes.  It’s rather new and hasn’t even made it into the released version of the spec yet.  However, it will be supported by the next version of GIO.  Hopefully, it will be supported in a not-too-distant release of Qt (4.8?), but in the meantime you can quite easily add support yourself.

The signal looks like

org.freedesktop.DBus.Properties.PropertiesChanged (
    STRING interface_name,
    DICT<STRING,VARIANT> changed_properties,
    ARRAY<STRING> invalidated_properties);

where changed_properties is a dictionary containing the changed properties with the new values and invalidated_properties is an array of properties that changed but the value is not conveyed.

Now, on the server side, you can’t support it “properly”, because the introspection for the org.freedesktop.DBus.Properties interface is fixed by QtDBus, but you can emit the signal yourself anyway:

QDBusMessage signal = QDBusMessage::createSignal(
 "/object/path",
 "org.freedesktop.DBus.Properties",
 "PropertiesChanged");
signal << "org.foo.MyInterface";

QVariantMap changedProps;
changedProps.insert("somestringprop", "newstringvalue");
changedProps.insert("someintprop", 4);
changedProps.insert("somemapprop", newmapvalue);
signal << changedProps;

QStringList invalidatedProps;
invalidatedProps << "invprop1" << "invprop2";
signal << invalidatedProps;

QDBusConnection::sessionBus().send(signal);

Easy as pie, right?  You can even have a helper method that does this:

void notifyPropertyChanged( const QString& interface,
                            const QString& propertyName )
{
    QDBusMessage signal = QDBusMessage::createSignal(
        "/object/path",
        "org.freedesktop.DBus.Properties",
        "PropertiesChanged");
    signal << interface;
    QVariantMap changedProps;
    changedProps.insert(propertyName, property(propertyName));
    signal << changedProps;
    signal << QStringList();
    QDBusConnection::sessionBus().send(signal);
}

On the client side, things are slightly more complex.  My approach is to insert a class into the proxy code heirachy.  While qdbusxml2cpp produces subclasses of QDBusAbstractInterface, I modify these to inherit a class of my own (DBusAbstractInterface) that in turn inherits QDBusAbstractInterface.  This class has all the magic needed to deal with the PropertiesChanged signal.

Essentially, it connects to the PropertiesChanged signal using QDBusConnection::connect(), and forwards this to any listeners.  So far, so simple.  But what happens if we have a property with D-Bus type a{si} (a map from strings to integers)?  Then the changed_properties map will contain an entry mapping the property name to an a{si} value.  How does QtDBus know how to demarshall this?

Well, the fact is, it doesn’t.  QtDBus will demarshall the changed_properties map into a QVariantMap (or whatever appropriate type the second argument of the slot has), but it can’t demarshall any complex types that are values in that map.  Do you want your a{si} map as a QMap or a QHash?  QtDBus doesn’t know, and so puts off the demarshalling by inserting a QDBusArgument value into the map.

If you know what structure you’re expecting here, you can just demarshall it with something like

QMap<QString,int> map;
changed_properties.value("foo").value<QDBusArgument>() >> map;

My helper class does something roughly similar to what QtDBus does internally, and uses the meta type system to figure out how it should demarshall the values in changed_properties.  But just remember that if you have a complex structure passed over D-Bus as a variant (D-Bus type v) and received in your code as a QVariant, the chances are it’ll be in the form of a QDBusArgument, and you’ll have to demarshall it yourself.

The Party of Gno

18th June 2010

I came across an interesting blog post about the FSF’s strategy on LWN, and thought it was worth sharing.

The essential argument is that the FSF does too much preaching about what people shouldn’t do, without offering constructive alternatives.

D-Bus threading issues

1st June 2010

There are some annoying issues and crashes in KDE 4 (and particularly in KRunner and Nepomuk) that are related to the thread-safety (or, rather, thread-non-safety) of libdbus-1.  kde-core-devel has seen some discussion about this recently.

There is a patch that fixes the issue, but it won’t make it into D-Bus before dbus-1.4, due to the fact that it changes the library behaviour and could potentially break bindings.  Thiago has confirmed that the change doesn’t break the Qt bindings, and (from the bug report), no-one has found any other bindings it breaks.

This is all just background on why, if you are running Arch Linux, you might want to check out the dbus-core-mt package on the AUR.  It’s dbus-core-1.2.24, as found in core, but with the afformentioned patch applied.  Note, however, that you use it at your own risk – it should improve KDE, but it may well break other stuff.

Exciting Nights at Akademy?

28th July 2009

I’ve come away from GCDS with several pieces of clothing I didn’t have before.  Some of them – a T-shirt I bought and three more given out by sponsors – were expected.  Others were not.  One of my roommates had to leave part way through the week, and (unsurprisingly, given that the room was as messy as you might expect from three guys) managed to leave a couple of items behind, which I picked up.  However one item still puzzles me.

I have a pair of jeans that are certainly not mine, and both my GCDS roommates deny owning.  Now, I’m pretty sure that our room didn’t see quite the level of excitement that leads to random people’s clothing being left around.  So the question is: where did they come from?

Akuadec

9th July 2009

Another day of the Gran Canaria Desktop Summit. After yesterday’s post, I got several offers of power adaptors. However, I ended up buying one on my way back to the hotel, along with a bunch of food for lunch today (the lunches here at the university are poor and quite expensive for what they are).

In fact, speaking of food, I had the worst meal I’ve had this week, and one of the worst I’ve had in my life, last night. We went to a Chinese all-you-can-eat buffet. Now, now, don’t scoff. I’m had some good (although never excellent) food at all-you-can-eat buffets. It seems that the Canary Islands is not the place for them, though. This one was so bad that after my first plateful, I was still hungry but didn’t want to eat any more. Avoid like the plague.

This was in direct contrast to the meal I had with the Amarok guys the night before, which was really nice (if expensive) – masses of paella, salad, chips and warm chocolate brownie. It was seriously good.

Today we had more Amarok discussions. So far we’ve discussed:

  • liblastfm on Windows
  • Playlist synchronisation
  • Unit testing
  • Whether scripts should be able to respond to Amarok quitting (and potentially slow it down)
  • A UPnP collection
  • Reorganising the source files
  • Playdar
  • The UI for dynamic playlists, and context-sensitive information for the area on the left of Amarok (where collections and services etc. are)
  • The EngineController class
  • Mac/Windows ports

Still to come:

  • Media devices update
  • The evil “organise files” bug (pro tip: don’t use Amarok 2 to organise your files for now)
  • UI clutter

We’ve had a very productive couple of days, and Leo’s been taking photos of the whiteboard, so we have a permanent record of our discussions.  Expect blog posts about the cooler things we discussed.


Follow

Get every new post delivered to your Inbox.