JUL
26
2005

Ottawa Desktop Developers Conference

I just returned from a week of Canadian hospitality in Ottawa. First I attended the Desktop Developers Conference, later in the week followed by the Ottawa Linux Symposium. It was also a chance to meet for the first time with some of my colleagues at Intel. The group I work in is spread around the globe, with me being based in France, some others in Bejing and the rest spread across various locations in the US. In October I will be moving to Oregon to be a bit closer to some of them. Read on for some impressions of the Desktop Developers Conference.

The desktop developers conference was interesting but after attending both Guadec and the European X developers conference earlier this year, there wasn't that much new to learn here. Alexander Dymo's KDevelop tutorial was somewhat sparsely attended. Vi-using X-hackers are perhaps not the right target audience for KDevelop. The early hour and the whiskey-buying BOF the nightbefore may also have contributed. Still, several of my Intel colleagues where impressed when they learned what KDevelop, Qt and the KDE framework had to offer to developers.

Malcolm Tredinnick gave a very brave presentation about Linux desktop development from a third-party developers perspective. Brave, because a lot of people in the various communities villify anyone who dares to criticize any aspect of their pet project. Especially in the KDE community quite a few people seem afflicted with some sort of victim-syndrome where every bit of critique is thought to be part of a secret plot to destroy KDE. I guess it is some sort of genetic left over from the Qt licensing squirmish from times past. Nevertheless the presentation provided an interesting view on no specific desktop project in particular with some good hints on what to pay attention to if you want to attract more developers to use your APIs. I think there is a lot we do right already within KDE, but I also think there are areas where things can be improved. Just pretend you are about to write your first KDE application and don't know where to start, can you find all the information you need without having to ask someone on irc? You can find Malcolm's presentation here: http://www.pointy-stick.com/desktopcon-2005/

Another interesting presentation was about UniConf and given by Patrick Patterson. I think UniConf is interesting because with recent discussions about DConf I believe there is a reasonable good understanding what both users and developers want from their configuration system. In case you are a developer and missed the discussion, users want a common configuration system for all their applications (and yes, that includes non-KDE applications such as Evolution, Gaim, Firefox and OpenOffice.org) and be able to take advantage of KDE's KIOSK lock down features for all of them. They also want to be able to store all or part of their settings in a remote database, possibly over LDAP. Being the diversive bunch that our users are, not all users want the same, some just want to keep using the current set of flat .ini files and don't want to rely on anything beyond that.

I think with KDE4 in the works it is an excellent time to see if we can deliver this kind of functionality to our users and UniConf may in fact be well positioned to deliver most, if not all, of that. I spoke with some of the UniConf developers and we managed to hash out how UniConf can provide the kind of functionality that we need. I think it will be interesting to create a work branch in KDE SVN and porting KConfig to it, and see whether it will be able to deliver that what looks good on paper also in practice. Then it will be a matter of agreeing on a set of policies with other potential UniConf users on how to configure and use UniConf so that it can become a commonly used configuration system for the Linux Desktop. Drop me a note if you are interested to work on any of this.

My colleague Rajesh Banginwar gave a presentation about LSB and how to develop applications for LSB compliant distributions. Don't worry if you have missed it, if you are visiting this year's aKademy in Malaga you will be able to get another chance. Rajesh is heading the desktop workgroup in LSB. Previous LSB efforts focused mainly on specifying the C ABI of the base libraries, the desktop workgroup plans to extent this to other areas as well, such as how to install a new font, how to add your application to the start menu or how to add an icon to the desktop. Make sure to join the LSB desktop workgroup mailinglist if this is an area that interests you.

In the LSB BOF that followed Rajesh' presentation it became clear once more that, despite efforts such as LSB, the fragmentation around Linux is posing real hurdles for ISVs (Independent Software Vendors).  There are the obvious differences between the two major desktops, differences between different distributions and even differences between two different versions of the same desktop and distribution (for example differences in the behavior of the window manager). Having strong standards in place can help reduce some of the associated pain but the ISVs present made the point that they will still need to test whether everything works on a large number of distributions/desktop combinations that are all slightly different.

An interesting point was made about older versions and new features in the context of GTK+. In order to target a large market they had to target a relative old version of GTK+ (2.2), they did however want to take advantage of features in newer versions of GTK+ when available. They solved this by dlopening gtk and looking up the symbols for the newer functions so that they could check their availability and use them when present. The ability of GTK+ to report its version at runtime helped here. It seems that a hack like this will be more difficult to achieve with C++, has anyone ever done something similar for Qt/KDE ?

Comments

> It seems that a hack like this will be more difficult to achieve
> with C++, has anyone ever done something similar for Qt/KDE ?

It's possible, in theory. In some ways easier than others. The thing to watch out for is the C++ ABI compatibility (g++ 3.x all define a CXXABI ELF version symbol).

If you're using the dynamic linker in lazy mode, you can link your application to the newer version. Just make absolutely sure not to try and use a symbol that isn't present in a certain version.

For instance:

KMyClass cls;
if (KDE::version() >= KDE_MAKE_VERSION(3,3,0))
cls->newMethod();
else
cls->oldMethod();

will work, even if KMyClass::newMethod isn't defined anywhere in the libraries. The catch is that you really must make sure those symbols aren't used in your program except in protected code paths: if the symbol in question is a virtual function newly added, the class must have at least one non-inlined function.

This method would work for both virtual and non-virtual functions. The virtual case would be even safer, because LD_BIND_NOW can't affect it. However, if you mess up, the virtual case will most likely lead to a crash (branching to an invalid pointer), whereas the non-virtual one will abort with an undefined symbol.

You could also dlopen() the library and look for a special function that would return your new class, depending of what's available:


KMyBaseClass* cls;
KMyBaseClass (*func)() = dlsym("createKNewClass");
if (func != NULL)
cls = func();
else
cls = createKOldClass();

and use all the benefits of virtual functions.


By Thiago Macieira at Thu, 07/28/2005 - 03:37