JDK-6490642 : GTK L&F: vertical progress bars are 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 :  
JDK-6417110 - various GTK LAF problems
Description
There are a couple issues with JProgressBars under GTK L&F that make them look different
than native GTK progress bars (first reported in umbrella bug 6417110):

  1) Vertical JProgressBars paint the foreground incorrectly; this is most visible
     on themes like Human and Clearlooks that use a gradient.

  2) The preferred width of vertical JProgressBars differs from their native
     equivalents.

Use the attached JavaWidgetFactory testcase to compare against the native behavior
in the attached "twf" application.
Comments
EVALUATION With these fixes in place, things look good on Clearlooks and "Legacy Human" (the old Ubuntu theme based on the clearlooks engine). Unfortunately, there are a couple problems remaining on Ubuntu's Human theme. One problem is that the ubuntulooks engine uses Cairo to perform a patterned fill of the foreground "bar", which is dependent on the x/y location of the area to be rendered. In the case of native GTK, gtk_progress_bar_paint_continuous() will call paint_box(), which goes into the cached offscreen_pixmap used by GtkProgressBar. So the x/y values are relative to the upper left corner of that pixmap. But in Swing's GTK L&F, the x/y values we pass to paint_box() will always start at (0,0), which means that the pattern will not repeat like it does in native apps. I really don't see a good solution for this. Fortunately, it is barely visible in LTR-oriented JProgressBars; it is much more noticeable in RTL-oriented and vertical JProgressBars, but those are much more uncommon in the wild. Therefore, I suggest we punt on this issue for now, and deal with it in the future if it gains more attention.
09-11-2006
EVALUATION 1) We need to differentiate between horizontal and vertical scrollbars (need to have separate HPROGRESS_BAR and VPROGRESS_BAR widgets at the native level). 2) We currently have certain values hardcoded in GTKLookAndFeel defaults: "ProgressBar.horizontalSize", new DimensionUIResource(146, 16), "ProgressBar.verticalSize", new DimensionUIResource(16, 146), SynthProgressBarUI.getPreferredSize() will then add in the insets, which come from GTKStyle.getThicknessInsets(), so in the case of Human theme we end up with 150x20 (or 20x150 for vertical). This is probably okay for horizontal ones, but this is too thin for vertical ones, due to the minimum sizes defined by native GTK (gtkprogressbar.c): #define MIN_HORIZONTAL_BAR_WIDTH 150 #define MIN_HORIZONTAL_BAR_HEIGHT 20 #define MIN_VERTICAL_BAR_WIDTH 22 #define MIN_VERTICAL_BAR_HEIGHT 80 We should probably add some logic to GTKStyle.get() to calculate the preferred size of progress bars more closely to the way it is done by native GTK.
07-11-2006