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.point...@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
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
