[RFC] Use QFileSystemWatcher as another method for KDirWatch?

[Christian Ehrlicher]

David Faure schrieb:
> On Wednesday 05 December 2007, Andreas Pakulat wrote:
>> On 05.12.07 23:11:53, Christian Ehrlicher wrote:
>>> Andreas Pakulat schrieb:
>>>> On 05.12.07 20:24:27, Christian Ehrlicher wrote:
>>>>> Christian Ehrlicher schrieb:
>>>>>> Hi,
>>>>>>
>>>>>> Using kdirwatch on windows is very cpu consuming (kded sometimes use 40% cpu on my duron 1300). Therefore I want to implement QFileSystemWatcher as an optional method. Is there a reason why this should not work? Should it be an optional or a hard dependency?
>>>>>>
>>>>> Ok, here the patch.
>>>>>
>>>>> I enabled it only for windows to not get in trouble with 4.0.0. There's
>>>>> a bug (task-tracker id 170021) which prevents watching directories on a
>>>>> fat32 partition. It's fixed in 4.4 but it would be nice when this patch
>>>>> could be applied to qt-copy.
>>>> Does this support all features of KDirWatch? Last time I checked
>>>> QFSWatcher had some limitations.
>>>>
>>> There's one major difference between KDirWatch and QFileSystemWatcher.
>>> KDirWatch can watch files/dirs which do not exist yet.
>>> Any other difference you're aware of?
>> No, and now that you mention it, I think thats exactly what I was
>> thinking about. I'm not sure though how much that feature is used...
> 
> I think it's quite necessary in kded, which has to notice directories created
> in the usual places (e.g. $KDEHOME/share/services). But I guess this can always
> be emulated by watching the parent dir instead - at the expense of making the
> code more complex.
> 
With my patch this works too (just copied the relevant parts from
KDirWatch/inotify - support)
Looks like inotify can't watch non existant files/dirs at all.

Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071206/77ddc3f2/attachment.sig>