[Bug 729] GTKLookAndFeel should be the system look&feel on all GNU/Linux desktops

[bugzilla-daemon at icedtea.classpath.org]

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=729

--- Comment #26 from Andrew John Hughes <gnu.andrew at redhat.com> ---
(In reply to Mario Torre from comment #17)
> Hi all, I just want to add my opinion on this thread. While I would like to
> see the Gtk LAF as default on Linux (after all, it doesn't really matter if
> you're running on KDE or Gnome, or whatever, the chances you don't have Gtk
> on your system are really 0),

The code looks for the Gtk+ library and will fall back on Metal if it's not
present.

 we can't do this because we would possibly
> break existing applications running Java on Linux.
> 
> Unfortunately, the LAF is one of the critical areas that could make the same
> application render with bugs, behave incorrectly or crash, especially on
> Swing where people reverted to all sort of tricks and custom components;
> that's why the system defaults never changed in years.
> 
> Of course, is equally easy to force a specific look and feel, on the other
> end, I expect bug reports arriving of the sort "getSystemLookAndFeel() gives
> me unexpected result", fixing those bugs will mean reverting this patch,
> which will mean creating an apocalyptic scenario where part of the world
> expect Metal and part expect Gtk, leading to a Schrodinger look and feel
> implementation that will break-fix anyone else! :)
> 
> Seriously, we *could* possibly have this default in JDK9, where people
> expect a certain level of breakage and are usually forced to test their
> applications from scratch, but JDK7 or JDK8 seems way too dangerous being
> the current releases, we really risk to break some application.

This doesn't make it the default. It simply returns it as the system look and
feel on additional GNU/Linux desktops. Prior to this patch, users on GNOME
would get Gtk+ as the system look and feel, while those using Xfce, KDE, etc.
would get Metal. Now everyone on a local GNU/Linux desktop gets the Gtk+ look
and feel as the *system* look and feel, removing the inconsistency between
those who use GNOME and those who choose another DE.

>From the code, I don't think a specific choice of Metal was made for the other
desktops. Rather, checking for "GNOME" rather than an OS covers both the
Solaris and GNU/Linux desktops Oracle test on in one go.

// May be set on Linux and Solaris boxs.                                       
                                                   return
"com.sun.java.swing.plaf.gtk.GTKLookAndFeel";

and I doubt others were considered.

There are plenty of options for turning it off - I used them when testing this
patch - and it's not the *default*; that's still Metal.

Running:

public class TestLnF
{
  public static void main(String[] args) {
    System.err.println("getSystemLookAndFeel: " +
javax.swing.UIManager.getSystemLookAndFeelClassName());
    System.err.println("getLookAndFeel: " +
javax.swing.UIManager.getLookAndFeel());
  }
}

on an *unpatched* RHEL 6 GNOME desktop gives:

getSystemLookAndFeel: com.sun.java.swing.plaf.gtk.GTKLookAndFeel
getLookAndFeel: [The Java(tm) Look and Feel -
javax.swing.plaf.metal.MetalLookAndFeel]

All the patch does is give the user the same result as above if they are
running Xfce, etc. instead.

We did make some progress in doing this just for Xfce upstream; it didn't
really hit any substantial criticism, but wasn't followed through for some
reason. I was just going to go with that, but there didn't seem to be a good
reason to focus on just one desktop when there are so many and, of the
available look and feels in OpenJDK, Gtk+ really is the best fit as a *system*
one for all desktops (i.e. it looks more at home even on KDE than Metal, as
people are used to running Gtk applications on KDE).

I'm aware that there are performance and theme issues, but these are something
that need to be resolved generally, and will already be hit by GNOME users,
regardless of this change.

> 
> Regarding the Gtk3, I indeed mentored a student last year. The work was not
> 100% finished, but working well enough to be a good starting point. As soon
> as I'll find some time I'll start hacking on that, of course anyone is free
> to jump in!
> 
> Here's the current code:
> 
> http://icedtea.classpath.org/people/elideu/gtk3laf/
> 
> Most of it needs to be rewritten, but as I said is a good starting point.
> 
> I would also love to work on a QT version of it.

I was thinking about integrating this for 2.6.0, so it would be available for
users to manually turn on and play with, if they so wished. Thoughts?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140624/3865f3ea/attachment-0001.html>