Review Request 129205: [kcoredirlister] Ability to watch files changes

[Mark Gaiser]

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



I don't know about this... It smells like an "eliphant approach" for something seemingly simple (you just want to know which files/folders changed if you had done a search).

I don't know what the right approach is, so i'm going to reason a bit here. David will probably reply and come up with an awesome solution ;)

Approach 1:
I think (assumption) that the ioslave itself should monitor for changes and react accordingly.
However, for that to work the slave itself needs to notify the one that called the slave and shout: "Hey, i have new changed data! Here it is.". But there doesn't seem to be an approach for that in the save interface. It spits out listEntry calls when you open it and ends with a finished() call, there is no (or is there but am i missing it somehow?) way for an ioslave to emit new entries after finished() has been called.
If you want that, then you probably have to extend the slave logic to allow for subsequent entries after finished is called.
Also, i'm quite sure that inotify (the notify backend that you likely use on linux) spits out all the information you need to know already. The interfaces that KDE exposes as wrappers don't emit as much as inotify does. They mainly seem to be making somewhat sure that the different notify backends behave the same.

Approach 2:
You can go (and you did) go to "the client side" by letting KDirLister(and friends) handle this for you. It's possible, but then you lose the low level stuff you had availible in the ioslave. You are fully at the mercy of KDirWatch(and friends) to make that work as you want. Performance wise, this is probably a bad idea.

- Mark Gaiser


On okt 24, 2016, 7:05 a.m., Anthony Fieroni wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129205/
> -----------------------------------------------------------
> 
> (Updated okt 24, 2016, 7:05 a.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> -------
> 
> David, i will discard review if you don't like it, cause watching files changes can be *really* expensive. I try to:
> 1. to not break abi compability
> 2. to extend filenamesearch with this option
> 3. to fix https://git.reviewboard.kde.org/r/129141/
> 
> 
> Diffs
> -----
> 
>   src/core/kcoredirlister.h e6ba2ac 
>   src/core/kcoredirlister.cpp 508516e 
>   src/core/kcoredirlister_p.h 9a3cc7b 
>   tests/kdirlistertest_gui.h 8316b20 
>   tests/kdirlistertest_gui.cpp 11e89cf 
> 
> Diff: https://git.reviewboard.kde.org/r/129205/diff/
> 
> 
> Testing
> -------
> 
> For 3. i still can't figure out why in filenamesearch signal for delete item(s) is not triggered.
> 1. Search for file (by name) in dolphin
> 2. When appear in view delete him
> 3. Signal ItemsDeleted is not triggered, file stays in the view even if new search is performed and reload is needed. The cache look good, tests pass, works but in filenamesearch.
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20161030/7b5f1b1d/attachment.html>