On Jul 23, 2012 8:07 AM, "logic.cpp" <logic....@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
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development