The KDE Look and Feel Project is a GPL-licenced Swing pluggable look and feel which uses Qt and KDE for the drawing of widgets. KDE Look and Feel implements most of the Java Look and Feel API including dialogs (ColorChooser, FileChooser, etc.).

I know Java needs an independant graphical interface, but the whole swing branch of the framwork (to me) is ugly as sin.

I've probably just been poisoned by .Net Winforms, but the object and method names in swing seem rather meaningless and vague. I've worked on about twenty very small Java applications and swing just left me angry and (more) crazy.

I do hope they can unify the appearance - that's a great accomplishment for the platform in general. I've heard many people complain that Linux looks 'badly thrown together' when it comes to the interface.

Agreed. Apart from the arguably ugly looking widgets and horrible font rendering on many systems, Swing is actually a joy to program in. It is very well designed though some might say overly designed :-)

But the objects I'm mostly referring to are JOptionPane, JPanel, and all of the J(something) objects. It would have been just slightly more intuitive to remove the 'J' prefix, I don't think Microsoft has copyrighted those quite yet.

And the Import JavaX (javax? is that java extension? or just another random suffix?)

I guess I'm one of the few people who likes both Windows.Forms and Swing. Complaining about having to put a J in front of the objects names and importing the javax instead of java is pretty silly, imo. I mean its not like it is confusing or anything. Stick to complaining about speed and aesthetics - you are on much safer ground there.

"its not like it is confusing or anything"
- it really shouldn't be confusing. But since the object is cleary 'a text box' it's unnecessary (imo) to delcare that it is 'a text box in java' - there is no other 'textbox' object, so why the 'J'? And the consistency doesn't seem to be there with many Java objects (Spinner vs JSpinner? whuh?). Its the little things that make a language acceptable (especially for friends of mine learning their first language). It doesn't make the language unusable, or inferior (like lots of .net advocates claim), but it doesn't help the learning curve (or porting from other languages). Maybe this is Microsoft's fault for not using objects similar to those already written in Java, but I think Sun was trying to make Java 'unique' - with some unforseen consequences. It never 'took over the world' like Sun had promised and advertised.

And, yes, the speed is anemic - and aesthetically, there is much to be desired. The only true saving grace is portability, for now. I simply wish Java had been designed with just a little more ease-of-use in mind regarding the framework, there would be many more Java programmers if they had.

The J components are named as they are to be different from the AWT components, which are just named things like "Button".
Just thought that should be cleared up, check out the Java API for more name details.

Swing is an extension of AWT. AWT widgets are native widgets, somewhat like SWT. AWT, however, uses the lowest common widget scheme where if ALL supported platforms don't implement a certain widget, it isn't included in AWT. SWT implements any widgets not available.

Why is this relevant?

If you see an official widget class, like a text box, you know if it's an AWT or Swing widget by the class name.

TextField is AWT
JTextField is Swing

This way you don't have to resort to fully qualified class names in a Java class if you happen to use both types of widgets in the same class. It also makes things CLEARER.

Also, javax is a "proprietary" non-standard package (.NET's copy of this is called a "namespace") for Java classes.

But the objects I'm mostly referring to are JOptionPane, JPanel, and all of the J(something) objects.

The reason for the "J" is probably that Sun needed some way to descriminate between the old java.awt component set that used the native platform for rendering and the new javax.swing components. I.e. there was allready a java.awt.Panel when JPanel was named.

"It would have been just slightly more intuitive to remove the 'J' prefix"

The reason for that was that the compiler messages when you mixed java.awt.* and javax.swing.* were confusing. Rather than fix the compiler (which admitedly would be a hard thing to do for this particular problem) they chose to rename the components. If less people used the .* form of importing the world would be a better place...

"And the Import JavaX (javax? is that java extension? or just another random suffix?)"

The original idea of the "javax" package was that things would move from javax to java when they were placed into the "standard" library. The problem is that that breaks everyones code, and nobody wants to change the imports. They could have provided a tool to alter the imports but that would still wind up leaving the binaries broken. They could have provided a tool to handle the binaries but that is just a hack.

So the decision was to place it into javax and leave it there (same with othr things taht moved from standard extensions into the standard).

They could not put it into the "java" package as some things, such as Netscape Navigator would not allow non-approved classes into the java package.

So, Jxxx to not have naming collisions with java.awt and javax as it started out as an extension and it is too hard to change it to java now.

"so he's not used to things like"
- as we've never met, I can safely say you don't know what I'm used to...

"clean design"
- is something that you can do in any platform/framework, no matter how bass-ackwords it is. The 'namespace' and 'region' features make things very clean, have you ever written anything in .Net? I'm no fan of Microsoft, but sometimes (rarely, but yes it happens) they do come out with something okay.

"writing code"
- ouch. I've only been writing code in C++, PHP, bash, VB4-5-6-.net, Javascript, Java, perl, and python - some for the past thirteen years. Gawd forbid a tool that automates some of the grunt work be used, it's only the year 2006. I must be a traitor to the keyboard - having an illicit affair with the mouse - I guess.

Performance has been much improved in Tiger, and is even better in Mustang.

As far as aesthetics, I agree that the Metal look and feel is horrible. But it only takes a very small amount of work for a programmer to have Swing pick the theme for whatever platform it is running on. Admitedly, Swing L&Fs need a fair amount of work on X Windows yet. But on Windows and Mac, the native themes look pretty damn good. Swing on Mac is virtually indistingushable from a native OS X application thanks to Apple having done such an incredible job on the Aqua look and feel for Swing.

While Sun is finally prioritizing Java on the desktop (Java 1.5 and the forthcoming 1.6 have made big speed optimzations and appearence enhancements to Swing), Java/Swing still need to improve. It's still noticably slower (particularily with long start up times), and the default "Metal" theme is still ugly as sin (and looks alien to the local environment), and anti-aliasing fonts and sub-pixel hinting is still not there (making it look like crap on LCD screens).

Newer Swing themes look better than metal (the default theme in NetBeans looks great). But for whatever reason, "Metal" is still the default. If I understand correctly, Swing uses "Metal" if not otherwise directed, or if it can't find the right theme to blend with the native environment.

This can't continue, if Sun, or the Java world in general, wants Java to succeed on the desktop. Perhaps this is due to Sun being mostly a server company.

By default, Java/Swing has to look fantastic, and be acceptably fast. Otherwise, end users will reject any desktop app written in Java, period.

A QT (or GTK) binding for Swing could improve things dramtically. The screenshots show it as looking just like a native QT/KDE app. And there is the added bonus of QT being very adaptable to the local environment - it can look just like a native Windows app, for instance.

I like Java for a lot of things. I would also like it to be good for GUI development. It's improving, but still has a long way to go. Swing is getting better, and SWT has potential (using Java wrappers around the native GUI toolkit), but SWT is not as easy to deploy.

As far as I know the default theme in 1.5 is not Metal, but Ocean, which is the blue-ish type you probably see in the latest Netbeans. Metal was a specific 1.4 l&f.
Of course another good theme site for Java is: http://www.javootoo.com/
Overall I think the Java UI is improving quite a bit, Ocean doesn't look half as bad as Metal, and a lot of the native skins are fairly good.

>>1. Has never seen Metal
I used Java for 4 year on Windows, Linux, Solaris. I have to say I hate the Metal LAF.

>>2. Is lying

I am not.

>>3. Has very serious psychological and/or sight problems

Maybe that's it. I just don't get it. How come the smart KDE people can come up with such a busy bumpy and noisy theme? I used to love KDE. But no more, as a tech-savvy person, I don't need 20 buttons with 5 configuration options plus tons of eye candies for a file browser. Maybe QT is technologically more advanced then GTK+. Who cares? If I don't use KDE apps at all, what good can it bring to me?

> How many times do we have to hear how superior SWING
> is for GUI apps when the reality is clearly
> the opposite?

Except the reality is NOT the opposite. Swing is one of the most powerful GUI toolkits ever created.

> And that is why it is so widely used and
> enourmously successful on the desktop.

Swing has actually been quite successful for internal applications, and on many new "non general purpose" applications. There is a lot of scientific and engineering software written with Swing that is being used inside various corporations. In addition, a lot of internal GUI database front ends and such in corporations use Swing.

And of course, on the desktop, there are some pretty successful Swing apps out there. ThinkFree Office and Limewire probably being the best known examples.

A while back I wrote a simple mp3/ogg/wav player in java. I wrote different frontends to it to get to know the various toolkits better. It has an SWT frontend for my native looking windows fun, a Swing frontend for cross platformness, and a Qt/KDE frontend for fitting in to my KDE desktop.

Using the Qt frontend, the Gtk-Qt engine for GTK and the KdeLAF, I can make all three frontends use the same Qt style, with varying degrees of success.

This pic is the results, with some commentary. KdeLAF has a little ways to go before I would replace the Qt frontend with it.

I was under the impression the javax package was more for things that are considered experimental and/or subject to potentially compatibility-breaking API changes in the future. Correct me if I'm wrong.

> I was under the impression the javax package was
> more for things that are considered experimental
> and/or subject to potentially compatibility-breaking
> API changes in the future. Correct me if I'm wrong.

javax was originally for extensions to Java that were not part of the core API. However, many of the things that were originally not part of the core API have since been integrated so that they are part of the core API and are included with the standard JRE. However, since moving them from the javax to the java package would have broken too much existing code, they just stayed in the javax package.