Created attachment 104682 [details] introduce compile-time selection of the file dialog implementation I think this topic has come up on the ML already, but it caught my attention again: KDevPlatform currently uses the KDE_FULL_SESSION variable to determine whether or not it should use KDE file dialogs instead of "native" ones (read: Qt's implementation of actual native dialogs). I find this a bit silly for several reasons: - both types of dialogs have their pros and cons, with the KDE dialogs having considerable advantages for developers over the native Mac dialogs, in my experience. KDevelop users ought to be perfectly capable of making their own informed choice which they prefer. See also https://bugs.kde.org/show_bug.cgi?id=371525#c1 . - the main platforms for which the distinction was probably introduced both allow users to set that env. variable (this is what makes the implementation silly in my opinion). I'd propose 2 alternative solutions: - make it a build-time choice via a CMake option with the default set to match the current behaviour. That's the simplest option which basically turns runtime ifs into compile-time #ifdefs. - make it a runtime user choice, with an option in the "User Interface" config panel. Not unheard of esp. in complex, multipurpose workhorses (you'll find such an option in Open/LibreOffice). I'll attach a patch for the 1st alternative and am willing to look into the 2nd.
> KDevPlatform currently uses the KDE_FULL_SESSION variable to > determine whether or not it should use KDE file dialogs instead > of "native" ones (read: Qt's implementation of actual native dialogs). That is not correct, on GNOME it would e.g. use the GNOME file dialog. The Qt ones are just the fallback in case there is no QPA plugin requesting something else. The env var stuff is not meant as a choice for the user; it is detecting whether we can embed the KDE dialog, or whether we have to fall back to the native dialogs because the KDE one looks out of place. I do not think we should offer users a choice on what file dialogs to use in our application, neither compile- nor runtime. This choice has to be made on the QPA plugin level.
+1 to what Sven said.
Does Gnome provide a QPA platform plugin akin to the plasma-integration plugin? The env. variable may not be meant as a choice for the user, but it sure can become one for the typical KDevelop user. Who probably couldn't care less if the dialog looks different: if it provides features that are more in line with his/her use of KDevelop different looks aren't out of place. It's not up to individual applications to protect users from doing something different, or to do what I call dictating the emperor's clothes. Anyone who wants can use different widget styles with any application, and that shouldn't be thwarted. Indeed, the choice of filedialog can be made at the QPA plugin level, but not all platforms have such plugins, or make it easy to use one (and not because it's forbidden by Qt). Mac and (probably) MS Windows are examples. I cannot speak for MSWin, but I don't feel the KDE dialog looks out of place on Mac. It looks a bit different the way all KDE software looks with a pure native style without support for KDE's font roles, but the Mac OS has seen file dialog customisation (hacked or via system APIs) probably for longer than KDE has been around. I think I mentioned the following when the topic came up earlier: I maintain a KDE platform plugin for Mac, so that KDE applications can look the way they're designed to look, whether that's using the Macintosh style, Breeze, QtCurve or anything else. That QPA plugin does in fact instruct Qt to use native file dialogs by default, because I happen to prefer them for simple applications. For KDevelop the native dialog is no match though, esp. not when opening files or even more so, importing a project. And again: they only look like native dialogs. PS: KDE's QPA plugin doesn't use KDE_FULL_SESSION, AFAIK.