QFileSystemWatcher: handle onFileSystemChanged() signal only once when multiple files are deleted at the same time.
-
@Diracsbracket said in QFileSystemWatcher: handle onFileSystemChanged() signal only once when multiple files are deleted at the same time.:
I was hoping for a more robust way though...
I don't understand what more "robust way" you are expecting to find. I am pretty sure that when, say, a user selects a bunch of files in Explorer and deletes them, Explorer issues system calls to delete them one at a time. I don't think there is any "delete these multiple files" system call in Windows (or Linux), nor does Explorer issue any "begin/end multiple delete" notification.
So what is the difference between, say, the user selecting two files and deleting them versus selecting one, deleting it, then selecting another and deleting that? I assume nothing other than the timing.
Given that, you can do what you want in any of the multiple ways suggested which in some shape or form look at timing to decide how many/when to show dialogs to the user. That might be e.g. set a single shot timer from the first delete and don't report till it expires, optionally renewing the timer if more deletes come in during its period, or it might be show a dialog immediately on the first one and then look at the time when the next one arrives and ignore it if "close" to the first time, or some "ignore further notifications while dialog is presented" in whatever shape or form.
@JonB said in QFileSystemWatcher: handle onFileSystemChanged() signal only once when multiple files are deleted at the same time.:
I don't understand what more "robust way" you are expecting to find. I am pretty sure that when, say, a user selects a bunch of files in Explorer and deletes them, Explorer issues system calls to delete them one at a time.
I got the fact that the system deletes the files one by one. By "more robust" I meant the way the app/user gets notified of these changes. To "wait for a small time" and then display another message if more signals come in did not seem satisfactory to me if the files were deleted as a single block by the user.
Maybe I should have used the term "elegant" instead of "robust"...
-
Hi @Diracsbracket,
How do I go about if I want to display the "Directory has changed" message only once in that case?
...
I was hoping for a more robust way though...There's two ways I can think of. Either:
- In the slot function, temporarily disable the watcher (eg disconnect the signal), then after the message has been displayed, re-enable it; or
- In the slot function first check some state to see if the message is already showing, and if not, then show the message, otherwise ignore it.
That said, a good example to look at would be Qt's own Qt Creator. It essentially does #2, by showing a modal dialog, then the slot just checks if any modal dialog is showing. Note, this has the advantage of also not interrupting other modal dialogs, that might be unrelated to the filesystem changes. But of course, that only works if the reload prompt is modal - you might be showing non-modal, or a status bar etc, in which case use a simple member variable or something similar as appropriate.
Have a look at documentmanager.cpp, especially the DocumentManager::checkForReload() function for inspiration.
Cheers.
@Paul-Colby
Thanks for your suggestions! I'll have a look atDocumentManager.I was also thinking something along the lines JonB suggested:
-
When the first signal arrives for the watched folder, start a timer.
-
If another signal arrives for the watched folder before the timer expires, then restart the timer.
-
Only show the dialog to the user when the timer expires.
With this approach, assuming a suitable timeout period can be set, the user will only be notified once the system has fired all its signals. I am here mainly concerned with the case a large number of files are added/deleted.
Can you see any disadvantages with this approach?
Cheers!
-
@JonB said in QFileSystemWatcher: handle onFileSystemChanged() signal only once when multiple files are deleted at the same time.:
I don't understand what more "robust way" you are expecting to find. I am pretty sure that when, say, a user selects a bunch of files in Explorer and deletes them, Explorer issues system calls to delete them one at a time.
I got the fact that the system deletes the files one by one. By "more robust" I meant the way the app/user gets notified of these changes. To "wait for a small time" and then display another message if more signals come in did not seem satisfactory to me if the files were deleted as a single block by the user.
Maybe I should have used the term "elegant" instead of "robust"...
@Diracsbracket said in QFileSystemWatcher: handle onFileSystemChanged() signal only once when multiple files are deleted at the same time.:
To "wait for a small time" and then display another message if more signals come in did not seem satisfactory to me if the files were deleted as a single block by the user.
I agree that I would not pick the approach which delays notifying the user in case more deletes come in: so pick the approach where you notify the user immediately on first delete, and decide how you would like to handle further deletes which arrive "shortly thereafter", which you take to be a "single block".
As I said, Explorer/the OS sends separate notifications. You could look for further information maybe in the Windows SDK
shellapi.hfile orIFileOperation::DeleteItemsmethod for Win-specific stuff. Explorer may use these. I do not know whether Windows offers "notifications" for such an action which you could subscribe to.In your latest post you write:
Only show the dialog to the user when the timer expires.
which is exactly the opposite of what you replied to me
To "wait for a small time" and then display another message if more signals come in did not seem satisfactory to me
Or maybe I misunderstand just what you are saying. In any case, you have a choice between
- Notify user immediately when first file deleted, think about what you want to do if more delete notifications arrive immediately after this.
- Delay notifying user till a time period has past, in case more notifications arrive.
-
@Diracsbracket said in QFileSystemWatcher: handle onFileSystemChanged() signal only once when multiple files are deleted at the same time.:
To "wait for a small time" and then display another message if more signals come in did not seem satisfactory to me if the files were deleted as a single block by the user.
I agree that I would not pick the approach which delays notifying the user in case more deletes come in: so pick the approach where you notify the user immediately on first delete, and decide how you would like to handle further deletes which arrive "shortly thereafter", which you take to be a "single block".
As I said, Explorer/the OS sends separate notifications. You could look for further information maybe in the Windows SDK
shellapi.hfile orIFileOperation::DeleteItemsmethod for Win-specific stuff. Explorer may use these. I do not know whether Windows offers "notifications" for such an action which you could subscribe to.In your latest post you write:
Only show the dialog to the user when the timer expires.
which is exactly the opposite of what you replied to me
To "wait for a small time" and then display another message if more signals come in did not seem satisfactory to me
Or maybe I misunderstand just what you are saying. In any case, you have a choice between
- Notify user immediately when first file deleted, think about what you want to do if more delete notifications arrive immediately after this.
- Delay notifying user till a time period has past, in case more notifications arrive.
@JonB said in QFileSystemWatcher: handle onFileSystemChanged() signal only once when multiple files are deleted at the same time.:
which is exactly the opposite of what you replied to me
I edited my previous message to acknowledge you suggested that approach in your reply, which I hadn't read thoroughly.
That said, the point I was trying to make is that I didn't like the fact of showing a message, then wait for some time, and then possibly show another message for the same block operation. I was hoping that by choosing an appropriate timeout period, such second message would never be shown.
-
@Diracsbracket said in QFileSystemWatcher: handle onFileSystemChanged() signal only once when multiple files are deleted at the same time.:
To "wait for a small time" and then display another message if more signals come in did not seem satisfactory to me if the files were deleted as a single block by the user.
I agree that I would not pick the approach which delays notifying the user in case more deletes come in: so pick the approach where you notify the user immediately on first delete, and decide how you would like to handle further deletes which arrive "shortly thereafter", which you take to be a "single block".
As I said, Explorer/the OS sends separate notifications. You could look for further information maybe in the Windows SDK
shellapi.hfile orIFileOperation::DeleteItemsmethod for Win-specific stuff. Explorer may use these. I do not know whether Windows offers "notifications" for such an action which you could subscribe to.In your latest post you write:
Only show the dialog to the user when the timer expires.
which is exactly the opposite of what you replied to me
To "wait for a small time" and then display another message if more signals come in did not seem satisfactory to me
Or maybe I misunderstand just what you are saying. In any case, you have a choice between
- Notify user immediately when first file deleted, think about what you want to do if more delete notifications arrive immediately after this.
- Delay notifying user till a time period has past, in case more notifications arrive.
@JonB
Apologies for my messy, hasty postings. I need to take more time reading your replies correctly...@JonB said in QFileSystemWatcher: handle onFileSystemChanged() signal only once when multiple files are deleted at the same time.:
I agree that I would not pick the approach which delays notifying the user in case more deletes come in: so pick the approach where you notify the user immediately on first delete, and decide how you would like to handle further deletes which arrive "shortly thereafter", which you take to be a "single block".
So, you think the approach of delaying the notification to the user until the (hopefully) last signal is received is not a good one?
-
@JonB said in QFileSystemWatcher: handle onFileSystemChanged() signal only once when multiple files are deleted at the same time.:
which is exactly the opposite of what you replied to me
I edited my previous message to acknowledge you suggested that approach in your reply, which I hadn't read thoroughly.
That said, the point I was trying to make is that I didn't like the fact of showing a message, then wait for some time, and then possibly show another message for the same block operation. I was hoping that by choosing an appropriate timeout period, such second message would never be shown.
@Diracsbracket said in QFileSystemWatcher: handle onFileSystemChanged() signal only once when multiple files are deleted at the same time.:
I didn't like the fact of showing a message, then wait for some time, and then possibly show another message for the same block operation. I was hoping that by choosing an appropriate timeout period, such second message would never be shown.
I agree that it will be "irritating" to show a box to the user, have them dismiss it, and then show another box for further deletions!
This all comes down to you time periods for delaying.
You will have a potential problem if you show a modal information message box. Have you considered whether a modeless window/dialog would suit you/your user? That can be updated as soon as deletes arrive, whenever they are. I don't know what your application is which wants to show a modal box when deletes happen, it could "interrupt" me as a user and suffers from the potential of being shown too frequently as we are discussing.
-
@Diracsbracket said in QFileSystemWatcher: handle onFileSystemChanged() signal only once when multiple files are deleted at the same time.:
I didn't like the fact of showing a message, then wait for some time, and then possibly show another message for the same block operation. I was hoping that by choosing an appropriate timeout period, such second message would never be shown.
I agree that it will be "irritating" to show a box to the user, have them dismiss it, and then show another box for further deletions!
This all comes down to you time periods for delaying.
You will have a potential problem if you show a modal information message box. Have you considered whether a modeless window/dialog would suit you/your user? That can be updated as soon as deletes arrive, whenever they are. I don't know what your application is which wants to show a modal box when deletes happen, it could "interrupt" me as a user and suffers from the potential of being shown too frequently as we are discussing.
@JonB
Indeed, maybe I am just complicating things too much by wanting to display a (modal) dialog. It is probably just simpler to just give a visual indication to the user somewhere in the View/List concerned that changes occurred to the directory. That should be enough to prompt the user to reload the View/List. This is equivalent to your non-modal dialog suggestion, I suppose.At long last, I am starting to see the light... which is exactly why I am coming to this forum.
Thanks!
-
@JonB
Indeed, maybe I am just complicating things too much by wanting to display a (modal) dialog. It is probably just simpler to just give a visual indication to the user somewhere in the View/List concerned that changes occurred to the directory. That should be enough to prompt the user to reload the View/List. This is equivalent to your non-modal dialog suggestion, I suppose.At long last, I am starting to see the light... which is exactly why I am coming to this forum.
Thanks!
@Diracsbracket
Yes, it depends on your application/goal. But the thought for me as a user that while I am using your app I am liable to be "stopped" by the presentation of modal dialogs, potentially multiple times whether for a single block delete or at least for separate deletes even if they do not form a block, is not "appealing". Can it be in your software that I am, say, typing into an edit control and for whatever reason a file gets deleted and my typing gets interrupted by a modal dialog popping up? I don't like that :) -
@Diracsbracket
Yes, it depends on your application/goal. But the thought for me as a user that while I am using your app I am liable to be "stopped" by the presentation of modal dialogs, potentially multiple times whether for a single block delete or at least for separate deletes even if they do not form a block, is not "appealing". Can it be in your software that I am, say, typing into an edit control and for whatever reason a file gets deleted and my typing gets interrupted by a modal dialog popping up? I don't like that :) -
@JonB
I might just turn the View/List into a red, blinking one. That should be enough of a notification to the user. :-)@Diracsbracket
I think that would be a whole lot simpler for this multi-file-delete notification! :)
