Discussion:
KDE vs. native/Qt file dialogs
René J.V. Bertin
2017-01-04 22:32:29 UTC
Permalink
Hi,

This came up thanks to a recent commit to KDevPlatform (8830685c). There are now 2 locations where the KDE_FULL_SESSION env. variable is used to determine whether or not the KDE file dialog should be used.

I find that a bit misplaced as that dialog doesn't have anything that links it so tightly to KDE sessions that it is misplaced everywhere else. Rather, it has a number of features that I find quite useful also on Mac, esp. when opening a project. For one, the Mac-native file dialog doesn't allow selecting a Make/CMake/QMake/.kdev4/etc file, at least not when there is already a .kdev4 project in the directory.

What do others think? Customised open/save dialogs are not uncommon on neither Mac nor MS Windows, and the KDE dialog works fine with the native macintosh style (I can't check on MS Win.). Would there be demand and support for making the KDE file dialog available as a build-time option, or maybe even as a runtime preference (like OpenOffice/LibreOffice does)? In the latter case one could link the initial/default setting to KDE_FULL_SESSION.

One could also just set KDE_FULL_SESSION but from what I've seen that variable is used in a few locations to control features that are best left off when you're not running a full KDE session.

R.
Sven Brauch
2017-01-05 00:51:47 UTC
Permalink
Post by René J.V. Bertin
What do others think? Customised open/save dialogs are not uncommon
on neither Mac nor MS Windows, and the KDE dialog works fine with the
native macintosh style (I can't check on MS Win.). Would there be
demand and support for making the KDE file dialog available as a
build-time option, or maybe even as a runtime preference (like
OpenOffice/LibreOffice does)? In the latter case one could link the
initial/default setting to KDE_FULL_SESSION.
The dialog is ok on Linux but on Windows, it's quite terrible. It has
none of the favourites you expect it to have, and instead has lots of
custom ones; plus it looks and behaves completely different from the
rest of the OS. Let's not use it on Windows.

On Linux I agree that it's far better than the other available options
(esp. the default Qt dialog, but also the GTK3 one is quite annoying).

Greetings,
Sven
René J.V. Bertin
2017-01-05 09:00:58 UTC
Permalink
PS: the only use case (in KDevelop) where I do prefer the native Mac dialog is selecting a directory, e.g. the build directory for CMake projects. In that case the simplicity of the native dialogs allows me to go faster even if I often get hindered by the fact they treat symlinks to directories as symlinks (and date-sort them according to the symlink mod. date, not the target's).

But I don't see that dialog being governed by KDE_FULL_SESSION so the reason I get the native version is elsewhere.
René J.V. Bertin
2017-01-06 08:39:36 UTC
Permalink
On Thursday January 5 2017 01:51:47 Sven Brauch wrote:

Edit: oops, this message was never sent...
Post by Sven Brauch
The dialog is ok on Linux but on Windows, it's quite terrible. It has
none of the favourites you expect it to have, and instead has lots of
custom ones; plus it looks and behaves completely different from the
rest of the OS. Let's not use it on Windows.
I'm pretty sure favourites work on Mac, though that may of course have to do with the way I build KDE in general. These do sound like things that should be reported; KIO is supposed to work on all major platforms. Ensuring that a central widget looks and behaves good across the board seems like a reasonable thing to expect. CC'ing David for that reason.
I guess the native windows "Open Project" dialog will allow selecting files without having to request that specifically when opening the dialog? Native Win32 file dialogs also have a lot of the features that are missing from Mac file dialogs (I always thought GTk/KDE/Qt copied those features from Win32).

The look is quite different from the native dialogs on Mac too, but in itself that is not uncommon. It's also not evident at all for Qt-based applications to hide the fact they're cross platform, probably not without doing significant Mac-specific tuning. There's no shame in that, and I think most all Mac users use at least 1 application that looks a bit off here or there. We're also talking about an application that is aimed at power users whom we should expect to be capable to make their own trade-off between form and function. And there's a *lot* of additional function that the native dialogs don't have. And FWIW, even Qt's native file dialogs look slightly off and behave slightly differently than those you get in truly native applications. I think I understand why that is but it's not very relevant here.
Post by Sven Brauch
On Linux I agree that it's far better than the other available options
(esp. the default Qt dialog, but also the GTK3 one is quite annoying).
I read that as "all Unix/X11" platforms, and a solution with a CMake option to fix the choice at build. A priori I'm fine with that.

R.

Loading...