Introduction and toolkit abstraction

[Sean Middleditch]

On Tue, 2004-09-14 at 20:13 +0200, Alexander Neundorf wrote:
> On Wednesday 01 September 2004 12:03, you wrote:
> > 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

You've obviously not used the APIs in question, then.  There is a lot of
work involved in doing even something like selecting a file.  What is
the default path?  What file types should be displayed?  Preview widget?
Any extra options in the dialog?  Selecting a file or a folder?  Save vs
load?  Will the GTK+ dialog allow users to browse using KIOSlaves so KDE
apps can save files there?  Will the Qt/KDE dialog allow users to browse
using gnome-vfs so GNOME apps can save files there?  Will the GTK+ file
dialog swap buttons around to the Windows layout so that the dialog
matches all the custom dialogs in a KDE app, and will the KDE dialog
swap its buttons around to the GTK+ way so it matches all the custom
dialogs in a GTK+ app?  Is the new API going to be in C or C++, or in
other words, is this new library only going to be used by GNOME devs or
KDE devs?

Nobody is putting even an ounce of actual thought into this cross-
toolkit nonsense, and just spouting off some lofty abstract ideas based
on very little fact or experience.

If you want the two apps to look and act similar, just bloody well make
them look and act similar.  You can patch GTK+ to have its file dialog
look like the KDE dialog; that would, unlike the abstraction library
idea, actually work, and it's be a lot easier to boot.  You can do the
same thing with KDE/Qt.  Just modify/update all the standard dialogs
(including those in extra libraries, like libgnomeprintui) and you'd be
all set.

> > >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.
> 
> I had a look at some gtk apps, if I remember correctly it was mainly xmms.
> gtk doesn't have a simple convinience file dialog function ( at least the gtk 
> version I looked at), and it seems common that gtk apps access stuff inside 
> the gtk file dialog directly. So simply replacing the static 
> gtk_give_me_a_file_name() with QFileDialog::getFileName() isn't not directly 
> possible in most cases.

XMMS uses GTK+ 1.2, which hasn't been in development for years.

GTK 2.0-2.4 (iirc) still used the old nasty file dialog "API," although
GTK+ 2.6 and onward has a much nicer and properly abstracted file dialog
API.

> 
> My conclusion was basically that the most realistic way would be to chose the 
> most common apps from the other framework (for kde this would be xmms, 
> sodipodi, gimp, ... , for gtk this would be k3b, scribus, kdevelop,... ) and 
> directly try to get patches in which support the dialogs from the other 
> toolkit.

Even then you have big problems without adding a lot of work to the mix.
For example, integrating main loops.  And the fact that the dialogs
often expect the app to use most of the same support code for VFS
access, printing, etc.

> 
> Having an abstraction lib even for only some dialogs won't become a real 
> success, I'm afraid. Every toolkit will still have its own unique features, 
> and the developer working with this toolkit will probably prefer to use the 
> advantages of his toolkit instead of using the wrapper function which provide 
> only the lowest common denominator.

*bing*  Thank you.  ;-)

> 
> ...
> > >Of course, OpenOffice will remain OpenOffice, but if the printing dialog
> > > is the KDE one, it is a lot better.
> 
> Yes, OOo is one of the most important single apps.

There are already modification to OOo to get it to use GNOME dialogs.
Getting it to use KDE dialogs really shouldn't be any harder.

> 
> > 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?
> 
> There is a ctd cvs module in fd.o, and I would be happily hand over admin 
> rights to you if you are interested. I don't have the time to do much for 
> this currently.
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.