kdialog --getsavefilename /path/to/newfile.ext no longer starts in the supplied directory, but always uses a default (for me ~/Documents) kdialog --getsavefilename file:///path/to/newfile.ext still works, but chromium is not that smart. This regression resulted from the recent commit REVIEW:128639 Code which prepended "file://" to the path was removed as it is not cross-platform. I believe QUrl::fromUserInput is doing the right thing, so I'm not sure where it breaks. Reproducible: Always Steps to Reproduce: 1. kdialog --getsavefilename /path/to/newfile.ext 2. 3. Actual Results: Dialog starts in ~/Documents Expected Results: Dialog starts in /path/to kdialog master, KDE frameworks 5.26, Qt 5.7, ArchLinux.
kdialog master, KDE frameworks 5.27, Qt 5.6.1 build from sources works here
Bug is reproducible with KF5 master and Qt 5.8 branch. Using kdialog --getsavefilename /path/to/ shows the correct folder. Using kdialog --getsavefilename /path/to/filename.ext shows the correct filename, but the wrong folder ("Home" on my system).
Christoph is right here, using his examples I have the same issue
My best guess now is it's in KIO's KFileWidget::setSelection - d->setLocationText(QUrl(url)); + d->setLocationText(urlFromString(url)); since the second last edit to kfilewidget.cpp made that change in another function and it has the affect of prepending file:// to absolute paths on Linux.
Paul, I can confirm that this fixes the problem in kdialog for me. Can you please go to https://phabricator.kde.org/ and submit your patch here for review so it can be included (or commented on by those who know the code better than I ;) Thanks!
*** Bug 373721 has been marked as a duplicate of this bug. ***
Git commit e62d80b07366bbeb8327a514c3a6be0975787b98 by Kai Uwe Broulik. Committed on 23/12/2016 at 09:37. Pushed by broulik into branch 'master'. [KFileWidget] Use urlFromString instead of QUrl(QString) in setSelection Differential Revision: https://phabricator.kde.org/D3773 M +10 -0 autotests/kfilewidgettest.cpp M +1 -1 src/filewidgets/kfilewidget.cpp https://commits.kde.org/kio/e62d80b07366bbeb8327a514c3a6be0975787b98
In which user-facing release is this fix expected to be included? Apparently it's not part of the just released 16.12.1.
Peter, you need kio from KF5 version 5.30.0 (the applications and frameworks have independend release schedules).
Right, sorry for the noise. Didn't notice the fix was in kio (frameworks) instead of kdialog (applications).