[file dialogs] Re: Redefining kdelibs and kdebase

[Christoph Cullmann]

On Wednesday 31 August 2005 13:39, Jarosław Staniek wrote:
> 1. A bit harder case: a KDE app running under GNOME needs to perform a
> *dynamic* switch to non-KDE file (and print?) dialog. What about trying to
> dlopen a gnome library for this (it's in C, so it's pretty safe).
>
> 2. A simple case: win32 or Mac. We're just using native set of dialogs.
> *Always*. That's why I prefer to have a set of static functions. You could
> say "but there're not all replacements for these native targets". Eg no
> KURL combos with history and IO slaves. IMHO this is just Linux' selling
> point because it has more powerfull functionality here.
I just have to say: no, why to do this, once again, than for example all our 
special IO slave url's won't work any longer. Kate would be crippled while 
using gnome, and how to detect that in the app? Should I inform the user: oh, 
you use gnome, sorry, nothing works? Or should I open the kfiledialog if I 
need url's gnome doesn't support?

Beside this, still the issue that many apps use inherited and manipulated 
filedialogs is just put aside, why all do this? And your embedding of the 
native dialogs sound nice, but they use a complete different HIG, you can't 
control them in any fine-grained manner, that will just cripple whole KDE 
just to have native dialogs on windows, which, IMHO, is just none-sense, if 
the whole app looks different on windows, because of our HIG and all, why 
make the filedialogs native?

cu
Christoph