[Development] QFileSystemWatcher and Recursive Monitoring

d3fault d3faultdotxbe at gmail.com
Wed Jul 25 00:20:54 CEST 2012


On Jul 24, 2012 3:09 AM, "Sylvain Pointeau" <sylvain.pointeau at gmail.com>
wrote:
> having them inefficient is worst than not having them.

Arguably. We have to choose from the following:
1) Make Qt only target Lion+, drop Leopard support as well as any platform
without fine grained fs notifications
2) Not have a cross platform public API (breaks Qt rules?)
3) Be inefficient for the few platforms that don't support fine grained fs
notifications

All 3 options suck (as does the current state of Qfsw), but I'm pretty sure
the last option sucks the least.

> make a separate lib or class and let the user decide if he can use it.
> don't force everybody to be penalized.

Similarly, don't force everyone to reinvent the wheel.

>
> As I said, a generic implementation cannot beat specialized code for the
specific domain/case.
>

Yes, but as mentioned before, we could additionally (runtime switch? ex:
if(Qfsw::currentPlatformDoesntSupportFineGrainedFsNotifications()) {
m_Qfsw.setDontSimulateFineGrainedSupportBecauseWeWillDoItManually(true); /*
already true(ish) for platforms with fine grain notifications */ }) disable
the behind-the-scenes-state-comparison code so the user can optimize their
heart out. They'd have to again use that static fine grained detection
method in their slot connected to dirChanged to decide whether or not to
even use their own manual implementation, because most relevant platforms
already provide fine grained notifications and the user's manual code
should then be skipped. A bit complicated, but definitely doable.

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


More information about the Development mailing list