[file dialogs] Re: Redefining kdelibs and kdebase

[Jarosław Staniek]

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.

Re embedding as subwidgets: I am not sure all features can be provided by
static functions and still work flexible. For example, on win32, the
solution could be to fall back to a file dialog implemented in Qt, so we
can have QWidget* in hand, enabled preview pane, and maybe something more.
If we can use a static functions:

//KFIleDialog doesnt inherit QFileDialog, so we're just keeping a QWIdget*
QWidget* w = KFileDialog::create( parent, args )
KFileDialog::setContentsPreview( w, args );

and so on...

Other proposal could be to use a clean KFileDialog container class as
something like this:

class KFileDialog : public QObject {
public: //.....
        QWidget* widget() const; //a real widget representing the dialog
                                 //(we do not assume what it is
        setContentsPreview( args ); //this will work or not, depending 
                                    //on the current env. 
                                    //-you shouldn't care
signals:
       //... some of them can work depending on the env.
slots:
       //as above
};


*RFC*

--
Jaroslaw Staniek