Review Request 119607: Support for ".hidden" files

Bruno Nova brunomb.nova at gmail.com
Fri Dec 5 12:04:47 UTC 2014



> On Set. 14, 2014, 3:27 p.m., Frank Reininghaus wrote:
> > src/core/kfileitem.h, line 262
> > <https://git.reviewboard.kde.org/r/119607/diff/2/?file=301216#file301216line262>
> >
> >     Since we probably do not want to make it possible that all users of this class can make items "hidden", I'm not sure if this should be part of KFileItem's public API.
> 
> David Faure wrote:
>     I don't have an issue with that. Gives more possibilities to the app (or file dialog) etc.
> 
> Bruno Nova wrote:
>     So, should this be left public or not?
> 
> Bruno Nova wrote:
>     I still need an answer here. :-)
>     
>     Besides this issue, there is another thing that was suggested that was not implemented: unit tests.
>     I'll try to do this tomorrow, but I'll probably not be capable of doing it.
> 
> Frank Reininghaus wrote:
>     To be honest, I just don't see a valid use case for that - why would an app or the file dialog want to make the dir lister consider a particular file item hidden? If the app/file dialog wants to hide items from the user, there are other (and easier) ways to do that, since they already use a QSortFilterProxyModel or some other kind of filtering mechanism, right?
>     
>     If anyone sees a good use case, then fair enough, but unless that is the case, I don't think that one should make it public API (which is extremely hard to change or remove in future versions!).
> 
> Bruno Nova wrote:
>     That's fine by me. And those other ways you mention are probably more reliable.
>     David, what say you?
> 
> David Faure wrote:
>     If you use e.g. KDirOperator or KFileWidget you can't inject a QSFPM. But OK, better add features once we have a use case, to ensure the API matches the use case.

OK. How should I make `setHidden()` private? Move that method to the `private:` section of KFileItem and make KCoreDirListerCache a friend class of the KFileItem class? Or is there a better and more correct way to do that here?


- Bruno


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119607/#review66475
-----------------------------------------------------------


On Dez. 4, 2014, 9:55 p.m., Bruno Nova wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119607/
> -----------------------------------------------------------
> 
> (Updated Dez. 4, 2014, 9:55 p.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Bugs: 64740 and 246260
>     https://bugs.kde.org/show_bug.cgi?id=64740
>     https://bugs.kde.org/show_bug.cgi?id=246260
> 
> 
> Repository: kio
> 
> 
> Description
> -------
> 
> This adds support for *.hidden* files to KDE.
> 
> When listing a directory, the files/folders listed in the *.hidden* file will be hidden, unless the user has chosen to show hidden files.
> 
> This patch was initially based on the patch provided by Mark in Bug #246260.
> 
> 
> Diffs
> -----
> 
>   src/core/kcoredirlister.cpp a31d629 
>   src/core/kcoredirlister_p.h dce7dbc 
>   src/core/kfileitem.h bebc241 
>   src/core/kfileitem.cpp 74dc069 
> 
> Diff: https://git.reviewboard.kde.org/r/119607/diff/
> 
> 
> Testing
> -------
> 
> Built and tested the patch in Project Neon.
> Dolphin was still using KDE4/Qt4 version of the library, so I only tested using the desktop folder widget, and "folder desktop".
> It worked correctly when I pointed it to "~" and "~/Desktop" (I added ".hidden" there).
> However, it didn't work when I pointed it to the "Desktop folder" (the default option, not the custom location "~/Desktop").
> More testing is required.
> 
> The version for KDE4/Qt4 submitted to Bug #246260 was tested in Kubuntu 14.04, and it worked everywhere I tested (Dolphin, open/save dialogs, folder widget and detailed/tree view in Dolphin).
> It wasn't an intensive test, though.
> 
> 
> Thanks,
> 
> Bruno Nova
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20141205/2a80bd69/attachment.html>


More information about the Kde-frameworks-devel mailing list