Introduction and toolkit abstraction
phil at freehackers.org
Wed Sep 1 11:13:10 EEST 2004
> > 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
I think the wording is not correct. Toolkit abstraction means that the whole
toolkit would be replaced by a wrapper. For this, there is already
Let's word it something like "common toolkit features".
This is a great idea.
Bascially, if we take a KDE applications or a Gnome application, we can
divide it in two parts :
1. some dialogs that are just very simple calls to the API, like the file
2. complex widgets usage that are the core of the application
The second part can obviously not been changed without messing with the
whole toolkit. But the first part can be adapted to the local running
desktop quite easily.
If we take for example a Gnome desktop user, who runs from time to times one
KDE application. The application really looks foreign in its desktop. The
file dialog is completely different, the theme might be too. To reduce this
sensation, we can make the theme common, with things like gtk-qt themes
(http://www.freedesktop.org/Software/gtk-qt), but we could also make the
file open and file save dialog common.
Now, the application would still be different. The menu entries are slightly
different betwen KDE and Gnomes and I believe the layout too. But this is
enough for most users. Developers tend to think in terms of features, and
not worry about the look. Most users tend to think in term of look and
won't bother with slightly different menu entries. Winamp was a huge
success on windows for its skinnable interface although the player itself
is not extraordinary (and poorly skinnable in my opinion).
The menu thing could be solved further if we manage to have common HIG or
with an abstraction level of where to put the setting and things like that
but this is more complicated.
Even for dialogs that are not standard, one could imagine the toolkit
detecting the current running desktop and switching the ok/cancel button
order to the toolkit's default choice.
Think also about appliations like sodipodi (and maybe gimp) that want to
stay desktop neutral, although they are using Gtk. The sodipodi author took
extra steps so that he could use the KDE file dialogs if the application is
running under KDE.
> But is it really worth the immense amount of complexity that would bring
I think the complexity is not that big and the result is worth it. And with
Novell/Suse pushing two desktop at the same time, we can surely get some
> Two main loops?
This has already been solved. By the sodipodi author at least, and with some
help of KDE people. I cc Alexander Neundorf which I believe has been
working on this in the past.
> Two *huge* sets of libraries pulled in?
The idea would be to have a shared library that is responsible of all the
work. The library would automatically detect which desktop is currently
running. It would then _dynamically_ load the right toolkit dialog and use
Gtk and Qt would just have to provide a configuration flag at compile time
to say whether they want to link to this common library. It would not add a
dependance on Gnome to KDE and on KDE to Gnome.
I remember that Mathias Ettrich had already something like that in mind, so
that Qt application use KDE's file dialogs in KDE. This is only one step
With the KDE 4 coming, we have the opportunity to let this enter one big
> Would the KDE dialog in GNOME use kioslaves or gnome-vfs?
That's a tricky question. My answer would be that the dialog use its native
file system abstraction. If the user is running Gnome, he is used to the
Gnome vfs system and would expect it to work in the file gnome open dialog
eventhough he is running a KDE application (something he might not be aware
Now, if the application depends specifcally on kioslaves, then obviously,
this is not a standard dialog and it can not be shared. Except if we use
I am sure that there are more technical questions (encoding of the name of
the returned file ?) but we can all work them out.
> 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?
This does not fit in the things that can be shared at this point. If KDE and
Gnome finally find a way to store their config files in a common way, with
something like gconf, the linux registry or something else, it could be
available. But I don't see it happen before a few years.
> 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?
That would still be left to the application. The idea is to share only the
minimum that can be. As both KDE and Gnome (and rox, xfce, gnustep, ...)
move forwards with freedesktop, more can be shared.
> What language is this toolkit in that people will get religious over?
Since the toolkit is really just calling this library, the language issue is
far less religious. It would be completely transparent to the KDE/Gnome
To answer the question thoroughly, I think a C interface would be ok for
> 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.
I don't share your opinion on this. I am sure that a KDE user would be
delighted to have a KDE file dialog when he uses gimp and that a Gnome user
would be delighted to have a Gnome file dialog when he uses, uh, let's say
Of course, OpenOffice will remain OpenOffice, but if the printing dialog is
the KDE one, it is a lot better.
For the distant future, I envision this : each KDE or Gnome application
could be defined as a raw widget without border, menu and toolbars, but
with a xml file describing what those are. The current running dekstop
would read a xml file for this application and dynamically create the menu
entries and toolbar in the current desktop style, apply the current desktop
theme, provide the current desktop common dialogs and embed the widget with
GtkSocket or QXWidget. When a menu is pulled, the desktop inform the
application with a DBUS call and the application can also control its
appearance with another DBUS call.
I think we have the capabilities to keep linux diversity (dekstop, themes,
applications) but provide it in a uniform way to the user. That's exactly
what freedesktop is about.
An open source OS for contactless Smart Cards
http://www.jayacard.org - Jayacard
More information about the xdg