Looks OK, its just adding existing methods to the ClassDB registration so shouldn't think too hard about merging this.

Starting thoughts, I'm not particularly fond of this. Mainly, these methods feel too "technical", "mechanical" to be needing to be exposed. The additional documentation does not help. Yes, these are used by the engine, but what can the user... use this for?

Hi, @Mickeon. There are several reasons for exposing these methods.

set_edited:

It's common practice in when serializing sub-resources during a save operation to set the resource edited state to false. Without this method, any custom ResourceFormatSaver has no way to reset this state, and the engine will continue to view the resource as modified. This creates a divide in how C++ modules and GDExtension work for plug-ins, meaning that GDExtensions that have custom resource loader/saver are incapable of handling this use case properly.

is_edited:

This one is chosen to be exposed mainly because if GDExtension needs a way to set the state to true or false, it may need a way in the future to query the edited state of the object. So this is purely for convenience.

get_edited_version:

This was being exposed primarily to support hash_edited_version_for_preview; however, in hindsight, maybe it would make more sense to change this and expose hash_edited_version_for_preview instead so that again resources exposed in GDExtension that may want to disable previews, like TileSet, can do so.

A quick skim over this has me believe that it would be a better fit to expose this in Resource, instead.

And furthermore, these are purely editor-exclusive, and very situational. Too much to be in Object, personally. This has me think there's got to be a better way to accomplish what one may need this for. Namely, exposing these methods through another Editor-exclusive class.

For our purposes, exposing this on the Resource class would definitely work, given that's our prime use case with our custom format loader/saver for our plug-in's data; however, I wonder if placing these on EditorInterface would also be better for other non-resource types, such as ConfigFile?

void EditorInterface::set_object_edited(Object* p_object, bool p_edited);
bool EditorInterface::is_object_edited(Object* p_object) const;

As for the get_edited_version or hash_edited_version_for_preview, I think maybe the best play is to expose the latter on the Resource class with a GDVIRTUAL call that can be implemented by custom resources.

Whats your thoughts on that approach @Mickeon ?

Sorry for not having much else to add. I am mostly looking at this from a general user perspective. Whether this is actually implemented should not be up to me.

I wonder if placing these on EditorInterface would also be better for other non-resource types, such as ConfigFile?

As I hinted at, delegating this to another class may be a better choice. So, personally, yes.

@AThousandShips so I decided on the following, in an attempt to get this into 4.4.

1. I removed exposing the get_edited_version from this PR. That is more directed toward rendering of thumbnails and I'd like to look at that work from a separate PR as I believe there may be other changes to align GDE and C++ modules in this area.
2. I removed exposing the set_edited and is_edited on Object and provided delegators from EditorInterface instead.

Let me know if you think anything else is needed here.

@dsnopek applied @Mickeon 's suggestions from above. Please take another pass.

Any example plugin to test this?
I checked how it works with my plugin and setting or not setting edited does not seem to make any difference.

This one is chosen to be exposed mainly because if GDExtension needs a way to set the state to true or false, it may need a way in the future to query the edited state of the object. So this is purely for convenience.

Sounds like theoretical use-case.

In Orchestrator for example, we want to have a way to mark our custom Resource as edited when a user makes some UI modification. Right now we either need to implement this behavior with custom is_edited / set_edited methods on our resource or maintain this state elsewhere in the UI.

In addition, there are several spots in the editor where it explicitly uses Resource::is_edited. For example, in the EditorFileSystem::_copy_file method, the editor explicitly checks whether a resource is modified before it is copied, and if it is, it explicitly calls save on it to avoid changes being lost and discrepancies.

Another example is in EditorNode::_find_and_save_resource, it again checks whether the Resource::is_edited, and only triggers the ResourceSaver::save call if the resource is flagged as edited. The same also applies in EditorNode::_save_external_resources.

A custom resource that implements its own edited tracking can't make use of any of this behavior at all.

So it's not only just a matter of convenience for tracking the state within one's own plugin, but it's also about making sure our custom resources work just like any other Godot resource does, @KoBeWi .

Ah, so it's for resources edited outside the inspector?

Thanks!