Skip to content
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

6664309: Docking point of a floating toolbar changes after closing #14444

Closed
wants to merge 9 commits into from

Conversation

prsadhuk
Copy link
Contributor

@prsadhuk prsadhuk commented Jun 13, 2023

Issue is if we create a floating JToolBar at the EAST side and drag it and then if we close the floating toolbar, then it gets docket at NORTH side instead of the EAST side where it was docked before being floated.
This is because of some contentious code in BasicToolBarUI where we change the constaint to NORTH if it is EAST/WEST.
I could not find any JBS which did that code change.

Albeit, removing that piece of code does not cause regression in "clientlibs" jtreg/jck tests in addition to solve this anomaly, so thought, removing the code seems prudent..


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

Issue

  • JDK-6664309: Docking point of a floating toolbar changes after closing (Bug - P4)

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/14444/head:pull/14444
$ git checkout pull/14444

Update a local copy of the PR:
$ git checkout pull/14444
$ git pull https://git.openjdk.org/jdk.git pull/14444/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 14444

View PR using the GUI difftool:
$ git pr show -t 14444

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/14444.diff

Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented Jun 13, 2023

👋 Welcome back psadhukhan! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

openjdk bot commented Jun 13, 2023

⚠️ @prsadhuk This pull request contains merges that bring in commits not present in the target repository. Since this is not a "merge style" pull request, these changes will be squashed when this pull request in integrated. If this is your intention, then please ignore this message. If you want to preserve the commit structure, you must change the title of this pull request to Merge <project>:<branch> where <project> is the name of another project in the OpenJDK organization (for example Merge jdk:master).

@openjdk
Copy link

openjdk bot commented Jun 13, 2023

@prsadhuk The following label will be automatically applied to this pull request:

  • client

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.

@openjdk openjdk bot added the client client-libs-dev@openjdk.org label Jun 13, 2023
@openjdk openjdk bot added the rfr Pull request is ready for review label Jun 13, 2023
@mlbridge
Copy link

mlbridge bot commented Jun 13, 2023

Webrevs

@prrace
Copy link
Contributor

prrace commented Jun 20, 2023

So there's two things at play here
(1) the orientation property set on the toolbar, which governs how the components on the toolbar are laid out.
(2) the special interpretation by JToolBar of being laid out on one side of a BorderLayout.
I don't know that I really understand why

For drag-out to work correctly, it is recommended that you add JToolBar instances to one of the four "sides"
of a container whose layout manager is a BorderLayout, and do not add children to any of the other four "sides".

my guess is that it just has the right characteristics - the CENTER component would be free to use for the rest
of the window, and empty sides are not an issue, and you can easily make it undock from any edge, and redock
on any edge without affecting layout of the rest of the window.

I've played around with it and it seems to me that the intent of the code you are removing is that
a HORIZONTAL layout implies it was docked on a side that would be HORIZONTAL - but in that
case why NORTH and not SOUTH ?

And I've verified that its perfectly possible, if a bit weird, to have HORIZONTAL toolbar on the EAST
i.e toolbar buttons laid out left to right.

So conflating orientation of the toolbar with the edge on which it is docked is probably wrong.

BTW you should add to the bug evaluation that this code was introduced by the fix for

https://bugs.openjdk.org/browse/JDK-4700351

The reasoning there seems to be a bit back and forth and confusing as to what views won out,
but I do not agree with all the comment.
For example I don't agree that "Also, when placed in a BorderLayout, the orientation should change
to the appropriate value, even if the orientation has been set explicitly"

But PROBABLY most people putting a toolbar on the EAST will make it vertical so I expect few apps
to see an unwelcome change in behaviour here .. but there's always a risk of that.

@openjdk
Copy link

openjdk bot commented Jun 20, 2023

@prsadhuk 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:

6664309: Docking point of a floating toolbar changes after closing

Reviewed-by: tr, prr

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 120 new commits pushed to the master branch:

  • 1120106: 8310458: Fix build failure caused by JDK-8310049
  • 09174e0: 8310049: Refactor Charset tests to use JUnit
  • 99d2a9a: 8310330: HttpClient: debugging interestOps/readyOps could cause exceptions and smaller cleanup
  • 31b6fd7: 8309258: RISC-V: Add riscv_hwprobe syscall
  • 4a9cc8a: 8309266: C2: assert(final_con == (jlong)final_int) failed: final value should be integer
  • 4e4e586: 8310194: Generational ZGC: Lock-order asserts in JVMTI IterateThroughHeap
  • e1906e7: 8310027: Fix -Wconversion warnings in nmethod and compiledMethod related code
  • 4ca548f: 8310326: Incorrect position of the synthetic unnamed class
  • a059576: 8310187: Improve Generational ZGC jtreg testing
  • 9a68ec8: 8219357: G1: G1GCPhaseTimes::debug_phase uses unnecessary ResourceMark
  • ... and 110 more: https://git.openjdk.org/jdk/compare/4d4706967d44b6908406818bb135f94130f373a0...master

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 master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Jun 20, 2023
@prsadhuk
Copy link
Contributor Author

But PROBABLY most people putting a toolbar on the EAST will make it vertical so I expect few apps
to see an unwelcome change in behaviour here .. but there's always a risk of that.

I am not sure on this point being "unwelcome change"....I think even if there is a change in behaviour, it is as per expectation as
If a user docks a "horizontal" toolbar in EAST and then it is dragged and floated and then closed, I think it should be expected to dock the toolbar as it is ie HORIZONTAL in EAST side, that is what it was before docking. If orientation is changed to VERTICAL while in floating state and then closed, then the toolbar should be docked at EAST in VERTICAL state

As you correctly pointed out it is not correct that "the orientation should change to the appropriate value, even if the orientation has been set explicitly" so orientation and docking point should not be changed by the implementation.
Also, it was mentioned in that bug that "The documentation should be changed to clarify this. " which was not done even though the implementation was done so it seems prudent to rectify the implementation.

@prsadhuk
Copy link
Contributor Author

/integrate

@openjdk
Copy link

openjdk bot commented Jun 26, 2023

Going to push as commit a420ff4.
Since your change was applied there have been 179 commits pushed to the master branch:

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Jun 26, 2023
@openjdk openjdk bot closed this Jun 26, 2023
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jun 26, 2023
@openjdk
Copy link

openjdk bot commented Jun 26, 2023

@prsadhuk Pushed as commit a420ff4.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@prsadhuk prsadhuk deleted the JDK-6664309 branch June 26, 2023 09:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client client-libs-dev@openjdk.org integrated Pull request has been integrated
3 participants