Fix QFileDialog::openUrl() for remote files
Review Request #126876 - Created Jan. 24, 2016 and submitted
Qt does not know if the remote URL points to a file or directory. that is why options()->initialDirectory() returns the full URL even if it is a file. 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.
Kate now happily opens local and remote folders :)
OK then you can remove the "is that a BUG" question here.
I'm still curious as to who is passing a url with a filename here; Qt or the app.
In any case the comment is confusing, "Qt returns", this is rather about Qt calling this method, not "returning".
No need for KFileItem just for that, use entry.isDir().
Updated the comment and removd the unnecessary KFileItem
Revision 2 (+24 -1)
Yes in my opinion this is fine and in line with how KFileWidget already works.
I just realized that if we want to minimize the number of stat jobs, then maybe my suggestion to put this here was wrong, it will be easier to optimize it if we all do it together in KFileWidget rather than a bit here and a bit there. I wanted this "adaptation to the Qt API" not to clutter the KFileWidget API itself, but this could be done with a new KFileWidget::setFileOrDirectoryUrl() method (or something like that) that frameworkintegration calls. Anyway, can be done later if someone wants to tackle reducing the number of (blocking) stat jobs.
If setDirectory is called multiple times and if that can't be avoided, we might want to add a if (directory == m_directory) return; early return (with a new member var m_directory).
Anyhow, let's get this in, it already missed 5.19, further improvements can be done on top.