Introduction and toolkit abstraction
m.hearn at signal.QinetiQ.com
Wed Sep 1 12:02:41 EEST 2004
> What a toolkit abstraction library would *really* be is Another Toolkit.
> So instead of having two major toolkits, you'd have three. Big
> improvement there.
> The problem you're identifying isn't a toolkit problem, really. It's a
> design problem. A GTK+ app can be made to look and act identically to a
> KDE app. It isn't the toolkit that causes the problem. It's the fact
> that the apps are designed for one desktop or another (or no desktop at
To be frank, I'm not even sure it's a problem. If you look at the
competition, well, Windows has *never* had totally consistent common
dialog boxes and has never really had a HIG worth speaking of, yet it
muddles through. It's not a killer problem.
> To some extent, this can be mitigated. Make GTK+ apps running in KDE
> automatically switch to one of the GTk-Qt themes to instantly unify
> visual appearance, for example.
Gtk-Qt bridge here: http://gtk-qt.freedesktop.org/
> You could take things a step further and, for example, have Qt apps use
> GTK+ dialogs when running GNOME. Or vice versa.
I don't think this would be a good idea w.r.t consistency. Some
applications (like the Gimp) modify their file dialogs with custom
widgets, so you couldn't just slap the Qt filepicker on top of that and
have it consistent anyway. You might *reduce* inconsistency a small
amount but you also increase complexity.
A better approach would be to hack GTK itself to have a similar dialog
box design to the Qt dialogs then use a unified theme to complete the
I'm not sure why you'd want to, as the Qt file dialogs are an exact rip
of the Windows 95 equivalents, even the default artwork is the same, but
ok whatever ...
> To be honest, there already is a fairly popular cross-platform toolkit
> that uses native widgets - wxWindows. It supports GTK+ and, I think,
> Qt. (And if it doesn't, nothing stops that from changing.) Why aren't
> most major Linux apps written in wxWindows? Of all the apps I've ever
> used, only *one* was written in that toolkit. I don't know why - but
> maybe if you found the answer to that one you'd have more insight into
> the problems of making an "official toolkit abstraction library."
Havoc has some theories about this. "Abstracting" toolkits always suck,
I think is the central thesis :)
I have to admit that all the wxWindows apps I've used have felt out of
place on every platform. Something has hugely different as a widget
toolkit just can't be abstracted in a meaningful way, you might as well
just rewrite the UI entirely or use a portable toolkit. They often look
wrong - GTK widgets but not GTK stock artwork for instance, or tend to
cause a lot of obscure bugs due to the imperfect abstraction they provide.
Better to choose one toolkit and stick with it.
More information about the xdg