Introduction and toolkit abstraction
m.hearn at signal.QinetiQ.com
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
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
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
for the GTK API. Qt/KDE has something similar.
More information about the xdg