On Wed, 20 Dec 2023 16:58:53 GMT, Alexey Ivanov <[email protected]> wrote:
> > > > But I do have another suggestion that actually might have been the best > > > > thing to do all those years ago. Keep the over-ride as the default > > > > behaviour, and document it better. But if the app calls setMaximumSize > > > > or setMinimumSize() then honour it like you are supposed to. I suspect > > > > very few apps actually call these since they are complete no-ops today. > > > > If we do that, then yes, you'll still see differences if you do call > > > > those APIs and forgot about it because it didn't make a difference. > > > > > > > > > Do you mean this way > > > https://openjdk.github.io/cr/?repo=jdk&pr=15325&range=01#sdiff-0-src/java.desktop/share/classes/javax/swing/JScrollBar.java > > > what I had done in the initial iteration? I guess that change will still > > > show the above problem during frame resize, where scrollbars are not rigid > > > > > > This is how I understand Phil's comment. > > As I understand Phil's comment, he suggests using the implementation that you > used in the first iteration of this fix: > > https://github.com/openjdk/jdk/blob/31bbdee8ea71f43eb4863af50b398170a7b81ed2/src/java.desktop/share/classes/javax/swing/JScrollBar.java#L762-L772 > > That is we preserve the current behaviour of `getMinimumSize()` and > `getMaximumSize()` methods in `JScrollBar`, yet if `setMinimumSize()` or > `setMaximumSize()` is called, the corresponding `get-` methods return the set > value and thus they follow the contract specified in `JComponent`. > > @prrace, could you confirm, please? > I already mentioned to him in this comment https://github.com/openjdk/jdk/pull/15325#issuecomment-1818768822 that moving back to initial fix iteration will cause the same problem as you mentioned https://github.com/openjdk/jdk/pull/15325#issuecomment-1796167220 which is the same what we observed when we removed these 2 getXXX methods (which was mentioned in hmuller comment) so if we are OK with the change in behaviour as compared to current, then removing these 2 methods may be considered as compared to moving to 1st iteration of this fix... ------------- PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1873589422
