Repository navigation
Ensure buttons don't overlap when resized mid-footer content change #39125
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
Open
LiquidPL
wants to merge
5
commits into
ppy:master
Choose a base branch
from
LiquidPL:song-select-footer-ctrl-enter
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
dcbb644
Add test case demonstrating the issue
LiquidPL 8d2d575
Ensure buttons don't overlap when resized mid-footer content change
LiquidPL 5b196aa
Move spacing to a constant
LiquidPL 2a29f36
Clarify some things in comments
LiquidPL 700de60
Merge branch 'master' into song-select-footer-ctrl-enter
LiquidPL File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Of note these changes rely on the children being transferred from their original placements in exactly the same order. Any
SetLayoutPosition()call on any children here probably breaks things and makes buttons move about during the hide in an undesirable manner.This was not previously the case because of "clever" parlor trickery (fill flow does layout by setting positions on their children directly, which means said positions transfer even when the drawables are moved to a plain
Container. That's also what causes the bug this is fixing, too.)Probably no action required here, but something worth keeping notes on (and maybe adding an inline comment on).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, I was considering proposing a refactor of the footer code in such a fashion that effectively each update of the footer content bindable would have its own set of containers, instead of all of them sharing a single one. Something along the lines of:
ScreenFooter.SetButtons()is called.ScreenFooterstarts transforms for disappearing the currently present buttons in the footer, and schedules the disposal of the containers they were stored in for after all the transforms have completed. At this point nothing inScreenFooteror elsewhere should have a reason to touch said buttons or containers.ScreenFootercreates a new set of containers, inserts them into the drawable, and proceeds with inserting the new buttons into said containers and animating their appearance as usual.This approach would effectively sidestep having to manually move the buttons into the hidden containers when changing footer content, and prevent any issues stemming from any mistakes made during such a move.
Just to be clear, I'm not trying to suggest this be implemented right now, I just wanted to ask if it makes sense, and if there's possibly some hidden complexity somewhere that would make this infeasible. Because if there is not, I think this would make the entire footer somewhat more pleasant to understand and work with.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I can tell your proposal only talks about
SetButtons()but not aboutRegisterActiveOverlayContainer(). The latter case is moreannoyinginteresting because not all buttons get offscreened in that case so you can't really just ditch the old buttons - and also they need to be restored once the overlay is dismissed.Am I missing something?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way I see it,
RegisterActiveOverlayContainerwould stay the same as it'd be after this PR is merged. Once an overlay is shown the relevant buttons are offscreened but they still remain in the container for thatscreenspecific footer content. Buttons would get fully offscreened and expired only when the footer content bindable changes.The way I see things, we don't expect the base footer content to be changed while an overlay is present (aside from screen changes I suppose) so I think this should be fine.
Either way, this is a thing to be dealt with in the future, so feel free to ignore this and just focus on this PR instead.