Review Request 119014: KUrlRequester: fixing handling of start directory

[David Faure]

-----------------------------------------------------------
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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20140714/438cea06/attachment.htm>