On Mon, 6 Nov 2023 06:22:33 GMT, Prasanta Sadhukhan <psadhuk...@openjdk.org> wrote:
>> javadoc contract for JComponent.setMinimumSize(Dimension) states: >> >> "Sets the minimum size of this component to a constant value. Subsequent >> calls to getMinimumSize will always return this value..." >> >> However, JScrollBar overrides getMinimumSize() and breaks this contract - it >> always returns a minimum size derived from the preferred size even if you >> have previously called setMinimumSize() >> >> Fix is made to check if mnimumSize is set and if so, honour it.. > > Prasanta Sadhukhan has updated the pull request incrementally with one > additional commit since the last revision: > > Reinstate setEnabled > > 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. > I guess that change will still show the above problem during frame resize, > where scrollbars are not rigid Yes, it will, this is why update to the javadoc of `getMinimumSize` and `getMaximumSize` is required—to document their default behaviour and the fallback to returning the set sizes as per `JComponent` specification of `setMinimumSize` and `setMaximumSize`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1819012794
