Somehow I missed this: digikam has stopped using native (on Mac) and KDE (on Linux) dialogs in 5.7.0 . Instead it now uses Qt's dialogs, meaning the lowest common denominator functionality-wise, and the worse possible choice for aficionados of optimal platform integration. This looks like it might be due to a wrong choice in dfiledialog.cpp, i.e. `options |= QFileDialog::DontUseNativeDialog;` instead of `options &= ~QFileDialog::DontUseNativeDialog;` but even when I make that change I keep getting Qt file dialogs. What am I missing here?
A new option to use native file dialog is available in Setup/Miscs/Behaviour section. It have been introduced in next 5.8.0. You can test with current pre release bundle : https://files.kde.org/digikam/ Gilles Caulier
Dang, another case where searching with the appropriate terms didn't take me to the existing bug report! I found the commit and it applies to the 5.7.0 source. The only thing one could still want is a build option to make native dialogs the default behaviour, but maybe that's already implemented too (and hidden in one of the numerous "upgrade" commits)? I cannot really think of a situation where you'd NOT want to use the native dialogs. You'll still get the Qt dialogs if those are all that's available, while if you have a plasma/platform integration plugin installed you get the KDE file dialog. I'm guessing that you can set things up in such a way that you always get the KDE file dialogs too, even on Mac and MS Windows. The choice between those and the real native dialogs would make more sense, IMHO. On Mac at least the KDE dialogs provide a lot more features lacking from the native dialogs.
Unfortunately, there are distributions with native GTK file dialogs, which lead to a crash of digiKam when calling. Since the chances are somehow small that this will be fixed, we have built in the possibility of pure Qt file dialogs. Maik
I don't really see how that excludes the possibility to bring the default under control of a build option. That option could be off by default itself, or do some fancy kind of detection if the user doesn't specify a value for it. But the bottomline is that those distributions will have the possibility to build the application with an appropriate default. You say so yourself, you provide a possibility to use Qt file dialogs. That doesn't mean it has to be the default. BTW, are you talking about desktops that use the gtk3 QPA? You can detect the name of the platform being used at runtime and use that to decide what the default should be, too.
BTW, are you talking about desktops that use the gtk3 QPA? You can detect the name of the platform being used at runtime and use that to decide what the default should be, too. ==> definitively no. It's not the goal to the client application to do this job. If we need to do it in all case that desktop type need to be checked. we will make a big puzzle and it will be the heel to maintain. Typically, a pure Qt application is the way to go in a near future. A huge application as digiKam do not be relevant of any desktop technonlogies at all. So the default behavior is enough and perfect for me... Gilles Caulier
That *is* a bit like dumping all SIMD and other optimisations and just use good old software of all algorithms because that's so much easier to maintain (and the result will perform and look similarly mediocrely everywhere...)