Reloading a project doesn't reload its GMEdit properties file

[thennothinghappened]

If #config/properties.json is edited outside of GMEdit, for instance, due to a git checkout, GMEdit will not pick up the changes upon reloading the project, only closing and re-opening the project works.

gmedit-project-properties-bug.mp4

Sample plugin demonstrating the issue, as used in the video.

[thennothinghappened]

This seems to be intentional behaviour:

GMEdit/src/gml/Project.hx

Lines 559 to 560 in 6a81cac

	if (first) {
	properties = ProjectProperties.load(this);

[thennothinghappened]

I had a look into auto-reloading properties when changes are detected, which is done for other project files. I tracked down where the other change-checking happens, which lead me to FileKind, but to be honest, there is too much of an interconnected web going on between GmlFile, Project, FileKind and Editor to make any use of that code without a very large refactoring of how these systems work.

I considered doing that work, but every time I've touched GMEdit my mind has been on not breaking plugins. I don't really know what plugins are out there to test against, so it makes it a bit of a fruitless endeavour.

I also considered just grabbing the relevant file checking code, sticking it in a util class somewhere, and adding a method to Project to query the last-modified date of a config file (since ProjectProperties isn't actually responsible for its config file, that responsibility is half-shared between it and Project), but no matter which way I approach it from, I'm not happy with the compromises, chiefly because a project's properties can be modified by any plugin at any time, and short of introducing a repeating check to see if properties or any of its members, or any of their members (etc) have changed, you can only rely on the fact that a plugin changing some properties will want to commit them sooner or later using ProjectProperties.save, which also takes an arbitrary structure, which means a plugin can accidentally overwrite the properties element another plugin was working with if they happened to structuredClone() their copy.

The solution I was least-unhappy with is the simplest one, which should also satisfy plugins that would misbehave if properties could change randomly, would be to copy that FileKind#checkForChanges code and have the properties config checked every so often, and if the last-changed date differs, present the same dialog currently shown for code changes, except if you choose to reload with the new changes, it reloads the whole project, thus dispatching the relevant events to keep plugins in-sync.

[YellowAfterlife]

a project's properties can be modified by any plugin at any time

Technically so, but properties are for saving project-specific settings, hence the name.

The expected use is that on interaction your Project Properties controls fetch the current .properties from the project they got earlier, modify something in them, and call ProjectProperties.save().

Furthermore, properties.json would not usually be gitignored, so putting any constantly changing data in there is undesirable and breaking such plugins is an acceptable sacrifice.

I would say that the actual subjects of concern are:

1. If Project Properties tab is open when properties are re-loaded from a change, it should be re-opened.
2. Figuring out when exactly you want to check for properties changing. I think doing it on project [re-]load (thus moving it out of that on-first block) makes the most sense.

I considered doing that work, but every time I've touched GMEdit my mind has been on not breaking plugins. I don't really know what plugins are out there to test against, so it makes it a bit of a fruitless endeavour.

Most plugins can be discovered by searching for $gmedit across JS files.