Uploaded image for project: 'Picard'
  1. Picard
  2. PICARD-2108

No ability to refresh files if filesystem has changed without Picard knowing

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • 2.5.2
    • User Interface
    • None
    • Debian Linux, Buster (stable)

      I've noticed that sometimes Picard does not see see filesystem updates that occur outside of Picard.  I'm assuming this is from the filesystem change monitoring either missing some update notifications, or just that not working on certain filesystems due to missing support.  That is not the issue at hand.

      The issue is that once Picard has missed some filesystem changes for whatever reason, there doesn't seem to be any way (short of restarting Picard) to get it to update the file listings.  Even clicking on now non-existent files/dirs and trying to do operations on them doesn't cause it to realize they aren't there anymore or that new files have appeared in them.

      I think there needs to be an option in the file browser pane context menu to "Refresh" (selected dirs/files) and "Refresh All" (all expanded dirs/files).  In addition, it would be good if picard re-scanned any directory that is actively being worked in within picard whenever a new operation is initiated in that directory (select, expand/collapse, scan, process, save, etc).

          [PICARD-2108] No ability to refresh files if filesystem has changed without Picard knowing

          Robo Tardis added a comment - - edited

          I don't think having the display refresh/change is that big of an issue.  Since the "refresh" action could be made so it will only be initiated manually, I would consider it almost expected to have the display refresh then too.  Maybe most people never need it, and so it will never affect them.  And given what you've said about it, my preference would be to have it re-center the selected item if that's the easiest.  But if you are concerned about that, call it "reinitialize file display" or something instead of "refresh", as that makes it clearer that some state may be lost.

          I would also point out that because the horizontal position already automatically re-positions whenever you select an item on a different level, having the vertical position re-center is also not unexpected, especially if it only occurs due to either a manually initiated process, or due to something detecting a verifiably inconsistent state (like a file operation/access failing due to it not existing).

          Robo Tardis added a comment - - edited I don't think having the display refresh/change is that big of an issue.  Since the "refresh" action could be made so it will only be initiated manually, I would consider it almost expected to have the display refresh then too.  Maybe most people never need it, and so it will never affect them.  And given what you've said about it, my preference would be to have it re-center the selected item if that's the easiest.  But if you are concerned about that, call it "reinitialize file display" or something instead of "refresh", as that makes it clearer that some state may be lost. I would also point out that because the horizontal position already automatically re-positions whenever you select an item on a different level, having the vertical position re-center is also not unexpected, especially if it only occurs due to either a manually initiated process, or due to something detecting a verifiably inconsistent state (like a file operation/access failing due to it not existing).

          Philipp Wolfer added a comment - - edited

          I actually had started looking into this a while back. The results so far are not really satisfying I must say, it feels really buggy. Refreshing by re-initializing the model works, but it is difficult to keep the state. I had the selection being kept and partially the state of expanded folders, at least for the selected folders. The viewport jumps around strangely, I could not get this to work as I wanted. Either the first selected item was at the very bottom of the view or at the center. Having it positioned exactly as before reloading seems impossible, but even having the selected item at the top (similar as the active folder is at the top when you initially load Picard) did not work.

          So while my code somewhat would solve your issue (able to reload without restarting Picard) for users it would look really buggy and incomplete

          Philipp Wolfer added a comment - - edited I actually had started looking into this a while back. The results so far are not really satisfying I must say, it feels really buggy. Refreshing by re-initializing the model works, but it is difficult to keep the state. I had the selection being kept and partially the state of expanded folders, at least for the selected folders. The viewport jumps around strangely, I could not get this to work as I wanted. Either the first selected item was at the very bottom of the view or at the center. Having it positioned exactly as before reloading seems impossible, but even having the selected item at the top (similar as the active folder is at the top when you initially load Picard) did not work. So while my code somewhat would solve your issue (able to reload without restarting Picard) for users it would look really buggy and incomplete

          Robo Tardis added a comment -

          I normally do most file operations from the command line with tab completion.  So when I have to do it the GUI way (for picard), opening something else that provides gui file management and navigating to the right part of the filesystem to be able to do drag-and-drop operations is usually more trouble than just restarting picard.

          But, I do have to say that picard's file management features are really pretty good normally, so kudos to the devs for that.

          Robo Tardis added a comment - I normally do most file operations from the command line with tab completion.  So when I have to do it the GUI way (for picard), opening something else that provides gui file management and navigating to the right part of the filesystem to be able to do drag-and-drop operations is usually more trouble than just restarting picard. But, I do have to say that picard's file management features are really pretty good normally, so kudos to the devs for that.

          I keep this open because a refresh function is definitely a valid thing to have. But I currently don't see a easy way to handle this except for re-initializing the model completely. Might not yield the best user experience, but needs to be tested.

          > When it happens, I usually kill picard and restart it almost immediately because I can't finish what I was doing because it isn't seeing the filesystem changes

          Just noting that technically you don't need to do this. Instead of the built-in file browser you can also use your normal file browser to see the files and add them to Picard. You should definitely still be able to finish current work. The file browser is really an optional, but hopefully handy, tool in Picard and not needed for any of the rest of the functionality.

           

          Philipp Wolfer added a comment - I keep this open because a refresh function is definitely a valid thing to have. But I currently don't see a easy way to handle this except for re-initializing the model completely. Might not yield the best user experience, but needs to be tested. > When it happens, I usually kill picard and restart it almost immediately because I can't finish what I was doing because it isn't seeing the filesystem changes Just noting that technically you don't need to do this. Instead of the built-in file browser you can also use your normal file browser to see the files and add them to Picard. You should definitely still be able to finish current work. The file browser is really an optional, but hopefully handy, tool in Picard and not needed for any of the rest of the functionality.  

          Robo Tardis added a comment -

          I haven't been able to find a fully reproducible scenario, but it seems to happen to me about once or twice a day when I'm using Picard a lot, or once every few days if I'm only using picard a little.

          The thing that triggers it to "lose" filesystem updates most often seems to be renaming or deleting a directory that is either the actively selected one in the file browser pane, and when it contains files that have already been loaded/scanned/recognized (into the right pane).  As far as I can tell, no error is printed to the console when it happens.  When it happens, I usually kill picard and restart it almost immediately because I can't finish what I was doing because it isn't seeing the filesystem changes, so I can't say I've done a lot of experimentation to see what else is affected.

          Robo Tardis added a comment - I haven't been able to find a fully reproducible scenario, but it seems to happen to me about once or twice a day when I'm using Picard a lot, or once every few days if I'm only using picard a little. The thing that triggers it to "lose" filesystem updates most often seems to be renaming or deleting a directory that is either the actively selected one in the file browser pane, and when it contains files that have already been loaded/scanned/recognized (into the right pane).  As far as I can tell, no error is printed to the console when it happens.  When it happens, I usually kill picard and restart it almost immediately because I can't finish what I was doing because it isn't seeing the filesystem changes, so I can't say I've done a lot of experimentation to see what else is affected.

          The file browser uses a QFileSystemModel which automatically is supposed to watch for changes to the file system. There is no immediate support to refresh this models, so it would likely need to completely exchange the current model with another one to force a refresh.

          Can you give some example under what circumstances the automatic refresh is not working?

          Philipp Wolfer added a comment - The file browser uses a QFileSystemModel which automatically is supposed to watch for changes to the file system. There is no immediate support to refresh this models, so it would likely need to completely exchange the current model with another one to force a refresh. Can you give some example under what circumstances the automatic refresh is not working?

            Unassigned Unassigned
            RoboTardis Robo Tardis
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:

                Version Package