[Development] QFileSystemWatcher and Recursive Monitoring

[marius.storm-olsen at nokia.com]

4) put the functionality in an add-on, which has no requirement of supporting all platforms, and allow people who need it link to it. It can live its life there until a decent algorithm and API has been developed, and then we can bring it in if we want.

--
Sent from my Nokia N9

On 7/24/12 17:21 ext d3fault wrote:
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