Introduction and toolkit abstraction

[Jono Bacon]

Hi all,

First of all, let me introduce myself. My name is Jono Bacon and I am a 
writer, consultant and developer. As a day job, I write for computer 
magazines and book publishers, and I have probably interviewed some of 
you in one way or another. I have been involved with Linux for a number 
of years, spent some time with the KDE project (wrote some code, founded 
the KDE Usability Study and KDE::Enterprise) and I am currently 
traveling all over the place talking about the future of the Linux 
desktop, emerging technologies and other related content. I have been 
keeping an eye on freedesktop.org and I have been on the HAL and Utopia 
lists for a while and chipped in with some discussion - I am interested 
in helping to standardise freedesktop.org as a platform. I look forward 
to working with you folks. :)

Anyway, one of the key areas that I have an interest in is some form of 
toolkit abstraction. I am sure this has been discussed many times 
before, but bear with me while I outline some of the things running 
around my head at the moment. To me, it seems we have a problem with how 
the desktop is archtected and how it is perceived by users. As an 
example, when I fire up the GIMP, the software pays no real attention to 
which desktop it is running in. Sure, if running in GNOME, it will honor 
some theme support, but in terms of pure functionality, the software 
functions largely the same in whatever desktop is being used. What do I 
mean by functionality? A key example are dialog boxes. When I am in KDE 
it would make sense if the KDE file dialogs are used as opposed to the 
GTK dialogs. KDE will behave in particular ways with regards to opening 
and saving files, making resources available etc., and this standard 
part of KDE should be honored in applications that run inside the 
desktop. This would apply in the same context in GNOME - the file 
open/save dialog in Quanta should be a GTK dialog box.

With this concept we have some technical challenges to face. By running 
this kind of solution we are essentially creating a bridge between two 
pieces of software. This will require (a) abstraction on both sides of 
the bridge (Qt/libkde*/GTK) and also require hooks into client software 
to make use of these resources. As with any kind of bridge though, we 
can only cross if both sides are held up. For this reason, if the file 
save dialog support is flaky on one side of the bridge, the whole bridge 
could collapse. The other technical challenge we would need to discuss 
is how technically possible the solution is. From my initial thoughts, 
it seems that much of the functionality can be mapped from one toolkit 
to the other. With the dialog example, a file open dialog will only 
return one value - the file to open. This is a pretty common return 
value for that kind of interface entity and if both sides of the bridge 
are matched, we can abstract it out and utilise it in the 
freedesktop.org platform. Another technical challenge we would need to 
face is to actually standardise themes across KDE and GNOME software. I 
know there is some good work going on in this area, and this is a whole 
new discussion, but it would obviously confuse the user if the file open 
dialog loads in one theme and the rest of the application is in another 
theme. This theme support would need to be consistent. I have not 
researched much into this area so I would be interested to hear any 
feedback.

Another area where this kind of support could be useful is in 
standardising HIG across software. I am a firm believer that usability 
can be enforced to a level by utilising commonly used chunks of 
functionality such as dialog boxes and wizards. Due to the fact that 
these chunks of functionality are largely pre-constructed, *some* HIG 
can be automatically applied. The obvious mecca is to make GTK software 
follow KDE guidelines and vice versa. Usability/HIG conformance and 
interaction design is obviously an area that is largely determined by 
the hacker, but if some kind of automation can occur, this could make 
the desktop much easier to use for the end user.

If this kind of idea is something that could show potential, what do you 
all feel would be the best way of implementing it. My personal hunch is 
that some kind of separate library could be linked to which abstracts 
out these shared resources. Each application that is designed to run on 
the freedesktop.org platform will link to the library and the relavent 
desktop environments will indicate which resources should be used.

It seems that possibly the most difficult hurdle to overcome is 
political. to make this work we would need to ensure that both the Qt 
and GTK camps can dedicate to the freedesktop.org platform. This may be 
easier for the GTK hackers, but I suspect it could cause some issues 
with Trolltech - they naturally have a commercial product to think of, 
but I am sure they could support abstracted toolkit functionality by 
rolling a switch into the compile process or something.

As an idealist, it seems to me that the ideal scenario for a developer 
is that their software should be written in any language/toolkit of 
their choosing and that application will integrate seamlessly with the 
user's desktop. Likewise, the user should be able to take any 
application and have it integrate with the desktop of their choosing. I 
see no point in necessarily having to give hackers the opportunity to 
use GTK widgets in KDE applications and vice versa, but common features 
that differ across toolkits would make sense to abstract out and 
contextualise.

If this sounds like I am smoking crack, feel free to put on the asbestos 
suit, but I am interesting in some good constructive discussion to see 
how viable this is.

Cheers,

    Jono

-- 
Jono Bacon - http://www.jonobacon.org/
Writer / Journalist / Consultant / Developer