Introduction and toolkit abstraction

[Jono Bacon]

Hi,

>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.
>  
>
This is exactly the idea. It is a case of looking for commonality 
between applications and applying native resources to these features.

>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).
>  
>
Agreed. I think that although menus are different, they are not *hugely* 
different in the eyes of the user. If the same theme is applied menus 
will look quite similar. The difference with these dialogs is that the 
entire interface is different.

>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.
>  
>
This would be something for the future. I am less inclined to persue a 
"lets create an entire standard and expect everyone to use it" - this 
will not work in the eyes of UI design as KDE and GNOME are too 
different, and ROX is even more different.

>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.
>  
>
Are these buttons added as two buttons or are they added as a special 
button arrangement? If they are added as an arrangement, we could 
abstract the arrangement in the common toolkit resources library so KDE 
could switch them around. There are obviously geometry issues here, but 
this could be further explored.

>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.
>  
>
I never knew this - how did the author implement this?

>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.
>  
>
This is exactly what I was thinking. If we are defining a 
freedesktop.org platform, we would create this small library to 
dynamically link to. I may be wrong with this assumption, but I assume 
that this library would simply act in a similar way to an old telephone 
operator - patching in a request from an application to use a native 
resource. It would not be a case of reimplementing Qt or GTK code, just 
a case of indicating which resource should be loaded from which toolkit.

>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).
>  
>
I am not hugely knowledgeable in this area, but isn't the GNOME-VFS 
accessed when the GNOME dialog is loaded and the kioslaves accessed when 
the KDE dialog is loaded? With this in mind, the user will simply use 
the native system that is accessed by the native dialog.

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

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

>>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.
>  
>
Agreed. Although some applications will look less unified than others, 
this does not mean the effort is worthwhile. In terms of UI conformance, 
OpenOffice.org is not hugely different to a KDE or GNOME app. I am 
pretty sure a user in either environment can use OpenOffice.org 
reasonably well. The issue with different file dialogs is that it *does* 
make the interface less uniform and compliant. If we are using standard 
themes and native dialogs, this will make a heck of a difference in the 
usability of most applications. Sure, not everything will fit, but I am 
interested in the big applications looking more uniformed, and the big 
applications are typically written for KDE/GNOME or in Qt/GTK.

>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.
>  
>
Exactly. With freedesktop.org I think we need to fill in as much of the 
picture as possible. If we have a shared trash can implementation, 
clipboard and other features, it can appear that KDE and GNOME 
applications are fairly unified - until they actually try to load a 
file. Ideally the user should not need to know that GIMP is a GTK/GNOME 
application and Quanta is a KDE application and that Scribus is a Qt 
application. The user should not need to care about these issues - 
recent distributions try to hide these issues with unified theming - the 
next step is the ideas we are discussing.

Now, I don't have much experience coding GTK software and I have *some* 
experience with KDE and Qt code. I would be interested in discussing the 
possibility of starting work on a library such as this. Would anyone be 
interested in contributing? Do we have the right knowledge between us to 
mock up a prototype?

    Jono

-- 
Jono Bacon - http://www.jonobacon.org/
Writer / Journalist / Consultant / Developer