[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: [PATCH] kdelibs kio::KDirWatch
From: Josef Weidendorfer <Josef.Weidendorfer () gmx ! de>
Date: 2007-07-25 13:17:30
Message-ID: 200707251517.30821.Josef.Weidendorfer () gmx ! de
[Download RAW message or body]
[oops, forgot the mailing list]
On Wednesday 25 July 2007, you wrote:
> On Wednesday 18 July 2007 20:08:42 Josef Weidendorfer wrote:
> > I suppose with inotify?
> No, also using famd.
> Talking about it, I've made a simple test program for KDirWatch.
> I've connected all KDirWatch signals to dedicated slots but I don't receive
> anything.
>
> After applying my patch KDirWatch works better (as I can see from debug
> messages), but my test program doesn't receive any signal. The strange thing
> is that I can see the debug messages printed before signal emissions.
> I would like to know what is wrong with this small program (~300 loc), can you
> perform a short inspection? You can find it here [1].
> The syntax is simple: ./kdirwatcher -d /tmp/foo
> and then perform same actions inside /tmp/foo
Get rid of these lines in main.cpp:
while (1)
{
// do nothing, just waiting for an interruption
sleep(1);
}
KDirWatch gets notifications usually via available data on some file descriptor
(for famd its a socket connection to famd, for inotify its a file descriptor
returned by inotify_init()).
Such nofications can only trigger from the main event loop (using
QSocketNotifier).
Unfortunately, I do not have famd here, but using inotify then I get dirty()
signals with your code.
Hope this helps.
Josef
PS: I do not have much time for KDE nowadays, so I did not get involved with
kdelibs for KDE4. But IMHO file change notification belongs into KIO slaves
(using KDirWatch in kio_file). Do you know if this was done for KDE4?
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic