The cause of this bug is related to some general confusion in the source code
of various GTK engines and in GTK+ itself. The code to draw the handle of
toolbars (actually the handle of "handleboxes") comes from gtkhandlebox.c.
The code in draw_textured_frame() always calls gtk_paint_handle() with an
orientation of GTK_ORIENTATION_VERTICAL. This makes sense for horizontal toolbars
(which have vertical handles), but this is totally bogus for vertical toolbars.
So it seems that each GTK engine has come up with a hack to deal with this
situation. For example, clearlooks has this code (see clearlooks_style.c):
/* orientation is totally bugged, but this actually works... */
orientation = (width > height) ? GTK_ORIENTATION_HORIZONTAL :
The ubuntulooks engine has something very similar to deal with this case, and
I suspect most other engines do too.
To complicate matters, we actually have a bug in our GTK L&F code that gets
the orientation backwards. In GTKPainter.paintToolBarHandleIcon(), we
pass the orientation parameter down to GTK directly. The problem with this
is that Synth is actually passing down the orientation of the toolbar, not
the handle. So for example, for a horizontal toolbar we would end up passing
GTK_ORIENTATION_HORIZONTAL to paint_handle(), when we should really be painting
a VERTICAL handle instead.
This explains why we paint the handle incorrectly under Nimbus. With other
themes (Clearlooks, Ubuntulooks, Crux, etc), we were just getting lucky based
on the fact that they compare width/height to determine the orientation of
the handle. But Nimbus doesn't do this; it looks at the orientation passed
to paint_handle(). Therefore we need to fix the code in
GTKPainter.paintToolBarHandleIcon() to effectively reverse the orientation
passed down by Synth before passing it to GTK. This is the first part of the
Now we're painting the handle in its proper orientation (this works for Nimbus
and all other engines too), but unfortunately there is another problem in
that the handle is painted one pixel too short (vertically). The reason for
this is that Nimbus (see nimbus_style.c, draw_handle() method) has a special
hack that decreases the height by one in certain cases. I'll have to discuss
this with the engineer responsible for Nimbus to see how it should be fixed.
I've discussed the height issue with the Nimbus engineer, and we found the
problem (as well as a few others in the Nimbus code), so we decided to file
a separate bug against Nimbus:
6479354: Nimbus: toolbar issues affecting Swing's GTK L&F
So we will fix the Swing-specific bug highlighted above as part of this bug
report (6477839), and then the other Nimbus-specific issues will be fixed
by the JDS team as part of 6479354.