Introduction and toolkit abstraction

[Alexander Neundorf]

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

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 
this currently.

Bye
Alex
-- 
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