Add dumb and manual theme caching systems to Window
#65192
Merged
Conversation
This file contains 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
YuriSizov
force-pushed
the
control-customizable-cache-p2
branch
from
d5a0b9f
to
15fd025
Compare
akien-mga
approved these changes
Sep 1, 2022
|
Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
A continuation of #65156, but for
Windowand its derivatives this time. I've also added the dumb caching system previously introduced for controls in #64314, because that's only reasonable.In relation to windows there is one thing that I didn't touch here, but that needs some rework later on. When a Viewport is handling its subwindows, all drawing code is in the Viewport class, which makes it very inconvenient to introduce the cache, and it also moves responsibilities to outside of Window, and spreads the string usage beyond where we can control it. Juan wasn't against me reworking this bit to organize the code a bit better and encapsulate some of the
Viewport::_sub_window_*methods' logic inside ofWindow. But I'll look into it at a later date.I also want to bring back
WindowDialogremoved during the multiwindow/viewport refactoring. Currently the base "dialog" node isAcceptDialog, which has extra stuff like buttons. IMO a more basic class is needed, and since we used to have it inWindowDialog, it's sensible to me to bring it back. This should also clean up the styles for dialogs, as currently all the base styles are defined inAcceptDialog(and before this PR there was a mysticalDialogstheme type which was manually polled for items, instead of using inheritance like we do elsewhere).Other than that, this is a straightforward version of #65156 for Windows. It's also independent, so if the general concept is approved and the code is good it can be merged before the other one.