[file dialogs] Re: Redefining kdelibs and kdebase

[Kuba Ober]

On Wednesday 31 August 2005 07:39, Jarosław Staniek wrote:
> Stephan Kulow wrote:
> > Am Samstag 27 August 2005 14:36 schrieb Anders Lund:
> >> On Saturday 27 August 2005 14:26, Clarence Dang wrote:
> >> > the file view is inconsistent with Konqueror's - as is ark's,
> >> > standalone KFind's, Kate's file lister,...
> >>
> >> In most places KDirOperator is used (the file dialog, kate and any app
> >> that copied kates directory view, and more). If konquerors view can be
> >> used with a comparable speed and with a resonable set of features, it
> >> should be (moved and) used by that class.
> >
> > So we have two different trends here? One side (let's name them Qt
> > maintainers) support KDE's future as least common dominator that Qt can
> > easily replace or use. And another side sees rather more connection
> > between konqueror and the file dialogs? Did I summarize correctly?
> >
> > I find it hard to believe that we can hook the KDE file dialog into
> > Windows applications not written for KDE.
>
> Absolutely, this sounds like a nonsense.
>
> > So without that, you would
> > always have KDE applications use another file dialog than any other
> > application on windows. Not sure that's appealing - even if the KDE file
> > dialog might have more options. On the other hand, not allowing
> > customizing or embedding the file dialog because it might break for use
> > on non-KDE desktop shells sounds broken as well. So what do we do here?
> >
> > I suggest we leave KDE file dialog in kdelibs but in a special library
> > (libkfile sound good, no? :) allowing custom use as currently and
> > applications using only the static functions to get a file name will use
> > the out of process file dialog pre forked without needing to link to
> > libkfile (as the static functions would stay in libkio).
>
> In general I couldn't see better solution than using as much static
> functions as possible. In the past I tried to wrap QFileDialog look&feel
> within a KFileDialog API (filters definitions were translated from KDE
> world to Qt3 world and so on).
>
> A main goal to do improvements in this department for KDE4 could be to
> avoid a need for #ifdefs in applications code at all and avoid forcing
> developers to think about possible problems could arise under other
> environments.
>
> First let's talk about a situation when a developer doesn't want to (a)
> *embed* as a subwidget or (b) *customize* file dialog (usually by inserting
> custom widgets)
> Hmm, then there're harder and simpler cases:
>

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

While I think that this all looks nice on paper, I don't really think that 
letting kde application use non-kde "native" dialogs has much merit. Thinking 
in this direction quickly gets you overboard and a kde application becomes 
crippleware, because there's little of "kde" left in it.

I do think that at least as far as windo$e is concerned, it's doable to 
implement extra functionality in the kde dialog to use platform features such 
as shell extensions and whatever other "new technologies" they cram into the 
file selector dialog.

It could be also doable for other platforms.

But I don't think it makes sense to cripple the functionality provided by kde 
in order to use some dubious features that the native platform offers. The 
only notable exception to the "dubious" may be finder interface on macs, but 
then again it should be doable to embed it in otherwise normal kde dialog. 
Those would be optional things to be implemented as time permits, though, 
i.e. making the kde dialog provide the "native" functionality if such 
"native" stuff is really a must have on given platform and not otherwise 
available in kde.

It seems only logical to me to have kde provide more and better functionality 
than all the "native" platforms, and stick with that. Assuming that &%@#!^*$ 
software patents won't encumber implementing some of it, of course. But 
that's not much we can do about besides taking it up with our 
representatives/senators/you name it.

Maybe it'd be nice to come up with a list of features that current kde dialogs 
don't offer and that are provided by native platforms. I'd start with 
following:
1. shell extensions on windo$e, which probably should be wrapped at a lower 
lever anyway (i.e. so that the desktop, konqui, icon/list views *and* dialogs 
would all see it)
2. finder interface on macs

Over time, it's imagineable that some of kde's features can be made available 
to the underlying platform, i.e. exporting .desktop stuff via shell 
extensions in windo$e so that right-clicking on a file in konqui and in 
explorer would yield similar views. But that'd be the last thing I'd worry 
about.

Cheers, Kuba