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
8272148: JDesktopPane:getComponentCount() returns one extra than expected with GTKLookAndFeel #5121
Conversation
…cted with GTKLookAndFeel
|
@pankaj-bansal The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
Can you please clarify why the GTK L&F is affected only? |
Synth L&F is adding a Taskbar in SynthDesktopPaneUI class if the "InternalFrame.useTaskBar" is set true. The "InternalFrame.useTaskBar" is set true in case of GTKL&F only, so this issue is happening. I think L&Fs are allowed to customize these things. https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthDesktopPaneUI.java#L109 |
What if we set this property to false and only set under some condition for GTK L&F, what sort of problem we can expect? Does any jtreg/jck test gets affected if we set it to false? |
I just ran a mach5 job with the "InternalFrame.useTaskBar" set to true with GTKL&F. Link in JBS. I do not see any issue due to this. The failures are not related to this change. My point is that, as discussed in the meeting, this is not related to GTKL&F. Anyone can make a custom container and add some default components and this test will fail for that container. So rather than setting "InternalFrame.useTaskBar" to TRUE for GTL L&F just to solve this issue quickly but wrong way, we should make changes to the spec and state that this is allowed. Similar things could have been done in other components for other L&Fs, which may have not yet been reported. |
I wonder how the other components handle that. For example, the JComboBox in Aqua L&F is a "compound" element and it contains a text field and button, what does the "getComponentCount" return in that case, wIll we hide internal data from the user? |
I just ran the following test for JComboBox for all L&Fs on my Mac. It fails for everyone of them. The test and output is as below. Looks like this test is not being run for all components for all L&Fs. It should give lot of failures I guess. `
` ` Current Look and Feel is Metal Current Look and Feel is Nimbus Current Look and Feel is CDE/Motif Current Look and Feel is Mac OS X ` |
Gentle Reminder to the reviewers |
/label csr |
@prrace The label
|
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 wonder how the other components handle that. For example, the JComboBox in Aqua L&F is a "compound" element and it contains a text field and button, what does the "getComponentCount" return in that case, wIll we hide internal data from the user?
I just ran the following test for JComboBox for all L&Fs on my Mac. It fails for everyone of them. The test and output is as below. Looks like this test is not being run for all components for all L&Fs. It should give lot of failures I guess.
Yep not unexpected which is why I said this needed to be documented at least as high up as JComponent.
And FWIW since nothing said that JComponents are created with no children it is a very weak bug/complaint to begin with !
/label csr |
@pankaj-bansal The label
|
/csr |
@mrserb has indicated that a compatibility and specification (CSR) request is needed for this pull request. |
The CSR is created for this issue https://bugs.openjdk.java.net/browse/JDK-8273356 |
@pankaj-bansal This change now passes all automated pre-integration checks. 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 261 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.
|
/integrate |
Going to push as commit 70c9e02.
Your commit was automatically rebased without conflicts. |
@pankaj-bansal Pushed as commit 70c9e02. |
A container may include few default components as children, which are added to it during creation. Due to this, calling function getChildrenCount on a new created instance may return non zero value. This behaviour may vary according to L&F also, as some L&F may add some default components to a container, but other L&F may choose not to do so.
The current bugs reports that this behaviour looks suspicious as it is expected that a newly created container will have zero children.
Current specification is not clear on this whether it is allowed for a container to contain default components or not. The fix make changes to the specification to clarify the same.
Note: I think this will need a CSR, I will file one after the review is completed
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/5121/head:pull/5121
$ git checkout pull/5121
Update a local copy of the PR:
$ git checkout pull/5121
$ git pull https://git.openjdk.java.net/jdk pull/5121/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 5121
View PR using the GUI difftool:
$ git pr show -t 5121
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/5121.diff