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

Separate resource picker's create options #91540

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

aXu-AP
Copy link
Contributor

@aXu-AP aXu-AP commented May 3, 2024

Implements an idea from godotengine/godot-proposals#7629 (discussion)

Adds a create and quick load buttons on resources in the inspector. The buttons are visible only if mouse hovers over them. Now the edit resource menu isn't too long for resources like Mesh.

resource_picker

Note: this is not yet ready, there's some cotchas I didn't yet figure out, but I wanted to put this out to test out if the idea is deemed good. IMHO it is a nice QOL thing and streamlines creating and loading resources.

TODO:

  • I couldn't get the container to observe if the mouse is in it (instead its childs do the checking) - buttons disappear when mouse is between them.
  • Get panel color from the theme. I couldn't figure out what the color for dark blue is called.
  • Think about keyboard users. Ideally the buttons would appear on keyboard focus, but again, I didn't yet solve how. Alternative: show all options in menu if it was opened via keyboard.

Adds a create and quick load buttons on resources in the inspector. The buttons are visible only if mouse hovers over them. Now the edit resource menu isn't too long for resources like Mesh.
@AdriaandeJongh
Copy link
Contributor

I think there's a good UX case to be made for putting the new and quick load buttons in the empty object (thought the buttons shouldn't overlap with the text ). I use both of those all the time so quicker access is a win. I'd even go as far as to say the buttons might not need to be hidden and only visible on hover, but I'd have to see that in action to know for sure.

But why put a 'new' button on an already picked object? That doesn't make sense to me. Seems much more logical to me that users first remove the existing object if they want to replace it. Replacing an existing object with a new one is not as common of a use case as filling an empty slot with a new object or an object from the file manager.

@AThousandShips AThousandShips added this to the 4.x milestone May 4, 2024
@aXu-AP
Copy link
Contributor Author

aXu-AP commented May 4, 2024

(thought the buttons shouldn't overlap with the text ).

I'd even go as far as to say the buttons might not need to be hidden and only visible on hover, but I'd have to see that in action to know for sure.

Unfortunately the inspector can be so narrow that overlap is inevitable. I don't think the butttons should take precious place from the resource preview. We could alleviate the problem by left-aligning <empty> text. @Mickeon had some good arguments in this comment.
Here's a screenshot with buttons visible all the time:
kuva

But why put a 'new' button on an already picked object?

I think replacing resources with a new one is common enough. I often duplicate nodes and and replace resources in them. Anyway, if we hid it entirely we should prepare for influx of tech support questions from confused users.

@AdriaandeJongh
Copy link
Contributor

AdriaandeJongh commented May 4, 2024

Seeing the screenshot I'd say it clutters the inspector and awful lot. Maybe if the icons were dimmer... but idk. Suddenly the fact that currently those options are hidden under a small submenu makes a bit more sense ;)

I'm not convinced that the options for these buttons are 'it overlaps' or 'we don't have them at all'. Perhaps some responsiveness to the inspector's width can be implemented. Most important is that the <empty> text is fully visible at all times because that indicates that the variable is empty. I can image the icons disappearing when the width takes a certain size small enough so that the buttons would overlap.

Anyway, if we hid it entirely we should prepare for influx of tech support questions from confused users.

Or, with this design, from users who wanted to click on the object to inspect it but instead clicked the suddenly appearing 'new' button, creating a new object and overriding the old one accidentally and unintentionally.

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

Successfully merging this pull request may close these issues.

None yet

4 participants