JDK-6490646 : GTK L&F: range widgets (JScrollBar and JSlider) rendered unlike native
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-11-07
  • Updated: 2011-03-09
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b07Fixed
Related Reports
Relates :  
Description
This bug report covers two separate, but related, issues with Swing's GTK L&F:

  1) The trough of JSlider is rendered unlike native for certain themes like Human,
     which will highlight the left part of the trough up to the point where the
     thumb is located (with an orange color); this was first reported in umbrella
     bug 6417110.

  2) JScrollBar thumbs under the Human (ubuntulooks) theme do not match their
     native equivalents when positioned at the beginning or end of the scrollbar
     "track".  The JScrollBar thumb will have an extra one-pixel line between the
     "thumb" and the scrollbar button, whereas native scrollbars do not exhibit
     this behavior.

Use the attached JavaWidgetFactory testcase to compare the Swing behavior against
the native behavior in the attached "twf" application.

Comments
EVALUATION There is a common theme connecting these two issues. The problem is that we set up a dummy GtkAdjustment object when we construct native GtkRange widgets. When the Swing scrollbar or slider changes its value, we do not currently update that native GtkAdjustment value so that it stays in sync with its Java equivalent. However, engines like ubuntulooks will actually look at the GtkAdjustment value for a GtkRange widget to determine how to paint it. In the case of (1), ubuntulooks will draw the orange indicator from the left side of the slider trough up to the current position of the slider thumb. In the case of (2), ubuntulooks will avoid painting the line between the thumb and the scroll button when the thumb is at one of the extremes. The fix is very similar for both of these issues. We need to add a new method that allows the painting code to control the native GtkAdjustment value for HSLIDER, VSLIDER, HSCROLL_BAR, and VSCROLLBAR widgets. In the case of (1), it seems that we need to render the slider trough differently at every given position/value, so we probably shouldn't bother caching an image for slider trough regions any longer, since that would unnecessarily bloat the image cache. In the case of (2), we only need to cache three potential positions (minimum, middle, maximum), which will help reduce the burden on the image cache.
07-11-2006