Thanks for the huge update, I hope to find some time later today to review it.

Watching files instead of layers and project support are very good improvements. ❤️

Enjoy!

I've been running this for the past week with frequent layer updates on a large number of watched layers (34) and haven't run into any issues not fixed in the PR's commits.

Also, if you're using the Layer Color Plugin then the status icons won't show up with the current version of that plugin and of QGIS. PRs on both are pending that fix the issue (LayerColorPlugin and QGIS). For now if you're running that plugin you need to disable it and then restart QGIS before status icons will show up (or use my modified versions: LayerColorPlugin and QGIS; both are needed to fix the issue)

the styling is a bit all over the place

Can you be a bit more specific?

[ I know I added indentation to blank lines (the original code doesn't have this); this was done to make the structure clearer (I have space/tab highlighting turned on in my editor). ]

First of all, thanks for the effort, there are some major improvements here!

De nada. A lot of it was just stuff that I wanted for my own use (saving watch state to the project, status icons) and much of the rest was covering corner cases (e.g. data source changed). Generally if I make changes that I reckon others might find useful I'll share them with the original project.

this is a rather large change (and might've been good to split it up into multiple PRs per issue/feature)

I originally had these split into different branches (see the commit history). I found that the code was getting very messy, hard to understand, and hard to keep in sync so I merged the three branches into one and refactored the code. [Refactoring each branch separately (and keeping the changes to each in sync) would have been tricky and error-prone.]

Given that, it might be good to move some stuff to a separate file. I also see a lot of nested functions that don't (need to) capture variables, so they can be moved to outside the function (to either inside the class or to utils.py).

Makes sense if it's feasible. One I think you called out specifically was the logging methods. These could be made standalone functions (no longer Reloader class methods) but IIRC would still need this to be be passed (the QGIS logging method needs it IIRC). Will comment more in response to your comment on that code.

It seems the most complex addition (given the administration needed everywhere) is multi-layer-single-file watch. I'm not sure what to do about it, but I think it could in its own class/administration, so you don't need the logic (and separate dicts).

Some of the rationale for this:

• Clearly divide the roles of the various parts of code.
• Code efficiency and code clarity: e.g. avoiding the need to check a layer's custom property when a simple hash/dict lookup would suffice.
• Fewer systems calls by having one watcher per file, even if watched multiple times. Having duplicate watchers could in particular be an issue on Windows systems which are (in my experience) extremely inefficient when it comes to things like [their equivalent of] stating a file.
• Avoid potential maintenance issues with keeping the various parts of the code in sync.

The dicts are also needed for e.g. the case where a watch is being removed due to the layer's data source having changed; in this instance there's no way to determine through the QGIS API what the former source was and thus, absent a mapping hash, no easy/efficient way to determine which file watch should be removed.

The watches could be moved into their own class but I think the complexity would be higher in that case.

Some overall styling patterns that are not optimal, and I might change later:

• Mixed camelCasing and snake_casing (the latter is preferred for all variables and functions, only classes have PascalCasing).

As for changes to my PR, this would effect only the pathForLayerID, layerIDsForPath, and fileChangedCallbackFunction class instance variables (which would change to path_for_layer_id, layer_ids_for_path, and perhaps file_changed_callback_singleton), correct? All methods (everything with a self parameter) get camelCase and all functions (those without an explicit self parameter) get snake_case.

• # END comments (introduced because of the nesting)

This is a stylistic thing on my part. Nesting is a large part of why they're present (and consistency; the end of all functions and methods are thus marked). Some of the nested code could be moved into stand-along methods but I generally favour keeping code that does a single task (and doesn't duplicate code elsewhere) encapsulated in single function or method, e.g. a function used only in a given method would be defined within that method [it's clearer that way IMO]. That said, there are cases where moving code into [top-level] subfunctions makes sense and can increase clarity. I saw you flagged some cases where code could be moved into a new top-level function/method; I'll comment more there.

• Many comments that only describe what, not why. These are unnecessary.

I'll keep an eye out for this when I go through your code comments.

Makes sense if it's feasible. One I think you called out specifically was the logging methods. These could be made standalone functions (no longer Reloader class methods) but IIRC would still need this to be be passed (the QGIS logging method needs it IIRC).

Yes, warning and info don't need self. warnAndLog could be moved, and take iface as a first argument (if moved out, it's best not to pass self, but pass the (most) specific object that's needed).

The dicts are also needed for e.g. the case where a watch is being removed due to the layer's data source having changed; in this instance there's no way to determine through the QGIS API what the former source was and thus, absent a mapping hash, no easy/efficient way to determine which file watch should be removed.

I agree you probably needs several dict like objects, but I meant that you have a separate class(es) for them, so you can isolate the logic, and ensure the dicts are in sync (and always set the custom property). This also makes it testable. You could define methods like is_watched(filepath) or is_watched(layer_id), which makes the code in the reloader class more readable.

I originally had these split into different branches (see the commit history). I found that the code was getting very messy, hard to understand, and hard to keep in sync so I merged the three branches into one and refactored the code. [Refactoring each branch separately (and keeping the changes to each in sync) would have been tricky and error-prone.]

I completely understand, and I don't want to make this process more difficult. Let's postpone the stylistic changes (easy to disagree on, and it makes merging/syncing with the fork painful, so I will just default to ruff after we got everything merged). Let me know if you want me to make some of these other suggested changes later on.

Makes sense if it's feasible. One I think you called out specifically was the logging methods. These could be made standalone functions (no longer Reloader class methods) but IIRC would still need this to be be passed (the QGIS logging method needs it IIRC).

Yes, warning and info don't need self. warnAndLog could be moved, and take iface as a first argument (if moved out, it's best not to pass self, but pass the (most) specific object that's needed).

Or move them into a class that takes iface as an argument to its constructor. Then one wouldn't have to pass it at all in the rest of the code, e.g.:

log = LoggingClass(iface);
…
log.info(message);
log.warning(message);
log.warning(message, notify=True);  # né warnAndLog

Note that warnAndLog is only used once in the code (when the user requests a watch on something that isn't backed by a local file).

The dicts are also needed for e.g. the case where a watch is being removed due to the layer's data source having changed; in this instance there's no way to determine through the QGIS API what the former source was and thus, absent a mapping hash, no easy/efficient way to determine which file watch should be removed.

I agree you probably needs several dict like objects, but I meant that you have a separate class(es) for them, so you can isolate the logic, and ensure the dicts are in sync (and always set the custom property). This also makes it testable. You could define methods like is_watched(filepath) or is_watched(layer_id), which makes the code in the reloader class more readable.

I'll take a look and see what would be involved in splitting the watcher-related code into its own class (including the mapping hashes) with access strictly though methods.

I completely understand, and I don't want to make this process more difficult. Let's postpone the stylistic changes (easy to disagree on, and it makes merging/syncing with the fork painful, so I will just default to ruff after we got everything merged). Let me know if you want me to make some of these other suggested changes later on.

Sounds good to me. I'll leave all the stylistic stuff as-is for for now.