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