Introduction and toolkit abstraction

Mike Hearn m.hearn at
Wed Sep 1 15:53:48 EEST 2004

> This sounds like the right plan. If we were to begin small and only 
> implement core features such as the dialog boxes, this abstraction layer 
> can be expanded where needed.
> The question is how do we map from one toolkit's dialog box to another? 
> Would we literally map arguments from one toolkit to another or is there 
> a better way of doing it?

I'm afraid it's not that simple. Here is the API docs for the new GTK 

here is the Qt docs:

Immediately you can see some big differences. Both support the concept 
of filtering, but in Qt you set them by using magically formatted 
strings, whereas the GTK+ API is more explicit and has a dedicated 
GtkFileFilter object.

The GTK file dialog also has features the Qt dialog does not. For 
instance GTK can filter based on MIME types, whereas Qt cannot.

Here is the KFileDialog which is (like many KDE classes) a heavily 
modified version of QFileDialog:

KFileDialog *can* filter on MIME types but the explicit API format for 
it is deprecated and they overload the string formatting system used by 
Qt further.

Both the KDE filepicker and the GTK filepicker can work in terms of URIs 
but the format used isn't standardised. GTK/GNOME correctly uses 
file:/// to refer to local files, whereas KDE uses "file:/" which is 
perhaps more aesthetic but is also non-standard.

Sorting that out needs to be done anyway though.

So you see my point. You can't just map one to another, they are too 
different. Any such abstraction library would have to pick a subset of 
features that all the targets supported, then wrap the APIs in such a 
way that you don't expose any KDE/GTK specific machinery. Developers 
would lose non-standard functionality, but would gain consistency.

> How do apps customise the dialog other than setting the dialog label and 
>  wildcards?



for the GTK API. Qt/KDE has something similar.

thanks -mike

More information about the xdg mailing list