On 2015-04-02 10:38, René J.V. Bertin wrote: > On Thursday April 02 2015 09:46:29 Matthew Woehlke wrote: >> It may be too late to change this for Qt 4, but please, let's get it >> right for Qt 5 :-). > > With KF5 aiming to be "just" a modular set of extensions to Qt 5, why > not leave it like that, and just push the KDE devs to implement the > file dialogs in something that's reasonably small and standalone?
Do you honestly expect that every Qt install on a Linux-based platform will also have the base KF5 libraries installed? Even on a machine that is otherwise running some other desktop (Gnome, XFCE, etc.)? (*Especially* on a machine that only has Qt installed because of some one-off application?) I don't find that reasonable. Nor does it help anyone who, for whatever reason¹, is disabling use of native dialogs. In short, I don't see this as a solution unless it *replaces* QFileDialog. (¹ And there *are* legitimate reasons. Some applications may need the ability to tweak the dialogs or their behavior. I've seen some do it just for cross-platform consistency.) > Adding specific code to an extension library is usually preferable to > patching Qt ... There may be cases in which I would agree with that statement. This is not one of them. This is *not* a bug that is specific to Linux. It affects all platforms that do not replace QFileDialog with a platform native dialog, whether because such is not available, or because the user has disabled the native dialogs for whatever reason. It's not a platform issue, it is a defect in QFileDialog. Patching Qt is the *exact right* thing to do in this case. Instances where the patch are not appropriate are instances where the code shouldn't be executing in the first place². (² Maybe this means that the code change should check that the built-in dialog being used, and not a native dialog. That would make sense, and I would have no objection to having the change only apply in that case. The code change still needs to be made in Qt itself, however; the case that does not work is the case where an extension library is *not* in play.) -- Matthew _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
