-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Add change handler callbacks from timing screen / components #10330
Add change handler callbacks from timing screen / components #10330
Conversation
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.
seems like a reasonable first step 👍
|
||
/// <summary> | ||
/// Immediately saves the current <see cref="Editor"/> state. | ||
/// Note that this will be a no-op if there is a change in progress via <see cref="BeginChange"/>. |
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.
Not relevant in the context of this PR, as the behaviour described hasn't been changed here, but I find dropping SaveState()
calls entirely a bit risky, maybe? Not sure if I'm being overly paranoid but either always persisting or throwing if a change is in progress seem like better choices from an API standpoint. That said this is probably OK for now until it becomes a problem.
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.
If we go down that path, we'll have to re-think how some of these operations are handled. Right now, batch operations surround smaller ones and reduce the state overhead by calling Begin
/End
.
Addresses part of #10314. As @smoogipoo discovered,
EditorChangeHandler
's patching doesn't support control points, so actually undoing/redoing will have no effect until that is fixed.Also, textboxes will save too many states until framework issue ppy/osu-framework#3912 is addressed. I had a local fix for this prepared, but it's probably not worth it.
I've confirmed via breakpoints that this change behaves as expected.