[KDE/Mac] Native file dialogs (was: What is happening to the KDE/OSX themes?)

[Ian Wadham]

Hi René, Nicolas and Marko,

On 21/10/2014, at 6:09 PM, René J.V. Bertin wrote:
> Quickly: yes to what you *think* I was saying (apparently in double-dutch?)

That's a bit politically incorrect, but I guess *you* are allowed to say it… :-)
I would say something like "triple-geek"… :-) But I guess I worked it out… :-)

> I'd appreciate you having another look at the Q/KFileDialog thing. I
> haven't done that myself because KFileDialog seems to be more than a
> *simple* wrapper around QFileDialog, and I didn't want to drop the
> option to instruct apps to use non-native dialogs through their .rc
> file.

Which .rc file exactly?  AFAIK, the only "native" option is in kdeglobalrc.
I do not know of any apps that have an option to override that in their own
Settings dialog.

First impressions, from studying the code for KFileDialog and friends:

- Most of the code for switching to a native file dialog is already in
   KFileDialog… at least for the commonly-used static methods, such
   as static QString KFileDialog::getOpenFileName(...).
- It works if you set Native mode, but fails and switches to KDE mode
   if it gets passed a "startDir" parameter of "kdefiledialog:///something"
   or anything that does not look like a local directory.
- Qt 4's QFileDialog supports only local directories and files.
- Qt 5's QFileDialog will support remote directories and files, via methods
   that have "Url" in the name.
- KDE 4's KFileDialog already supports remote directories and files, via
   methods that have "Url" in the name.
- The "kdefiledialog:///something" parameter is a trick to get kdelibs to
   remember and automatically re-use recently-used directories.  We
   would need to check for that and do some evaluation of it before
   attempting to use QFileDialog.  It is probably a major reason why we
   are getting a mix of KDE and native dialogs on *local* file lookups.
- Some KDE apps do not use the static methods, but create their own
   KFileDialog object (Dr Konqi is one, but I also noticed Calligra and
   some KDE edu applications).
- I do not know yet how a roll-your-own KFileDialog object will perform
   regarding Native mode… but, one step at a time… :-)
- The "patch-nativeDialogs" file ensures that Native mode is used as a
   default, if there is no value for that setting in the KDE Globals rc file.
- It also enables and compiles some additional processing (in exec()),
   which is used in Windows too.  Normally KFileDialog does not
   re-implement exec(), but uses the one in its ancestor (KDialog::exec()).
- I have not yet worked out exactly what this extra processing does,
   but it would certainly constitute whatever the difference is between
   using the patch or just setting Native mode by hand.
- David Faure's deprecations apply to the static methods, in favour of
   equivalent Qt5 QFileDialog methods and there is a general deprecation
   of KFileDialog itself in favour of QFileDialog, but no other specifics.

Conclusions:

- We can get native dialogs for all *local* directory and file lookups
   where the static methods of KFileDialog are used, as long as we do
   something about "kdefiledialog:///something" parameters.
- These should function in the same way in apps that get ported from
   KFileDialog to QFileDialog, by KDE developers for KF5.
- When KDE 4 apps use static methods to request remote directories
   and files, we are forced to use the KDE dialogs.  When those apps are
   ported to Qt 5's QFileDialog, I expect we will get native dialogs.
- KDE 4 apps that roll their own KFileDialog are an unknown quantity.

I will soldier on… :-)

Cheers, Ian W.