Re: [Development] QFileSystemWatcher and Recursive Monitoring

Hah 13 years later 😆 QFSW should probably just do what this codebase does: https://github.com/emcrisostomo/fswatch -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

Re: [Development] QFileSystemWatcher and Recursive Monitoring

BH Alright I'll begin trying to implement some of this, possibly inside the QFileSystemWatcher class itself. But don't expect much, this is opensauce after all so I might come back in a few months and yawn "Oh right, QFileSystemWatcher... forgot about that" :D Though if some volunteers can help

Re: [Development] QFileSystemWatcher and Recursive Monitoring

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://

Re: [Development] QFileSystemWatcher and Recursive Monitoring

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. So it now would be: QFileSystemWatcher(IQFileSystemWatcherSpecialCoarseToFineGrainedNotificationsFigureOuter *userCustomSnapshotComparisonCode, bool a

Re: [Development] QFileSystemWatcher and Recursive Monitoring

On Jul 27, 2012 6:02 AM, "logic.cpp" wrote: > > BH > > I think this is very much like what I was trying to describe. > I think so too, it was immediately after reading your post that the design jumped out at me. The confusing part was your stating that the interface should be required to be imple

Re: [Development] QFileSystemWatcher and Recursive Monitoring

BH I think this is very much like what I was trying to describe. It's really annoying that Mac<=Snow Leopard is forcing us into such corners, but if it works and it pleases all Qt evangelists :) then maybe this'll do. ___ Development mailing list Devel

Re: [Development] QFileSystemWatcher and Recursive Monitoring

On Thu, Jul 26, 2012 at 9:55 AM, logic.cpp wrote: > So how about something like this (others have suggested something along these > lines): > > In order to work recursively, Recursive isn't the same problem. Recursive is easy. The only problem with doing recursive before was that 256 fd limit on

Re: [Development] QFileSystemWatcher and Recursive Monitoring

So how about something like this (others have suggested something along these lines): In order to work recursively, the file-system watcher class will require the user to implement a sort of snapshotting "backend" which will be interfaced/used for FS change comparisons. And only as a "bonus", t

Re: [Development] QFileSystemWatcher and Recursive Monitoring

Nice. I have missed that. :-) Thank you for your help. Best Regards, Laszlo Papp On Wed, Jul 25, 2012 at 12:03 PM, wrote: > On 25/07/2012 05:52, ext Thiago Macieira wrote: >> On quarta-feira, 25 de julho de 2012 11.45.23, Laszlo Papp wrote: Neither playground nor non-playground add-ons ne

Re: [Development] QFileSystemWatcher and Recursive Monitoring

On 25/07/2012 05:52, ext Thiago Macieira wrote: > On quarta-feira, 25 de julho de 2012 11.45.23, Laszlo Papp wrote: >>> Neither playground nor non-playground add-ons need to support >>> all platforms, though if they want to be in the Qt Essentials set >>> of modules, they do. >> >> Is that document

Re: [Development] QFileSystemWatcher and Recursive Monitoring

> It predates the list. It's one of the grandfathered principles of the Qt > Project: the essentials work everywhere, in all Reference Platforms. Any > feature contributed to them must support all Reference Platforms before it can > be considered for acceptance. That I am aware of, for sure. Howev

Re: [Development] QFileSystemWatcher and Recursive Monitoring

On quarta-feira, 25 de julho de 2012 11.45.23, Laszlo Papp wrote: > > Neither playground nor non-playground add-ons need to support all > > platforms, though if they want to be in the Qt Essentials set of > > modules, they do. > > Is that documented somewhere? I have not personally seen any such a

Re: [Development] QFileSystemWatcher and Recursive Monitoring

> I'm not quite sure what information you are missing on that page? The information about expectations and requirements about an add-on, for sure. There should be mentionings there for new contributors joining the project through playground for instance, or at least a link to such a page from the

Re: [Development] QFileSystemWatcher and Recursive Monitoring

On 25/07/2012 00:29, ext Laszlo Papp wrote: > On Tue, Jul 24, 2012 at 11:59 PM, > wrote: >> 4) put the functionality in an add-on, which has no requirement of >> supporting all platforms > > Really? Was a community decision agreed upon about that earlier? > Perhaps I have just missed something, b

Re: [Development] QFileSystemWatcher and Recursive Monitoring

On Tue, Jul 24, 2012 at 11:59 PM, wrote: > 4) put the functionality in an add-on, which has no requirement of supporting > all platforms Really? Was a community decision agreed upon about that earlier? Perhaps I have just missed something, but as an "official" Qt Project add-on, I would expect

Re: [Development] QFileSystemWatcher and Recursive Monitoring

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:2

Re: [Development] QFileSystemWatcher and Recursive Monitoring

On Jul 24, 2012 3:09 AM, "Sylvain Pointeau" 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

Re: [Development] QFileSystemWatcher and Recursive Monitoring

It will only be inefficient for the few platforms that don't support the > functionality. The cost for platforms that already do provide the > functionality is zero. > > Filesystem notifications are a pretty basic piece of functionality, and > having them be 100% cross platform would be a huge win

Re: [Development] QFileSystemWatcher and Recursive Monitoring

On Jul 23, 2012 11:49 PM, "Sylvain Pointeau" wrote: > I really like the idea of 1 signal and use the best as possible of each OS. I am against Qt to make a snapshot of the directory because it will not be done efficiently, means that this code, to be efficient, depends on the task to achieve, and

Re: [Development] QFileSystemWatcher and Recursive Monitoring

On Jul 23, 2012 7:51 PM, "logic.cpp" > wrote: > > > > So - are you suggesting that Qt file-system monitoring facilities > > should actually generate an in-memory snapshot of the necessary > > directory tree(s) for platforms that need it (in this case Mac OSX <= > > Snow Leopard) ? > > > > Hey I'm

Re: [Development] QFileSystemWatcher and Recursive Monitoring

On Jul 23, 2012 7:51 PM, "logic.cpp" wrote: > > So - are you suggesting that Qt file-system monitoring facilities > should actually generate an in-memory snapshot of the necessary > directory tree(s) for platforms that need it (in this case Mac OSX <= > Snow Leopard) ? > > Hey I'm not against, it

Re: [Development] QFileSystemWatcher and Recursive Monitoring

So - are you suggesting that Qt file-system monitoring facilities should actually generate an in-memory snapshot of the necessary directory tree(s) for platforms that need it (in this case Mac OSX <= Snow Leopard) ? Hey I'm not against, it would be really easy to implement. But you should really t

Re: [Development] QFileSystemWatcher and Recursive Monitoring

On Jul 23, 2012 8:07 AM, "logic.cpp" 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 snap

Re: [Development] QFileSystemWatcher and Recursive Monitoring

> I don't like your single signal design. It's cross platform only in that it > will compile/function on every platform. The application will behave > differently in the slot connected to said signal on mac than on > windows/linux. We should not expect every _user_ app to have separate > codepaths

Re: [Development] QFileSystemWatcher and Recursive Monitoring

I don't like your single signal design. It's cross platform only in that it will compile/function on every platform. The application will behave differently in the slot connected to said signal on mac than on windows/linux. We should not expect every _user_ app to have separate codepaths for differ

Re: [Development] QFileSystemWatcher and Recursive Monitoring

> This can be either quick-n-dirty > passing a concatenated string (semicolon separated or whatever) as the path > value, or getting fancy with passing pointers to structures that may have > several pieces of info packed in I'd just add an extra parameter to the signal which is empty for some even

Re: [Development] QFileSystemWatcher and Recursive Monitoring

> How will you handle renames? It looks like ReadDirectoryChanges uses > two separate events, leaving it up to the user to match them up. > As for renames (and moves on Linux/X11) we'd need to come up with some mechanism to sebd 2 pieces of information in one signal. This can be either quick-n-di

Re: [Development] QFileSystemWatcher and Recursive Monitoring

> Are you sure about that? The documentation specifies an > kFSEventStreamEventFlagMustScanSubDirs flag for > events which indicates that a problem happened either in the kernel or > user space and events were coalesced. > Events being coalesced is another unrelated thing (a feature in fact - not

Re: [Development] QFileSystemWatcher and Recursive Monitoring

> Notice how on Mac we get notified on the exact leaf-most folder where the > event > happened, and that the event is always just "something changed here". Are you sure about that? The documentation specifies an kFSEventStreamEventFlagMustScanSubDirs flag for events which indicates that a proble

Re: [Development] QFileSystemWatcher and Recursive Monitoring

Darn, second attempt to fix my mess-up here in the mailing list only made things worse. Shoot me. -regedit On Fri, Jul 20, 2012 at 1:21 AM, logic.cpp wrote: > BH > > Hello, > > Hope you don't mind my less-waste-your-time more-get-to-the-point English. > Begin ramble: > > Wanted to fix QFileSystem

Re: [Development] QFileSystemWatcher and Recursive Monitoring

BH Hey'all, Thanks for the feedback. I think we can still make everything work inside one single class, either QFileSystemWatcher or perhaps a new class if we don't want to break QFSW too much. We'll do this à la "Graceful Degradation". Before I explain, consider also the fact that - as Arvid me

Re: [Development] QFileSystemWatcher and Recursive Monitoring (Arvid E. Picciani)

Whoops I am so sorry, total noob here when it comes to mailing lists. This was meant to be a reply to the existing thread http://lists.qt-project.org/pipermail/development/2012-July/005279.html The last post of which was by Arvid E. Picciani Not sure if this means the discussion continues in this

Re: [Development] QFileSystemWatcher and Recursive Monitoring (Arvid E. Picciani)

BH Hey'all, Thanks for the feedback. I think we can still make everything work inside one single class, either QFileSystemWatcher or perhaps a new class if we don't want to break QFSW too much. We'll do this à la "Graceful Degradation". Before I explain, consider also the fact that - as Arvid me

Re: [Development] QFileSystemWatcher and Recursive Monitoring

On Fri, 20 Jul 2012 21:39:32 +0300, Konstantin Ritt wrote: >> I would prefer that QFSW was simple and reliable and doesn't attempt >> to impose a heavy cost or internal complexity (which translates into >> bugs) for things that the underlying APIs do not really support > Same opinion here. > Sinc

Re: [Development] QFileSystemWatcher and Recursive Monitoring

If Windows and Linux provide the capabilities, we shouldn't let specific functionality absent in Mac (or any platform for that matter) define Qt. I think modifying the addPath methods to include an optional bool watchRecursively = false as the second parameter is the correct solution. Any platforms

Re: [Development] QFileSystemWatcher and Recursive Monitoring

> As you say, applications which are watching (possibly large) directory > trees will likely > have their own database of content which they will compare any changes > to. The app > can optimize this in domain-specfic ways, such as not recording any > information about > types of files it doesn'

Re: [Development] QFileSystemWatcher and Recursive Monitoring

> I would prefer that QFSW was simple and reliable and doesn't attempt to > impose a heavy cost or internal complexity (which translates into bugs) for > things that the underlying APIs do not really support Same opinion here. Since we could get a good solution for windows only, the QRecursiveFil

Re: [Development] QFileSystemWatcher and Recursive Monitoring

> With FSEvents you cannot emit signals such as fileChanged(), fileModified(), > pathCreated(), or pathDeleted() if all you're notified about is that > "something happened in this folder here", >From my experience building an app that 'watches' a folder and imports all files of a certain type adde

Re: [Development] QFileSystemWatcher and Recursive Monitoring

#1 Clarification of original post: When I say "Making QFileSystemWatcher Recursive" I mean *adding* new functions for recursive monitoring, such as "addPathRecursively()". I don't mean to replace the current non-recursive functinality, which is very useful in its own right (for "A" category use ca

[Development] QFileSystemWatcher and Recursive Monitoring

BH Hello, Hope you don't mind my less-waste-your-time more-get-to-the-point English. Begin ramble: Wanted to fix QFileSystemWatcher for Windows as per w00t's article: (also see his fix: