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.).
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.).
It’s good to see a project to produce a KDE Look and Feel for Swing, since so far most of the “native” L&F effors on Linux have been targetting Gnome / Gtk.
What about the licenses? Is only valid for GPL products?
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.
This does look pretty.
> but the object and method names in swing seem rather
> meaningless and vague.
…How are names like JFrame, JButton, JTable, JList, JComboBox, JDialog, JCheckBox, etc. meaningless and vague? I don’t see how they could have made them much clearer.
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 🙂
Like I said “I’ve alread been poisoned by .Net” – so its mostly me.
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.
The more you know.
Also, javax is a “proprietary” non-standard package (.NET’s copy of this is called a “namespace”) for Java classes.
Errr… you sure about this? Swing is part of the J2SE standard (has been since 1.2) and it resides in javax.
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.
..darcy
Edited 2006-04-12 00:37
The guy programs with .NET, so he’s not used to things like “clean design” and “writing code.”
Swing’s performance and aesthetics are debatable (I personally am not a fan). However, Swing has one of the best technical designs of any toolkit.
I am curious though, if this look and feel matches the theme currently in use by QT. The GTK look and feel theme typically doesn’t work with all GTK themes (or even the most common ones).
I can imagine this must difficult to do, but if themes don’t work properly, what is the point?
“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.
> Swing’s performance and aesthetics are debatable (I personally am
> not a fan).
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.
Surely, the fact that i think that KDE is ugly is pure personal taste.
But don’t tell me that I’m the only one that see the uglyness of font managment in KDE and in this java-theme too !!!
Totally agree. I think that KDE theme is even uglier than Java Swing’s Metal. Maybe kids under 15 with a lot of body piecings will appreciate it.
Anyone who thinks that is uglier than Metal either:
1. Has never seen Metal
2. Is lying
3. Has very serious psychological and/or sight problems
Seriously.
>>Anyone who thinks that is uglier than Metal either:
>>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?
KDE’s UI design philosophy is seriously flawed, esp. Keramik. It’s no wonder that no major enterprise Linux distro uses KDE as the preferred desktop.
For fast, good looking Swing demo software, go to JGoodies. JGoodies adds extensions onto Swing, and makes it look and perform great.
>Swing’s performance and aesthetics are debatable (I
>personally am not a fan). However, Swing has one of the
>best technical designs of any toolkit.
And that is why it is so widely used and enourmously successful on the desktop.
How many times do we have to hear how superior SWING is for GUI apps when the reality is clearly the opposite?
Are you daft? (That was rhetorical, as anyone can plainly see the answer from your comment)
Like I said, Swing’s performance and aesthetics are debatable.
It’s design from a programmer’s standpoint is superb. It is very cleanly designed and implemented.
Swing hasn’t exploded on the desktop, but not because it’s development framework is poor. It used to be slow, and currently still looks “not quite right.”
However, it has not had any real competition in the Java space since it’s inception until now. Once SWT started becoming popular, Sun has really put resources into making Swing work.
I just wish Sun would open source this stuff so real progress could be made.
> 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 bit off-tangeant, but Trolltech promised QT bindings for Java by the first quarter 2006 – anyone hear any news of that effort?
If you’re developing GPL’ed software, you could use the QtJava-binding the kdebinding-project/package are providing.
http://developer.kde.org/language-bindings/java/qtjava.html
Yeah, I know Qt3 only and not official Trolltech-binding.
Edited 2006-04-12 01:47
“I am curious though, if this look and feel matches the theme currently in use by QT. The GTK look and feel theme typically doesn’t work with all GTK themes (or even the most common ones). ”
I tried the demo and yes, the look and feel is native Qt. I have plastik, for instance and it shows all widgets as that of plastik including theme colors etc.
Wow, that sounds fantastic.
GTK and QT work reasonably close to the “Real Thing” maybe I’ll have to take a look at using it for my next project.
Currently, I prefer SWT’s performance and feel but I like Swing’s programming model much more.
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.
http://img130.imageshack.us/my.php?image=toolkitthemecomparisons8tm…
******************
edit: the Swing version looks just fine when using metal or ocean or some other more complete LAF, if metal can be called ‘fine’
Icons work and all.
Edited 2006-04-12 09:16
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.