In the next release of Java (Code named Mustang) user interface will use more native GUI components. Dimitri from Java2D team announced that in the latest relase of Mustang (Build 42) Gnome native widgets are used for rendering. You can see the related bug, change list for Build 42, and download the latest binary snapsot and code.
Swing = slow
Gtk = slow
Swing + Gtk = you guess
I seem to remember that the last java was able to use (almost) native looking widgets, but only with a few thems like the default gnome and bluecurve. Does anyone know if this is still an issue?
Finally, they’ve come to their senses. On the desktop front, how about working with yout Java-GNOME/GTK people?
I can only hope that it will just be Gtk+-dependent, not additionally on GNOME libraries. Can someone closer to the matter comment on this?
Gnome native widgets or GTK widgets? There is a big difference. One require gnome libs, the other only GTK. It is like claiming that a Qt app is a KDE app. The bug report and feature list say nothing about GNOME.
Apple have done it first.
Swing-programs on MacOSX using the native Aqua-widgets.
Swing isn’t slow… It is the people who are developping for it that don’t know how to use it. I can make a any program slow if you give me access to source code, it is in the way you design it.
The fact that ‘Java’ is interpreted make it likely to be a bit slower than compiled programs, but, it may have very acceptable speed and responsiveness if programmed correctly.
Over the past releases of Gnome widgets have migrated from Gnome to GTK+. The idea is to deprecate libgnome and libgnomeui.
Swing isn’t slow…
I have never alleged, that Swing slow is.
I have only said, that Apple have already done something like that, what Sun now plans with Gtk+.
It have advantages and disadvantages. With native Gtk+ the Java-programs looks like native programs. And by changing the Gtk+ theme, the theme of the Java-programs, changed, too.
But on the other side, the Swing-themes like the Kunststoff LaF have no longer effect.
And Swing can no longer make use of features, which Gtk+ or Aqua don’t support.
One of the advantages to AWT was, that for example pictures can be in an button and so.
Aqua and Gtk+ also supporting it.
But if there existing other nice things, which Gtk+ and Aqua don’t have, than Swing can not integrate it, if it used the native widgets.
Please note that Swing in OS X still has its own widgets. It does however get some help from the underlying OS to draw out its widgets. Basically, the OS’ theming engine will be used to draw out the proper background, borders and decorations at positions indicated by Swing and all the events and user interations are still handled by Swing.
Sun has been adopting this approach since Java 1.4.2 for its WinXP theme and its GTK+ theme. This latest snapshot features improvements in the GTK+ theme.
I hope the editors will clarify the wording in the news entry.
>But on the other side, the Swing-themes like the >Kunststoff LaF have no longer effect.
>And Swing can no longer make use of features, which Gtk+ >or Aqua don’t support.
Swing is not using native widgets, it is using native libraries to draw it’s own widgets, and it is using them ONLY if one chooses GTK+ look and feel. You can use Kunstoff LaF or any other LaF you like, it works just like it was working before. This change has effect only when Swing is forced to use GTK look and feel.
One of the advantages to AWT was, that for example pictures can be in an button and so. Aqua and Gtk+ also supporting it.
But if there existing other nice things, which Gtk+ and Aqua don’t have, than Swing can not integrate it, if it used the native widgets.
As a user, I’d rather use an application developed with snappy, good-looking native controls than the slow, un-professional looking controls that ship with Swing. You can always see and feel the difference in a native Windows app to one developed with Swing (i.e. Swing-based vs SWT-based).
But the netbeans pic (not even sure if it’s posted here) doesn’t have full support for subpixel rendering yet, so the editor fonts will still look strange compared to say the menu fonts.
I still don’t understand why they just can’t use the underlying font engine if they’re going to be using other parts of the gtk+ engine to do the drawing – and go into a fallback mode if gtk+ isn’t there. The same goes for windows.
Just wish this stuff would’ve been done a few years ago.
You can always see and feel the difference in a native Windows app to one developed with Swing (i.e. Swing-based vs SWT-based).
No, you can’t. At least I can’t. I use Java apps on windows and on linux every day and I feel both as fast on the widget side. Take a chance at JEdit (www.jedit.org) and compare it with any other editor. Even Netbeans which is way heavier feels fast. The applications I develop feel fast. The UI widgets performance is not an issue on java.
Yes, you can just look at those fonts on your LCD if you have one.
Errrr WRONG.
They just did a good job of making you -think- that.
Those are just like every other swing widget, PAINTED to look like something else.
People should stop talking authoritatively about things they don’t understand.
I don’t see what the big deal is, it looks like they finally dropped the old Motif based AWT & Java2D implementation and used GTK. I’d wager this code is oodles cleaner. Would’ve been nice to have this to look at while porting to BeOS…
You can always see and feel the difference in a native Windows app to one developed with Swing (i.e. Swing-based vs SWT-based).
No, you can’t.
Yes, you can. You’ve never seen any complaints on Swing’s performance? Why do you think they are?
The applications I develop feel fast.
Figures. You use and like Java therefore it is fast.
The UI widgets performance is not an issue on java.
Yeah. Sure. Whatever.
Is there a screenshot available?
I just tested Mustang demo suit. It looks nice, but it is still not SWT just yet. Look at the FileChooser Demo and compare it to a native FileChooser Dialogue in windows and you will see. But they have done a lot of nice work, I hope they keep working on it and improve speed as well on GTK.
Java is not interpreted.
http://java.sun.com/products/hotspot/docs/whitepaper/Java_Hotspot_v…
JVMs compile java bytecode to native instructions at runtime.
This compilation is very fast (no parsing).
IBM’s and BEA’s JVMs also use similar techniques.
SwingSet works in both windows and GTK, the GTK is considerably slower though, but seem to work flawlessly, FileChooserDialogue is not available for GTK. I switched my XFCE theme and the java application changed also with no problems.
This is a very good approach by SUN, hopefully they get up to same speed as SWT on GTK.
I have often heard from java that they use a “native windows look and feel”, but just juse the drawing engine from windows, which only applies to the look, but the “feel” is much more important.
So the question, are these real gtk_buttons which work like the gtk ones, or is this just a new swing theme, which looks native but still behaves like swing?
kde control about 65% of the desktop under linux…
why sun don’t use qt?
Mustang supports gtk-qt-engine so KDE users can now have matching theme in Swing apps too. It is far from perfect yet but still better than nothing.
why not ditch linux all together, afterall, windows has 90% of the desktop market. because QT is ‘popular, doesnt mean QT is better.
kde control about 65% of the desktop under linux…
why sun don’t use qt?
The argument probably goes back to the licensing issues of LGPL vs GPL.
i.e. If you write a swing app, but then Swing uses the GPL’d Qt on Linux, should your app then be GPL’d, or in turn, should Swing itself be GPL’d?
By using Gtk+, all this confusion goes away, you can write the apps you want with the license you choose.
Same reason why IBM can’t release QT support for SWT, even though its already been developed.
Blame Trolltech, its their fault KDE will forever have licensing problems.
http://forums.java.net/jive/thread.jspa?messageID=17784&tstart=0#17…
Is databingings (like the .NET framework) or any similar technology will be available in the next Swing ?
” You can always see and feel the difference in a native Windows app to one developed with Swing (i.e. Swing-based vs SWT-based).
Yes, you can. You’ve never seen any complaints on Swing’s performance? Why do you think they are? ”
ya i seen but everytime the program was be created by a wanabee…
any good program know to correct that
stop the fud and go reading
http://java.sun.com/products/jfc/tsc/articles/threads/threads3.html
Well, I am sure that Sun Microsystems could afford to buy a few licenses of Qt4 (just released) for their developers if they wanted to use Qt, and no longer be bound to release their code under the GPL.
Otoh, Sun’s betting on Gnome for JDS, so it makes sense to try make the Java applications not stick out on their enterprise desktop offer. And by going the native route, they may be able to save themselves the work of reimplementing look and feels all the time, and use those resources on something else.
cheers,
dalibor topic