[file dialogs] Re: Redefining kdelibs and kdebase
kuba at mareimbrium.org
Wed Aug 31 17:21:49 BST 2005
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
> 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
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
More information about the kde-core-devel