[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Review Request: Correctly handle the cases where a directory
From:       "David Faure" <faure () kde ! org>
Date:       2009-07-02 11:51:57
Message-ID: 20090702115157.21301.70239 () localhost
[Download RAW message or body]



> On 2009-06-29 03:23:01, David Faure wrote:
> > Looks ok to me, except the KUrl(dir.toLocalFile()) bit which seems redundant \
> > (KUrl->QString->KUrl). And if this is replaced with just "dir" then the whole \
> > specialDir?dir:dir conditional can be simplified :-)
> 
> Jonathan Marten wrote:
> Good point, agreed that the conversion normally seems pointless but this may be a \
> double check to ensure that a non-local file is not accepted as a starting location \
> for the SaveFileName operations (local files only) - it would be equivalent to 
> specialDir ? dir : (dir.isLocalFile() ? dir : KUrl())
> 
> OTOH, though, this is not done for the OpenFileName operations - they, though, do \
> set the dialogue mode to include KFile::LocalOnly. 
> Maybe this should be made consistent by doing setting KFile::LocalOnly mode for all \
> the *FileName operations, and either removing the toLocalFile() from all of the \
> getSaveFilename* operations or adding it to all of the getOpenFileName* ones.  \
> Unfortunately KFileWidget can't validate whether its startDir parameter is allowed \
> to be non-local, because the setMode() happens after the constructor - but the \
> dialogue will show an error on "Ok". 
> Any thoughts on that?

You lost me a bit (I don't know the code that well), but overall, I prefer explicit \
checks (like the kWarning you added) over methods with implicit side effects (like \
KUrl(dir.toLocalFile()). Calling toLocalFile should only be done when a local path is \
needed, not as a way to say if (dir.isLocalFile()).

I see what you mean about KFileWidget - no big issue IMHO.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/803/#review1411
-----------------------------------------------------------


On 2009-06-08 05:28:24, Jonathan Marten wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/803/
> -----------------------------------------------------------
> 
> (Updated 2009-06-08 05:28:24)
> 
> 
> Review request for kdelibs.
> 
> 
> Summary
> -------
> 
> Fix bug 194900 by simplifying the code in KFileDialog.  For the \
> getSaveFileName/getSaveUrl cases, this originally used to create a KFileDialog and \
> then used setSelection() on it to set the starting location and/or initial file \
> name.  Doing this seems to always insert the basename of the setSelection() \
> argument into the file name field of the dialogue - even if it is not present or is \
> a directory. 
> Now the starting or special directory is passed directly to the KFileDialog \
> constructor, which handles the cases where this is a directory correctly.  (The \
> KFileWidget constructor does a KIO::stat() to check the filename/path, and decides \
> what to do based on that).  This simplifies the code in KFileDialog too. 
> Extend the test cases (tests/kfiledialogtest.cpp) to check for these cases.  Since \
> this test has grown quite a bit, add a caption to the dialogue of each sub-test to \
> indicate what is being tested. 
> 
> This addresses bug 194900.
> https://bugs.kde.org/show_bug.cgi?id=194900
> 
> 
> Diffs
> -----
> 
> /trunk/KDE/kdelibs/kio/kfile/kencodingfiledialog.cpp 977959 
> /trunk/KDE/kdelibs/kio/kfile/kfiledialog.cpp 977959 
> /trunk/KDE/kdelibs/kio/kfile/tests/kfiledialogtest.cpp 977959 
> 
> Diff: http://reviewboard.kde.org/r/803/diff
> 
> 
> Testing
> -------
> 
> Checked operation of the file dialogue using the test case and the code in the bug \
> report, correct operation observed. 
> 
> Thanks,
> 
> Jonathan
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]