Version: unspecified (using KDE 4.6.3) OS: Linux In Java Swing apps, using the com.sun.java.swing.plaf.gtk.GTKLookAndFeel (with oxygen-gtk as the GTK+ theme), tabs look somewhat disjoint, in particular, there's a visible gap between the tab bar and the tab pane, and the tab pane looks clipped off at the top. Reproducible: Always Steps to Reproduce: Try running a Java Swing apps which has tabs in it. Use these JVM switches: -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel -Dswing.systemlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel to make sure it actually uses the GTKLookAndFeel (as opposed to the ugly Metal one, see also http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=729 ). Actual Results: Disjoint tab look with visible gap. Expected Results: No gap. This is less annoying than bug #273828, but still doesn't look all that great. A workaround like the one for Mozilla might be needed here.
-Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel -Dswing.systemlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel I have no idea where to set these ... Any clue ?
Hugo: check the path to executable which runs the program, something like /blabla/bin/javaws.real, go to /blabla/lib/swing.properties or something like this, and add the lines there (without -D)
> -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel > -Dswing.systemlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel > > I have no idea where to set these ... > Any clue ? On the java command line, between "java" and the class or JAR to run. > Hugo: check the path to executable which runs the program, something like > /blabla/bin/javaws.real, go to /blabla/lib/swing.properties or something like > this, and add the lines there (without -D) Unfortunately, as far as I can tell, swing.properties is only checked for defaultlaf, not systemlaf. Ironically, this means that those very apps which go out of their way to integrate properly (by selecting the system look&feel, which is not the default for some stupid reason) are the ones hardest to get to pick the proper look&feel. It's possible to get Swing to pick the GTK+ look&feel by setting GNOME_DESKTOP_SESSION_ID to anything, but that's a very bad idea because it will also make other apps think they're running in GNOME. Hopefully we can get Swing's idea of the system look&feel fixed: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=729 (but Oxygen-GTK not having obvious rendering glitches would help with that ;-) ).
Thanks Ruslan, Kevin. I'm now able to reproduce the glitches, and possibly debug. Will keep you posted.
For the record, I ended up adding swing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel swing.systemlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel To /usr/lib/jvm/java-1.6.0-sun-1.6.0.24/jre/lib/swing.properties Now get oxygen-gtk used everywhere even for web-launched apps.
Ruslan: what do you think of "ApplicationName.isJava() && !ApplicationName.isJavaSwt()" for tagging Swing (not SWT) java applications ? Or are there other (incomplete, and frustrating) java base gtk wrappers on the market ?
... another (possibly usable as safety belt) way to tag widgets for which tab hover is to be disable is to test GDK_IS_WINDOW on the window passed to Oxygen::StyleWrapper. For offline painted notebooks, the rendering is actually done on a pixmap, and the above returns false. As far as I could test, it returns true in all other cases. So I guess something like (isJava() && !isJavaSWT() && !GDK_IS_WINDOW( window ) ) should be safe and robust. (JavaSWT is actually passing a valid window as far as I can tell, so that the above is already redundant). PS: in fact, this check on IS_WINDOW could likely be used elsewhere (where we use mouse pointer to detect hover), either for windows passed to Oxygen::StyleWrapper or on gtk_widget_get_window().
There are also Java bindings for GTK+ itself. (I think even old and new ones.) Those shouldn't need any of those workarounds.
Git commit abcceffd3eb38fef3d49499ce5a82caa5d1cd6c5 by Hugo Pereira Da Costa. Committed on 23/05/2011 at 19:09. Pushed by hpereiradacosta into branch 'master'. Disable tab widgets hover in Java (non-swt) applications when an invalid window is passed as argument to draw_extension. CCBUG: 273829 M +4 -1 src/oxygenstylewrapper.cpp http://commits.kde.org/oxygen-gtk/abcceffd3eb38fef3d49499ce5a82caa5d1cd6c5
Damn it. Wrong bug number :) ok. Will copy paste to the other and close.
@Kevin, thanks for the info. In fact I think the test on GDK_IS_WINDOW is robust enough that the other bindings should not get affected.
Hugo, i think !GDK_IS_WINDOW is just enough to disable hover. You aren't gonna get anything meaningful from invalid windows.
I think Ruslan is right, the checks for Java are not really necessary, if the "window" is not a valid window, we don't really need to look any further, do we?
Not sure. You could imagine some sort of double-buffering I guess ... Still, you guys might be right, and I want to investigate this on a larger scale (e.g. for all the crappy apps around, firefox, openoffice, opera, etc.). Putting that on todo list. That would make a nice 1.1.1 release :) (or 1.1.0, if I have time).
still, the isJava and isJavaSWT checks create virtually no overhead. Its just an enum comparison. So I'd rather leave it like that for the moment ...
Any updates on this? IcedTea finally got changed to make GtkLookAndFeel the default native look&feel under KDE Plasma, so it'd be nice to get this fixed.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.