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

Editor setting popup menu #31815

Conversation

FeatherAntennae
Copy link

@FeatherAntennae FeatherAntennae commented Aug 30, 2019

Bugsquad edit: Depends on #36926.

Work in progress. PR opened to facilitate feedback.

Adds a small popup menu to the editor settings dialogue window accessible through a menu button next to the search bars and through right clicking in the trees.

AiSEA1L224

The goal is to put together a bunch of small quality of life improvement to the way users interact with these settings by allowing to collapse / expand all of the sections at once, collapse all the sections except the one that is currently active and restore everything to their default values without having to manually reset all settings one by one.

Created stub for general tab menu.
Implemented Collapse/Expand all for shortcuts tab.
Implemented Collapse unselected for shortcuts tab.
@Xrayez
Copy link
Contributor

Xrayez commented Aug 30, 2019

#22834 would be useful for this yet again.

@FeatherAntennae
Copy link
Author

FeatherAntennae commented Aug 30, 2019

#22834 would be useful for this yet again, as it could be for #19936 as well.

I was thinking about asking on the IRC and make a PR about bringing a few new features to the Tree and TreeItem. The whole collapse extend logic should probably be handled by them to improve maintainability and there should probably also be signals for it. Right now a lot of places in the editor have the same code with slight variants / written completely differently to do exactly this.

Adding an "active item" or something to get the currently selected "branch" of a tree would help too. Like if the tree item has one of it's column selected or any of it's children have a column selected and so on recursively, it's considered active. This would allow adding more selection based comportment which are pretty standard when working with trees (Like collapse all but selected in this menu).

That'd probably be something for 4.0 though.

Created stub for general tab menu.
Implemented Collapse/Expand all for shortcuts tab.
Implemented Collapse unselected for shortcuts tab.
Created stub for general tab menu.
Implemented Collapse/Expand all for shortcuts tab.
Implemented Collapse unselected for shortcuts tab.
@akien-mga akien-mga added this to the 4.0 milestone Sep 2, 2019
@FeatherAntennae
Copy link
Author

Been waiting for my laptop to come back from the manufacturer for RMA for over a month now, I'll start working back on this as soon as I get my hand on the replacement.

@Xrayez
Copy link
Contributor

Xrayez commented Nov 11, 2019

Not sure if collapse_unselected should be there, this might add unnecessary complexity. If anything is selected then it might be better that collapse_all_sections could skip the sections with selection by default? Then you need to ensure that the selected items are visible after collapse.

@FeatherAntennae
Copy link
Author

@Xrayez It's a common behavior I've coded and/or used in a lot of UI before. I don't think collapse all sections should do that logic either.

I do think none of this should be there though. These 3 functionality are pretty common, are in a few places in the editor already and are going to be in even more places soon. They might just be a few lines of code, but they do add complexity and these few lines are going to be repeated in quite a few places and are already written in a few different ways by different contributors.

I think the Tree / TreeItems should handle most of this. It makes no sense to me to redefine these functionality everywhere and add complexity to all the editor classes requiring it instead of adding it once in the Tree or TreeItem class.

I think that a Tree should allow to be recursively expanded and collapsed natively, a TreeItem should allow the same for it's children. Also somewhere in there, there should be a way to differentiate an item that is Active (is selected or has a children selected, recursively too) so that we can choose to ignore it or not.

I can implement that and write doc for it too without problem, in a different PR linking this one as dependant. It would also simplify the next PR I wanted to make which is the same as this one, but for project settings.

@aaronfranke
Copy link
Member

@FeatherAntennae Is this still desired? It seems that this PR still needs more work. Also, the commits in this PR will need to be rebased and squashed before this can be reviewed or approved.

@FeatherAntennae
Copy link
Author

FeatherAntennae commented May 26, 2020

@FeatherAntennae Is this still desired? It seems that this PR still needs more work. Also, the commits in this PR will need to be rebased and squashed before this can be reviewed or approved.

This is on hold as it would be highly simplified by #36926.
Waiting on feedback for the other PR before continuing this one.

Edit:
This one is still desired and is part of #33984. I could complete this one and rewrite half of it if/when the other one is merged, but I don't think it's a good idea.

@Nukiloco
Copy link

Is there any interest in this PR still?

@FeatherAntennae
Copy link
Author

@Nukiloco The PR this depends on got lost in the void when focus shifted to Godot 4 and the suggestions switched to the other repo. It has been waiting for review so long that it probably isn't even worth reviewing now.

Things have changed a lot, so it would probably require some time to bring everything up to date, or to make sure to go over everything that might be affected again.

Since I don't have the time to contribute right now, and don't feel like waiting 3 years for feedback, I guess there's no interest.

Feel free to salvage, I'll try and contribute again once I'm less busy with work and school.

@mhilbrunner
Copy link
Member

Closing for now as per the discussion above. Sorry this fell through due to the backlog, we're trying to improve that situation.
Still, thanks for contributing! In the future, if you want to try again, it may make sense to gather feedback/approval first for this particular change, e.g. via the proposal process, as it seems harder to find consensus on this.

@mhilbrunner mhilbrunner removed this from the 4.0 milestone Aug 25, 2022
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.

8 participants