[Development] QFileSystemWatcher and Recursive Monitoring

[Andre Somers]

Op 28-7-2012 11:04, d3fault schreef:
>
> I've been thinking about it some more, and I think it would be a good 
> idea to add another optional bool to the opt-in custom interface 
> constructor.
>
Having (series of) bools in API's is usually a bad idea. See for 
instance this blog posting: 
http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html
>
> So it now would be:
> QFileSystemWatcher(IQFileSystemWatcherSpecialCoarseToFineGrainedNotificationsFigureOuter 
> *userCustomSnapshotComparisonCode, bool 
> alwaysUseCustomFigureOuterEvenIfPlatformDoesntNeedIt = false, QObject 
> *parent = 0);
>
> The reason for the additional bool is that we cannot predict what 
> criteria a _user_ will use to determine a file changed. They may 
> ignore certain changes that the native platform would emit, which will 
> lead to inconsistencies in their application on platforms with native 
> support vs. those without. The bool allows them to opt to take control 
> of every platform so there aren't any inconsistencies. It defaults to 
> false because most of the time the user will want to use the much more 
> efficient native platform notifications when available.
>
> We need a pretty beefy class description explaining all this.
>
That's exactly the problem.

In my view, these things should not be needed in the constructor at all. 
Instead, make the whole thing property based. That is: make the 
user-class that you plug into the QFileSystemWatcher something that you 
can just get and set. There are other examples of this in the Qt API, 
for instance in working with delegates in itemviews. By default, there 
will be a delegate set on an item view, but you can set your own if you 
want. The same goes for QItemSelectionModel: an instance is created by 
default, but you can just set another one if you want. The benefit is that:
1) it is all very explicit in the code. It is easy to understand what 
happens
2) it does not get in the way of those not using it
3) it allows initializing in any order that makes sense to the user

It would be nice if the system default object doing the work, if there 
is such a thing, would be available from the API and you could "get" it 
from the QFileSytemModel. That would make it possible to use the default 
implementation from the custom one.

So, instead of complicated constructors, I'd suggest some normal API 
methods instead:

//say, QAbstractFileSystemBuffer is the class (interface) that takes 
care of tracking the file system changes
void setFileSystemBuffer(QAbstractFileSystemBuffer* buffer); // 
QFileSystemModel takes ownership
QAbstractFileSystemBuffer* getFileSystemBuffer(); // simply returns a 
pointer to the object
QAbstractFileSystemBuffer* takeFileSystemBuffer(); // releases ownership 
of the object

That makes this possible:
QFileSystemWatcher* watcher = new QFileSystemWatcher(this);
// MyFileSystemBuffer can use the standard implementation to do much of 
the work...
MyFileSystemBuffer* buffer = new 
MyFileSystemBuffer(watcher->takeFileSystemBuffer());
watcher->setFileSystemBuffer(buffer); //watcher takes ownership of the 
buffer


André