On Tue, 31 Mar 2026 02:09:30 GMT, Prasanta Sadhukhan <[email protected]> wrote:
>> I don't know the original ticket author's intent, but I can think of a few >> use cases where this feature is helpful and extending BasicScrollBarUI is >> actually a nonstarter. >> >> For ex: >> A few years ago I wanted to create a tooltip-like control for sliders. The >> finished result resembles: >> >> https://github.com/user-attachments/assets/76dc92f9-e5f3-4b8e-a32c-ff70e8407928 >> >> This was very hard/hacky, because the thumb rect was not publicly >> accessible. (I ended up calling `slider.paint(g)` with a custom Graphics2D >> that recorded paint instructions to tease out where the thumb was being >> painted.) >> >> In this case I wanted to preserve the existing L&F (either AquaSliderUI or >> WindowsSliderUI), so creating a new subclass of a BasicSliderUI wouldn't >> work. >> >> The same basic idea could apply to scrollbars: I might want to show a >> tooltip that points to the scrollbar thumb. Maybe as you scroll it shows >> some identifying information about what section/chapter that portion relates >> to. >> >> Or I could create a subclass of JScrollBar that preserves the L&F's default >> SliderUI, but the subclass decorates it. Similar to how IntelliJ shows >> stripes in the scrollbar: >> <img width="937" height="268" alt="image" >> src="https://github.com/user-attachments/assets/b2e08b64-c4f7-40a8-b931-648b23f78f97" >> /> >> >> Again: I want to preserve the L&F's SliderUI for a native-looking >> experience, so subclassing BasicSliderUI is problematic. >> >> (Admittedly: scrollbars are a little trickier than sliders because >> AquaScrollBarUI does NOT extend BasicScrollBarUI. WindowsScrollBarUI does...) >> >> My point is: making these methods public may be useful in cases where >> extending BasicScrollBarUI is problematic. > > @mickleness Would current PR help you in that scenario or do you expect more > by making it public? > @prsadhuk Would current PR help you in that scenario or do you expect more by > making it public? I assume the methods should be fully public to really make a difference. IMO putting this in SliderUI is too ambitious. I'd recommend putting it in BasicScrollBarUI to start with. (Even though that alienates AquaScrollBarUI. Mac support could be a separate ticket / PR.) There could be some clever custom ScrollBarUI that doesn't use a conventional "track and thumb" representation. For ex: I think some smartwatches may have a circular track. The BasicScrollBarUI, though, is guaranteed to always have a rectangular track and a thumb. (We should also include some language in the javadoc allowing for zero-width or zero-height tracks and thumbs. Some scrollbars are hidden until mouseover, and some thumbs can become so small they're basically invisible. Can they ever be null? I don't think so, but it's worth asking...) ------------- PR Comment: https://git.openjdk.org/jdk/pull/30209#issuecomment-4159481685
