Review Request 126876: Fix QFileDialog::openUrl() for remote files
Kåre Särs
kare.sars at iki.fi
Mon Jan 25 10:24:14 UTC 2016
> On Jan. 24, 2016, 10:01 p.m., David Faure wrote:
> > src/platformtheme/kdeplatformfiledialoghelper.cpp, line 195
> > <https://git.reviewboard.kde.org/r/126876/diff/1/?file=439596#file439596line195>
> >
> > Yes, this definitely looks like it should be fixed in Qt instead (and this code can be kept with a #ifdef QT_VERSION if you want).
> >
> > The method is called setDirectory, I expect it to get a directory.
>
> Kåre Särs wrote:
> OK, but what whould I put as QT_VERSION? ;) The bug is present in at least Qt 5.5.1. I have not tried with the Qt 5.6 branch.
>
> I wonder if it is actually fixable in Qt. How does Qt determine what is a file and what is a directory? What if you name a directory "foo.doc" and you cannot use QFileInfo::isDir() on it.
>
> David Faure wrote:
> Sure, but how do we end up with a file passed to setDirectory? The API (e.g. getOpenFileUrls) takes a QUrl dir, surely that's supposed to be a dir. Is that where the file comes from? Or is QFileDialog getting confused somewhere? I just don't see why we have to determine "is this url a file or a directory" when the API is clear about the directory argument. But I assume I'm looking at the wrong place, setDirectory is also called with some other URL?
> I'm asking for some debugging inside Qt, to find out how we end up with setDirectory called with a file URL, and then if it's indeed a bug in Qt fixing it there, and only then this will answer the QT_VERSION question ;)
Now that I read the documentation again I don't see any mention of it, but if you provide a local file url to getOpenFileUrls()'s dir parameter it will open the directory of the file and pre-select the file. While this works for local files it does not work for remote protocols.
I looked into this last night for a couple of hours, but I have not dug deep enough to find it. I do suspect that this maybe hidden feature just can not work for remote protocols and that the "fix" has to be in the integration.
- Kåre
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126876/#review91545
-----------------------------------------------------------
On Jan. 24, 2016, 9:19 p.m., Kåre Särs wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126876/
> -----------------------------------------------------------
>
> (Updated Jan. 24, 2016, 9:19 p.m.)
>
>
> Review request for KDE Frameworks, Alex Richardson and David Faure.
>
>
> Repository: frameworkintegration
>
>
> Description
> -------
>
> This fix is a bit like Alex Richardson workaround in KIO (https://git.reviewboard.kde.org/r/126831/), but in frameworkintegration in stead (I did not see his/Your KIO fix before now...)
>
> I check the remote url in setDirectory() because setDirectoy() is called from two places.
>
>
> Diffs
> -----
>
> src/platformtheme/kdeplatformfiledialoghelper.cpp 11e7efb
>
> Diff: https://git.reviewboard.kde.org/r/126876/diff/
>
>
> Testing
> -------
>
> Kate now happily opens local and remote folders :)
>
>
> Thanks,
>
> Kåre Särs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160125/7d6fb698/attachment-0001.html>
More information about the Kde-frameworks-devel
mailing list