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
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
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://
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
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
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
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
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
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
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
> 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
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
> 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
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
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
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
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
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
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
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
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
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
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
> 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
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
> 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
> 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
> 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
> 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
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
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
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
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
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
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
> 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'
> 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
> 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
#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
39 matches
Mail list logo
