Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allowing customization of which load menu is used in EditorResourcePicker #11508

Open
mdelorme opened this issue Jan 6, 2025 · 1 comment · May be fixed by godotengine/godot#101244
Open

Comments

@mdelorme
Copy link

mdelorme commented Jan 6, 2025

Describe the project you are working on

Various projects, but mainly a narrative puzzle game.

Describe the problem or limitation you are having in your project

Following the discussions on #101183

The load button has been removed from the EditorResourcePicker in a previous PR to favor a new quick-load button located right next to the arrow.

Image

This can be convenient in lots of cases however :

  1. This is not suitable for all users due to accessibility issues.
  2. In the cases where a lot of files are listed, the quick load is limited to only 100 search occurrences which can be a problem with a lot of repetitive asset names (for instance portrait_XXX.png)
  3. Some people just prefer navigating the folder structure and avoid using the quick load menu.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

The problem could be solved in two ways :

  1. Simply bringing back the load button at the bottom of the list as it was before.
  2. Allow for the configuration in the editor of which load menu is used when clicking the button.

I personally prefer the second option as it continues with the current flow of improvement, but also does not feel like a regression for people struggling with the new system.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

For option no1 we can simply revert part of the commit df01daf to re-include the "basic" load menu at the bottom of the list.

For option no2 I propose we proceed as follows :

  1. We add an enum in the EditorResourcePicker (L65) class defining which load menu is used for the resource picker :
enum LoadDialogMode {
  QUICK_LOAD,
  DEFAULT_LOAD
};
  1. We add an option in editor_settings.cpp to account for this :
EDITOR_SETTING_BASIC(Variant::INT, PROPERTY_HINT_ENUM, "interface/inspector/resource_picker_load_dialog_mode", (int32_t)EditorResourcePicker::LoadDialogMode::DEFAULT_LOAD, "Quick Load, Default Load")
  1. We add a test in the _load_button_pressed method of EditorResourcePicker (L184) to choose which dialog to open when the button is clicked :
auto load_dialog_mode = (LoadDialogMode)(int)EDITOR_GET("interface/inspector/resource_picker_load_dialog_mode");
if (load_dialog_mode == QUICK_LOAD) {
  [... Do quick load ...] 
}
else {
  [... Do standard load ...]
}
	
  1. We add documentation for the new settings.

Of course I'm voluntary for the corresponding PR if the proposal is accepted.

If this enhancement will not be used often, can it be worked around with a few lines of script?

This can be edited of course by people in their own forks, but this is clearly not ideal. Quick load is really useful as far as I am concerned, but I think the choice between quick and slow load should not be imposed on the user in that way.

Is there a reason why this should be core and not an add-on in the asset library?

This is part of the editor, so I believe it should be core.

@mdelorme mdelorme changed the title Allowing customisation of which load menu is used in EditorResourcePicker Allowing customization of which load menu is used in EditorResourcePicker Jan 6, 2025
@Calinou
Copy link
Member

Calinou commented Jan 6, 2025

  1. Simply bringing back the load button at the bottom of the list as it was before.

I would prefer doing this, as toggling an editor setting just for this sounds quite niche.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants