Review Request: Correctly handle the cases where a directory (without filename) is passed to KFileDialog::getSave*

[David Faure]

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