Common user interface mistakes in KDE applications, part 4: Being .

Common user interface mistakes in KDE applications, part 4: Being GNOMEfriendly

Here is a new accession to my series on common user interface mistakes in KDE applications.

This time I wish to speak about being GNOME friendly. While that may sound odd for a KDE developer to guess about GNOME, assuming we need our applications to make the largest possible audience, we should try to ensure GNOME users get a enjoyable experience.

After all, a user is a user, there are efforts going on to ensure KDE works intimately on Windows and Mac OS X, I remember we should also take charge of GNOME users. They are at least as potential if not more likely to bring back to our applications.

As common with Qt, it already does most of the form for us: when a Qt or KDE application is working on a GNOME desktop, it will uses the "gtk " Qt widget style by default. This widget style uses GTK primitives to run widgets, which helps a lot to combine your diligence in the GNOME land. Testing

You can of course test how your application behaves on GNOME by working it on the Gnome desktop. This is interesting to do, at least to support an eye on what our fellow competitors are doing, but it takes quite some time. There is a quicker way: start your application with these arguments: "-style gtk ".

KWrite running with the GTK style (Clearlooks GTK style):

"It doesn`t work!"

What happened? If you get a substance like that one: The style 'gtk ' was not found

Tough luck: your interpretation of Qt was not built with gtk support, not often to do here, except rebuilding Qt or using a different one.

If on the other hand you get something which looks a lot like Oxygen, chances are you are working the Oxygen GTK theme! This idea is keen to integrate GTK and GNOME applications on a KDE desktop, but it`s not very helpful here. There are a few ways to convert your GTK theme from within KDE. The simplest one is probably "kcm-gtk", a GTK KConfig Module available from https://code.launchpad.net/kcm-gtk (Would be a nice candidate for inclusion in KDE SC!)

Making your application GNOME friendly

Enough testing, let`s fix bugs now! Double margins

First of all, be on the watch for my all-time-favorite pet-peeve: "double margins". Oxygen often reduces the shock of double margin problems, but other styles do not. Here is for example a screenshot of Partition Manager with Oxygen:

Now, the same application, using the GTK style:

As you can see, there is rather a lot of wasted space. The fix is simple: call setMargin( on the layout in the embedded widget and the trouble will go away.

• note 1: QLayout:setMargin(int) is deprecated, and one should be using QLayout:setContentsMargin(int, int, int, int), but I can`t
  get used to it: setMargin(int) is much shorter. Please Qt people, "un-deprecate" setMargin(int)!
• note 2: Sorry for the french on the screenshots, hopefully it does not keep you from seeing what I mean

QFormLayout

Another good exercise to take your application GNOME friendly is to use QFormLayout instead of QGridLayout for typical "label: [edit widget]" dialogs. Using QFormLayout ensures your labels will be correctly aligned: KDE 4 HIG says labels should be correctly aligned, while GNOME HIG prefers them to be aligned on the left. Use standard dialog classes

One of the oldest GNOME vs KDE troll is button order in dialog boxes: KDE uses the OK-Cancel order, while GNOME uses Cancel-OK. If you use KDialog instead of QDialog as a base class for your dialogs, you won`t get to care about it: the button order will vary according to the platform.

If you cannot use KDialog, for instance because you get a Qt-only application, do not create individual OK and Cancel buttons: use QDialogButtonBox. This class lets you set a standard dialog button bar: you simply want to determine which buttons you need. If for some cause you get a KDE application but do not wish to use KDialog, be certain to use KDialogButtonBox, KDE version of QDialogButtonBox. Icons

This one is for Qt-only applications: instead of embedding your own copy of the generic open, close, save_ icons, consider using those coming from QStyle:StandardPixmap. Your application will automatically use GNOME icons when working on Gnome and KDE icons when working on KDE. Others

Sometimes you want to be set to go the extra mile. For example, Gwenview start page used to be wretched and hard to use with GTK themes because the tabs would not be rendered using the correct color. I worked round this bug by scene the title of the tab widgets to Plastique when run on GTK .

Before:

After:

If you are interested, here is the diff implementing this hack. Conclusion

That`s it for this episode, now lets see ifcan make our applications as beautiful on GNOME as they are on the KDE desktop!

• Share this:
• Share

← February 2011wrap-up