Hallo,

I would like to ask, if someone knows if there are plans (or considerations) to build pluggable look&feel for java's SWING, and make the java apps looking KDE-like. The truth is that Metal java apps look really ugly comparing to the shiny new KDE.

Yes, I know that projects like QT Jambi provide bindings of QT for java, but I am intrested if java apps build on the top of SWING will use QT/KDE look&feel when running under KDE and windows look&feel (as they already do) when started on windows.

I would like to understand little bit why there are "emulated" look&feels for SWIG (windows, gnome), but there is no attempt to use native libraries when implementing custom look&feel in SWING (except http://kdelaf.freeasinspeech.org/ , but I guess it is not developed furthermore). Is it so hard? Is the architecture of SWING not compatible with the architecture of QT/KDE. For which reason?

Explanations are very welcomed. Thank you very much,
Dan

as far as I know, it is possible, but it is hard.

java swing does not use any native graphics api, it use the whole window as a canvas and draw directly on it. It is obvious not compatible with any of the architecture of Qt/Gtk+. So the attempt to use native libraries in java swing may involve dirty hacks or change the internal implementation of java swing.

afiak java swing does not use native graphics api on windows. it simply emulated the look and feel. so that may be an easier way .

Please correct me if I'm wrong.

I believe you can use Java Xswing to create better looking Java apps. I saw some screenshots and they were spectacular. Still, it uses its own drawing tools, so I wonder if you can use the Qt libraries.

You can create custom Java Swing themes, but I suspect that Jambi would add just too much overhead. I think it would be easier writing an Oxygen (or plastique or whatever) theme for Swing.

pansz wrote:java swing does not use any native graphics api, it use the whole window as a canvas and draw directly on it. It is obvious not compatible with any of the architecture of Qt/Gtk+.

I understand, I didn't know that it just drawn on canvas. Thanks, now I can imagine, why it is so hard. What about integration? Let us imagine that there is a KDE look&feel for SWING (emulated), what if I change e.g. theme? Will Java react on this change? I guess no, which is annoying, but correct me.

Due to the fact that all systems use set of more or less similar components (panels, buttons, file-dialogs, progress-bars, ...) I thought that to implement custom L&F it is enough to create set of classes wrapping javax.swing.j* components to your native components (where possible, or if not possible just to draw then), and to register this wrapper into SWING, which seems to me an intuitive approach, as also the philosophy of work with KDE/QT (GTK,...) components is quite similar to java when creating a GUI, I thing.

It is a pity for java, as it lowers its quality in the eyes of ordinary people when looking at old-fashioned Motif style apps compared to the polished rest of their desktop (OK, Gnome users are feeling better ).

BTW, just theoretically, isn't it more work to create canvas drawing methos "emulating" L&F than to create a set of wrappers for existing components (which is not possible now, I know)?

pansz wrote:afiak java swing does not use native graphics api on windows. it simply emulated the look and feel. so that may be an easier way .

I think that you are right that even Windows look&feel is just emulated.

Guys, you're terribly wrong... As Java/Swing developer I'll try to explain...

1. There are some LookAndFeels that are painting directly using graphics. It's Metal, Nimbus and few old-style. And of course there is possibility to use custom painting for any other LookAndFeel, but you need to know it's parameters and colors to paint it right way.

2. Both WindowsLookAndFeel and GTKLookAndFeel are using native invocations to paint themselves. That's why they are using much more memory than "pure java" LookAndFeels, because abstraction level is doubled.

3. There is two main problems in creating KDELookAndFeel:
3a. LookAndFeel stands for both Look and Feel. While it is relatively simple to implement Look, Feel is the most important part, like single clicks for folders, rollover effects, focus system features, hotkeys and many other. KDE is a bit more advanced than other platforms, and of course Sun doesn't want to spend it's time on this. If you know, MacOSX LookAndFeel implemented by Apple themselves. That's why if KDE team want to do it - KDE team should do it. (By the way, I'm ready to help with Java side if there will be somebody from C++/KDE side )
3b. License. KDE used GPL, GTK used LGPL. Sun couldn't link with KDE because of license, so they used LGPLed GTK. Then they started their own NimbusLookAndFeel, for both GNOME and Java. And when they moved to OpenJDK and KDE moved to LGPL - it was too late for Sun to start one more LookAndFeel. As I can remember - one of Nimbus developers stated that it was planned as the very last LookAndFeel by Sun ever.

Regarding Qt Jambi - it's great, but still it is not enought to write powerfull KDE application. It would be great to use Jambi Generator for kdelibs and kdebase, to generate KDE bindings in the same way, but still even Jambi soon will not be supported.

Aekold wrote:3b. License. KDE used GPL

KDE always used LGPL see http://techbase.kde.org/Policies/Licensing_Policy

Aekold wrote:Sun couldn't link with KDE because of license

A Swing LNF is a plugin, it can basically link against anything that is not in violation of the Java licence. If it links against a GPL library, the result would have to be licence in a compatible way, e.g. GPL as well. Not a big issue for a LNF plugin, is it?

Aekold wrote:Regarding Qt Jambi - it's great, but still it is not enought to write powerfull KDE application. It would be great to use Jambi Generator for kdelibs and kdebase, to generate KDE bindings in the same way, but still even Jambi soon will not be supported.

There were Java bindings for KDE even before Qt Software started to work on Qt Jambi, but there weren't enought people working with it or on it to keep them maintained.
You should probably contact the bindings people, either on their mailinglist http://lists.kde.org/?l=kde-bindings&r=1&w=2 or on their IRC channel #kde-bindings (freenode network)

Cheers,
_

anda_skoa wrote:KDE always used LGPL see http://techbase.kde.org/Policies/Licensing_Policy

Hm, libs really are licensed with LGPL. Didn't noticed that before. Thanx for info.

anda_skoa wrote:A Swing LNF is a plugin, it can basically link against anything that is not in violation of the Java licence. If it links against a GPL library, the result would have to be licence in a compatible way, e.g. GPL as well. Not a big issue for a LNF plugin, is it?

It is not a plugin by standard means. Sun released their JRE and JDK as complete product, without additional plugins or something. It's just their Java-related politics, with all that backward compatibility hell and many other blackmagic things. They were never interested in Desktop, and now, when Oracle bought Sun, hardly anything will get better.

anda_skoa wrote:There were Java bindings for KDE even before Qt Software started to work on Qt Jambi, but there weren't enought people working with it or on it to keep them maintained.
You should probably contact the bindings people, either on their mailinglist http://lists.kde.org/?l=kde-bindings&r=1&w=2 or on their IRC channel #kde-bindings (freenode network)

Aye I know, I even tried to use it a bit, but... There are no Java bindings for KDE4 and KDE3 bindings were not enought powerful and maintainable for real application. It looked more like "proof of concept".