Introduction and toolkit abstraction
neundorf at kde.org
Tue Sep 14 21:13:32 EEST 2004
On Wednesday 01 September 2004 12:03, you wrote:
> >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.
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.
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
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.
> >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.
> 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
Work: alexander.neundorf at jenoptik.com - http://www.jenoptik-los.de
Home: neundorf at kde.org - http://www.kde.org
alex at neundorf.net - http://www.neundorf.net
More information about the xdg