[Development] QFileSystemWatcher and Recursive Monitoring

[d3fault]

On Jul 23, 2012 8:07 AM, "logic.cpp" <logic.cpp at gmail.com> wrote:
>What else do you suggest then, should we make 3 separate classes one for
each
> OS?
>

definitely not. qt is a cross platform toolkit after all. separate
back-ends... on the other hand: yes.

> By all means, please do try to generate this in-memory snapshot of a
sizable
> directory tree (say 20,000 folders 150,000 files) with all the necessary
info
> you listed (filename,filesize etc.) and tell me how it goes.
> Last I tried it on my own hard drive full of stuff (40k folders 300k
files) it
> 1) consumed too huge an amount of memory, and 2) took too long to
complete.
>

That's fine, so long as a warning is present in the class description for
affected platforms. The argument i'm making is that EVERY _user_ app will
be responsible for creating the in-memory snapshot and additional
codepaths.... at least if they plan on targetting Mac OS. The overhead in
terms of memory/performance is the exact same... but you're giving app
developers the extra burden of doing it every time they use qfsw. It's
better behind the scenes and hidden from the _user_. At the very least just
so it only has to be coded/maintained once (instead of once per _user_ app).

> What I'm trying to achieve here is to have some kind of common cross
platform
> interface for file-system monitoring (in contrast to, for example, making
3
> separate classes QWinWatcher QNixWatcher QMacWatcher which will force
users to
> have platform specific code) that works as similarly as possible on all
OSs and
> gracefully degrades as necessary. Users will be made aware of this
degradation

Behind the scenes compile time progressive enhancement is better than
userland runtime graceful degradation -- at least in this use case.

> In fact - as was noted in a previous post - even on Mac OS itself there
can be
> different features available depending on which version (Snow Leopard(-)
vs.
> Lion(+)) and not just any trivial feature difference, it's a huge &
important
> one; getting actual file-level details on what exactly changed,
eliminating the
> need for an existing snapshot to compare against! Will Qt not take
advantage of
> these features where available?

Simple, the #ifdef Q_MAC_OSX now becomes #if (Q_MAC_OSX_VERSION <= 69 /*or
whatever the Leopard version is*/)

So Lion+ uses it's native functionality, and Leopard and any other platform
missing the functionality uses an expensive in-house snapshot comparison
method.

> The questions remain as follows;
> - Should it all be in one class?

Yes, making it two classes isn't necessary. It's still the same
functionality, just with a recursive element.

>     If yes, how to go about differences in features/functionality.
>     Should we emit many different kinds of signals, or just 1 general
signal.

This doesn't matter so much, as long as the Qt code ensures that the same
signal(s) are emitted for every platform. Using a single signal +
capabilities() shifts the burden onto the _user_ developer... and one could
even argue that qfsw isn't even cross platform at that point.

d3fault
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120723/c1a28dc7/attachment.html>