[Development] Why is QTBUG-27186 closed?

Matthew Woehlke mw_triad at users.sourceforge.net
Thu Apr 2 17:58:58 CEST 2015


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




More information about the Development mailing list