JDK-6432013 : GTK L&F: JScrollPane corners
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2006-05-31
  • Updated: 2011-03-08
  • 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 :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.6.0-beta2"
Java(TM) SE Runtime Environment (build 1.6.0-beta2-b85)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0-beta2-b85, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Linux helium 2.6.12-10-amd64-generic #1 Fri Apr 28 13:18:42 UTC 2006 x86_64 GNU/Linux


A DESCRIPTION OF THE PROBLEM :
The GTK LAF doesn't do anything to suppress the JScrollPane's upper-right corner, which doesn't exist in real GTK+ scrollable views. This means that tables have an unsightly hole in the upper-right corner when using the GTK LAF, compared to a native GTK+ application.

An obvious work-around is to pull the vertical scroll bar out and place it next to the JScrollPane (rather than letting the JScrollPane's custom layout manager lay it out). This *almost* works, but there's a gap where the table has no border. The gap may be because of an assumption that there's a vertical scroll bar taking up that space.

Compare the native GTK+ table and the Java GTK LAF table in the two pictures here:

  http://elliotth.blogspot.com/2006/04/gtk-laf-in-java-6.html

Notice in particular the bounds of the vertical scroll bar are very different. I mention this in passing in 6417110, but I'm here reporting a different problem I found while trying to work around the original problem.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile and run the attached class. Look at the table's border on its right-hand edge, and the top and bottom at the right-hand side. There's a gap of about a scroll bar's width.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Ideally, with the GTK LAF, a JScrollPane wouldn't have a visible upper-right corner unless the developer has put something in the gap. The vertical scroll bar would expand to the top of the header. (A similar feature could be useful on Mac OS; there the header should normally extend all the way to the right, over the top of the vertical scroll bar. I've written about working around that here: http://elliotth.blogspot.com/2006/05/making-jtable-look-more-at-home-on-mac.html).

But it would be good in the Java 6 timeframe (assuming there's no time for the full solution described above) to at least have the border rendered correctly so developers who care enough can make their Java apps more GNOME-like.
ACTUAL -
Not only is the default JScrollPane(JTable) behavior wrong, it doesn't seem possible to correctly work around the default behavior. We're left with an unsightly gap where the right-hand side of the border ought to be.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
    public static JComponent makeScrollable(JComponent c) {
        JScrollPane scrollPane = new JScrollPane(c, JScrollPane.VERTICAL_SCROLLBAR_ALWAYS, JScrollPane.HORIZONTAL_SCROLLBAR_AS_NEEDED);
        if (c instanceof JTable) {
            JPanel panel = new JPanel(new BorderLayout());
            panel.add(scrollPane, BorderLayout.CENTER);
            panel.add(scrollPane.getVerticalScrollBar(), BorderLayout.EAST);
            panel.setBorder(BorderFactory.createLineBorder(Color.YELLOW, 1));
            scrollPane.setBorder(BorderFactory.createLineBorder(Color.RED, 1));
            return panel;
        }
        return scrollPane;
    }

---------- END SOURCE ----------

Comments
EVALUATION This behavior is actually not specific to Synth/GTK, but rather is dictated by ScrollPaneLayout. Note that there is an existing (older) RFE that requests similar behavior, except controlled at the API level: 4199394: JScrollPane - scrollbars + headers should not leave gaps For this particular bug, I suggest that we fix it by providing a private UI default that can be defined by GTKLookAndFeel, and then look for that UI default in the ScrollPaneLayout.layoutContainer() method. (We can leave 4199394 open for a later date, but so far there hasn't been sufficient demand for this feature to warrant an API change; fortunately there isn't much about the fix for 6432013 that should conflict with any future proposed fix for 4199394.) When the GTK L&F is in use, we will adjust the layout for the vertical scrollbar (for scrollpanes only, when column headers are present) so that it fills the upper corner, only if the user hasn't set a custom corner component; in that case, we will fall back on the existing behavior that leaves the corner alone. The same approach will be used for the horizontal scrollbar when row headers are present. This fix will take LTR and RTL differences into account, of course. While we're in fixing this particular issue, we should also resolve one other issue mentioned in umbrella bug 6417110, specifically the issue that "empty" scrollbars do not show the thumb, whereas in native GtkScrollBars, the thumb fills the track in this case. For this issue, we should add another private UI default that is defined only in GTKLookAndFeel, and check for that UI default in BasicScrollBarUI. Instead of calling setThumbBounds(0,0,0,0), we will call setThumbBounds() with the same extents as the scrollbar track, which will exactly match native behavior.
14-11-2006

EVALUATION There might be some problems with this in Synth L&F that GTK L&F uses. SynthScrollPaneUI might be in charge.
01-06-2006