Introduction and toolkit abstraction

[Sean Middleditch]

On Wed, 2004-09-01 at 00:37 +0100, Jono Bacon wrote:
> Hi all,

> 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 

Short response: ugh.

Long response:

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

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.

You could take things a step further and, for example, have Qt apps use
GTK+ dialogs when running GNOME.  Or vice versa.

But is it really worth the immense amount of complexity that would bring
in?  Two main loops?  Two *huge* sets of libraries pulled in?  Would the
KDE dialog in GNOME use kioslaves or gnome-vfs?  How would the
application handle that?  Should the application have to handle that?
GNOME uses instant-change preferences (yay) while many non-GNOME apps
use the ok/apply/cancel hodge-podge - how could the toolkit abstract
that away?  When the widgets are laid out in an application, there is a
good GNOME way and a good KDE way and a good Windows way and a good OS X
way - how do you handle that?  What language is this toolkit in that
people will get religious over?  What other dependencies will it bring
in that people will resist?  Is it just going to abstract GNOME and KDE,
or GNOME, KDE, ROX, GNUStep, OS X, etc?  When you look at the *huge*
number of programming languages, wildly different design patterns, and
totally differing application behaviours between all those desktops
(many of which are Free UNIX desktops which freedesktop.org exists to
serve) does a single abstraction toolkit seriously look at all feasible?

When an app is running on my desktop, the way I expect it to work cannot
at all be facilitated by a toolkit.  It needs to be facilitated by a
design.  Give OpenOffice.org all the GTK+ theming and native dialogs you
want, it will *still* look, act, feel, and taste like a rip-off of a
very design intended solely for Windows.  The changes you'd need to make
to OpenOffice.org to truly make it fit in with GNOME are far beyond
simple toolkit issues.  The same goes for KDE integration, OS X
integration, GNUStep integration, ROX integration, etc.

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