Introduction and toolkit abstraction

[Avery Pennarun]

On Tue, Aug 31, 2004 at 10:30:21PM -0400, Sean Middleditch wrote:

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

UniConf, the unified configuration library, is just another configuration
library, but it saves work because you don't have to use it - it uses you. 
Maybe I'm a weirdo, but I'm willing to try that game with toolkits too :)

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

That would be nice.

> But is it really worth the immense amount of complexity that would bring
> in?  Two main loops?  Two *huge* sets of libraries pulled in?

Probably no users would notice the slowness and complexity, since both
desktops are disgustinly bloated and slow as it is.  glib's mainloop is
pretty extensible, so you ought to be able to mash kde into it somehow.

> Would the KDE dialog in GNOME use kioslaves or gnome-vfs?

Clearly we should unify those two first of all.
http://open.nit.ca/wiki/index.php?page=WvFuse

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

Sounds tricky.

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

It ought to be a theming issue, but this sort of thing isn't totally
critical at first.  Unifying the other stuff would be a big gain, and
twiddling widget layout would be minor by comparison.

> What language is this toolkit in that people will get religious over? 

None.  Use your current toolkit, and your current toolkit will use this.

> What other dependencies will it bring in that people will resist?

The trick, of course, will be to make it optional.

> Is it just going to abstract GNOME and KDE, or GNOME, KDE, ROX, GNUStep,
> OS X, etc?

Start simple: use the file dialogs from KDE in GNOME, or the GNOME ones in
KDE.  If you can do that, you win points.  If you can do more, you win more
points.

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

I think you have his proposal inverted here: wxWindows requires you to
change the way you think about GUI programming, and it will deal with your
favourite toolkit.  I'd rather you deal with your favourite toolkit, and the
toolkit changes the way it thinks about the GUI.  GTK programmers want to
use GTK: let them.  KDE users want the KDE file dialog: GTK should use it.

Sounds like a project.  All we need now is a project leader, sample code,
and tens or hundreds of people to do the work.  How bad can it be?

Have fun,

Avery