-
Notifications
You must be signed in to change notification settings - Fork 6.2k
8365389: Remove static color fields from SwingUtilities3 and WindowsMenuItemUI #26783
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
base: master
Are you sure you want to change the base?
Conversation
👋 Welcome back prr! A progress list of the required criteria for merging this PR into |
@prrace This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 77 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
Webrevs
|
acceleratorSelectionForeground); | ||
SwingUtilities3.setAcceleratorForeground(acceleratorForeground); | ||
SwingUtilities3.paintAccText(g, lh, lr); | ||
SwingUtilities3.paintAccText(g, lh, lr, |
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.
I left this private method here rather than calling the SU3 code directly because this method was here all along, before the previous fix. Same for a couple of others.
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.
Previously, these private methods did the work that's now performed by the new methods in SwingUtilities3
.
It's fine to postpone removing these private methods.
acceleratorSelectionForeground); | ||
SwingUtilities3.setAcceleratorForeground(acceleratorForeground); | ||
SwingUtilities3.paintAccText(g, lh, lr); | ||
SwingUtilities3.paintAccText(g, lh, lr, |
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.
Previously, these private methods did the work that's now performed by the new methods in SwingUtilities3
.
It's fine to postpone removing these private methods.
There are still static fields to store colors in |
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.
Removal looks correct when I compare it to the original implementation PR. Double-checked this by building and testing the changes on all OS's and I don't see any issues. LGTM
Yes I do. I overlooked them. |
If you do, this will resolve JDK-8365625 that I submitted a few minutes ago. |
oh. ok. I guess I will look at your test case and confirm that .. and looks like it is a fully done regression test. |
Yes, it is. It was easier to make it a full regression test.
Yeah, I guess so. I didn't look to update this myself initially. When I left my first comment above, I didn't come up with a test that proves there's a bug even though I had a hunch. Now I looked at the code and resolved the bug myself. I also submitted my PR #26826 that's based on yours. I edited the subject of the JBS issue that this PR resolves, now it doesn't reference |
@prrace Your latest commit 1b67651 doesn't address the problem fully, you should also remove I posted a comment where I said that I went ahead and submitted my own PR #26826 to resolve JDK-8365625. My PR removes the static fields from I propose you revert commit 1b67651 and integrate this PR in the state it was last week with the updated subject that doesn't mention |
Shouldn't we keep it in WIndowMenuItemUI
whereas in WIndowsLookAndFeel it is
so I think it would be better to initialize the defaults in the L&F it is currently on |
You are right. What's there just duplicates the super-class. Although I don't know what "problem" it causes.
I thought that was supposed to be a follow-on ONCE this was done and I indicated last week I'd be removing these.
I think this should go as it is, and that follow-on can be updated. Also I just noticed this comment I'd prefer you not have done that. In fact I was puzzled at the PR/JBS mismatch and restored the subject. |
This refactors some Swing code to pass args instead of using statics
The bug report suggests some further refactoring which could be considered later, but the most
important thing to do is to eliminate using statics to pass args.
I've added one other suggestion from the bug report to have the windows case call SU3 directly rather than via newly added static methods, but for the basic case, I left the pre-existing private instance methods.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/26783/head:pull/26783
$ git checkout pull/26783
Update a local copy of the PR:
$ git checkout pull/26783
$ git pull https://git.openjdk.org/jdk.git pull/26783/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 26783
View PR using the GUI difftool:
$ git pr show -t 26783
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/26783.diff
Using Webrev
Link to Webrev Comment