Introduction and toolkit abstraction

Philippe Fremy phil at
Wed Sep 1 14:49:45 EEST 2004

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

I agree, increased complexity, reduced inconsistency. Still I believe it is 
a valuable development. Anyway, the complexity / inconsistency trade off is 
already there. Gnome is more complex than Gtk but provides a more 

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

Won't work. First, nobody would be willing to use the Qt style of the Gtk 
dialog. Second, both Qt, KDE, Gtk and Gnome move quite quickly and any 
emulation is asking to be obsoleted and unmaintained quickly. The only long 
term solution is that the right toolkit should display its own dialog.

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

For example, KDE dialogs remember a set of preferred directories that you 
can quickly choose on a left panel. Very convenient feature. A non geek 
user is annoyed not to find its directories when he uses gimp, openoffice, 
or gnome.

> Havoc has some theories about this. "Abstracting" toolkits always suck,
> I think is the central thesis :)

I agree. But it is not what is proposed.

Anyway, the only way this topic will move forward is when somebody actually 
does something. Talking about a wonderful abstraction layer is interesting 
but not sufficent.

Jono, are you willing to work on that ?


An open source OS for contactless Smart Cards - Jayacard 

More information about the xdg mailing list