Introduction and toolkit abstraction

[Mike Hearn]

> 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.

Right.

> 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
> all).

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 
effect.

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.