----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119014/#review62361 -----------------------------------------------------------
kio/kfile/kurlrequester.cpp <https://git.reviewboard.kde.org/r/119014/#comment43312> the space before '(' shouldn't be there kio/kfile/kurlrequester.cpp <https://git.reviewboard.kde.org/r/119014/#comment43313> move declaration further down to where it's first used (i.e. before if(comp) kio/kfile/kurlrequester.cpp <https://git.reviewboard.kde.org/r/119014/#comment43314> move down, closer to first use (this is not C) kio/kfile/kurlrequester.cpp <https://git.reviewboard.kde.org/r/119014/#comment43320> Calling toLocalFile on a relative url seems wrong to me (relative = no scheme, while toLocalFile() is for urls with the scheme "file"). (I'm even surprised this works...) I guess you want path() instead. kio/kfile/kurlrequester.cpp <https://git.reviewboard.kde.org/r/119014/#comment43315> merge with previous line kio/kfile/kurlrequester.cpp <https://git.reviewboard.kde.org/r/119014/#comment43319> The notion of the "current path" in a GUI program (started graphically) makes little sense to me, but I'm not sure what this should be instead .... so if this is closer to the earlier behavior, I won't object. Alternatives would be the home dir or the document path... kio/kfile/kurlrequester.cpp <https://git.reviewboard.kde.org/r/119014/#comment43316> Many things in KIO break with relative urls. In my mind, a KUrl is almost always absolute, even though isRelative() indeed exists. I would not worry about it, or at most I would replace the comment with if (startDir.isRelative()) { kWarning() << "relative URLs are not supported:" << startDir; return; } kio/kfile/kurlrequester.cpp <https://git.reviewboard.kde.org/r/119014/#comment43317> unbalanced spaces inside () space after ! shouldn't be there kio/kfile/kurlrequester.cpp <https://git.reviewboard.kde.org/r/119014/#comment43318> upUrl has a lot more magic than what you want here (e.g. stripping fragments, etc.). Do this instead: m_startDir = newUrl; m_startDir.setPath(m_startDir.directory()); and when you later port this to Qt5/KF5: m_startDir = newUrl.adjusted(QUrl::RemoveFilename); - David Faure On June 29, 2014, 3:04 p.m., Simon Bachmann wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/119014/ > ----------------------------------------------------------- > > (Updated June 29, 2014, 3:04 p.m.) > > > Review request for kdelibs. > > > Bugs: 92237 > http://bugs.kde.org/show_bug.cgi?id=92237 > > > Repository: kdelibs > > > Description > ------- > > The handling of the start directory in the KUrlRequester is only halfway > implemented. > More in detail: > - m_startDir (the private field holding the start directory) is not > initialised - the default value of startDir() is an empty URL instead of the > current working dir. > - when the start dir changes, it is not always passed to the KUrlCompletion > object of the lineedit. The suggestions showed when entering a relative path > into the LineEdit might be wrong as a consequence. > - when selecting a file, the start directory does not change to the directory > of the selected file - the API doc says it should. > - when the user entered a relative path into the LineEdit, url() returns a > relative path instead of an absolute one. > > This patch should fix these issues. > > > Diffs > ----- > > kio/kfile/kurlrequester.h 2083d4c > kio/kfile/kurlrequester.cpp 661b428 > > Diff: https://git.reviewboard.kde.org/r/119014/diff/ > > > Testing > ------- > > > Thanks, > > Simon Bachmann > >
