KDE vs. native/Qt file dialogs

[René J.V. Bertin]

On Thursday January 5 2017 01:51:47 Sven Brauch wrote:

Edit: oops, this message was never sent...

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

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