Allow opening sprites and other files in external editor/default program

[nikhilCad]

Describe the project you are working on:
Project with many sprites
Describe the problem or limitation you are having in your project:
To edit sprites, I have to leave Godot and locate them on my computer
Describe how this feature / enhancement will help you overcome this problem or limitation:
It will basically make me stay close to the 'Godot environment'
Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:
See below
Describe implementation detail for your proposal (in code), if possible:
Basically, it will be an option in editor settings. User has to point the application.
All textures resources will have an Edit in Image Editor button in inspector
If this enhancement will not be used often, can it be worked around with a few lines of script?:
Plugins are per project. It will be tedious to set image editor in each project
Is there a reason why this should be core and not an add-on in the asset library?:
Same as above

[Calinou]

As you said, I think we'll need to make users define editor settings for this. If we want the option to always open an image in an editor (rather than just a viewer), relying on the OS file associations would be a bad idea.

What about other kinds of files, such as sounds? Should we have a "sound editor" property so users can point to Audacity or similar?

[KoBeWi]

Plugins are per project. It will be tedious to set image editor in each project

Making plugins easier to set up and having this proposal as a plugin sounds like an option too.

[willnationsdev]

I think I'd almost prefer to have both an EditorSetting and ProjectSetting for it (a "default" and an "override") since I imagine it would be annoying to have to set it for every project, as OP says. But, I can also see the argument that different projects, with different art styles, might use different image editors (Krita, Asesprite, Inkscape, etc.), and so being able to override the default setting on a per-project basis would be useful, that way you don't have to update the shared EditorSetting if you happen to be flipping between contrasting projects.

As for plugins, I just don't really see the need for them here. It's not like you're doing any sort of user-defined integration with the editor beyond just linking to the app. And there is no need for any runtime evaluation of the configuration data for linking, so no scripting is necessary.

[samdze]

The user could be able to define custom resource edit overrides specifying file extensions for each type of file he wants to open in an external editor, so, not limited to images only.

[aaronfranke]

To make it generic, it could just be an "Open file in default program" button.

[Calinou]

@aaronfranke Implementing this on Linux is very easy, it's a matter of calling xdg-open with the absolute path to the file. I think macOS has an equivalent open command for this. Windows might be a bit more difficult, but it should still be quite easy.

That is, unless we decide to go the "custom program paths" route, which just involves using OS.execute() with the program path and absolute path to the file.

[nikhilCad]

Will this issue be fixed by this pr?
godotengine/godot#35432

[nikhilCad]

I think if the said pr is merged, Godot could itself provide a lot of plugins like this Image Editor one.
A dedicated list of official/recommended plugins could also be made.

[Calinou]

@nikhilCad No, that's entirely separate. The feature you proposed here might be able to be provided by a plugin, but I think it makes sense to have it in core. (Not a dedicated image editor of course, but a way to define an image editor program in the Editor Settings and provide a context menu option in the FileSystem dock.)

[Calinou]

I ported godotengine/godot#40285 to latest master, but I am not convinced it provides good usability. On most operating systems, the default application for PNG images is an image viewer, rather than an image editor. Example with KDE's Gwenview:

This does not provide the editing tools you're used to, so I think we need to provide separate editor settings to specify the programs to use for each type of file. I wouldn't make a per-extension list, but rather provide a few settings such as:

• Raster Image Editor (.png, .jpg, .jpeg, .tga, .bmp, .dds, .webp): Use for raster images. Can be associated to GIMP without trouble.
• Vector Editor (.svg, .svgz): Use for vector images. Can be associated to Inkscape without trouble.
• Audio Editor (.wav, .ogg, .mp3): Use for audio files. Can be associated to Audacity without trouble.
• 3D Editor (.dae, .gltf, .glb, .obj): Use for 3D files. Blender cannot automatically import such files by default, unfortunately, so setting the path to the Blender executable there wouldn't work. Maybe if someone creates a wrapper executable of sorts…

These settings would default to empty strings. When a program path is an empty string, the option should still be available in the context menu. However, attempting to use it will bring up a file dialog asking you to select the program to use to open the file. After the user confirms their selection, the path to the program is stored in the editor settings.
Edit (April 2022): We discussed that when there is no override, the default program associated with the file type on the system should be used (with OS.shell_open()).

For file types not on this list (and not excluded by the editor itself), the default program associated with the extension would be used.

[willnationsdev]

@Calinou Are there also ProjectSettings overrides of these EditorSettings available, as I suggested earlier?

[samdze]

We can provide an editable list of named groups of extensions, the default one could be the one @Calinou suggested, but the user will be able to add more of them or customize each group.

We could also make opening and editing separate operations, each with possibly different settings, if needed.

[Calinou]

We discussed this in a proposal review meeting and agreed to go with the implementation suggested in #328 (comment).

[Anutrix]

@YuriSizov Why was feature: approved tag removed?

We discussed this in a proposal review meeting and agreed to go with the implementation suggested in #328 (comment).

Any info on if work on this started already or is it gonna be for 4.1?

[YuriSizov]

@Anutrix Because we moved from labels to a project. You can find the status in the projects section of the sidebar under the Godot Proposal Metaverse project.