Introduction and toolkit abstraction

[Philippe Fremy]

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

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 
open dialogs
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
> in?

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

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

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

With the KDE 4 coming, we have the opportunity to let this enter one big 
desktop quickly.

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

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 
this: http://wiki.kde.org/tiki-index.php?page=KIO+Fuse+Gateway

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

To answer the question thoroughly, I think a C interface would be ok for 
everybody.

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

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.

	cheers,

	Philippe

-- 
An open source OS for contactless Smart Cards
http://www.jayacard.org - Jayacard