Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Trolltech Bets on Desktop Java. Releases Qt Jambi
URL: Trolltech
At 6:26 AM on Jun 7, 2007, Michael Urban wrote:
Fresh Jobs for Developers Post a job opportunity
"In addition to adding value to Java developers, current Qt customers who wish to add Java to their current C++ applications now have a solution", said Naren Karattup, product director, developer tools, Trolltech. "Independent studies of our customers indicate more than 25 percent wish to use Qt with Java", he added.
Qt Jambi comes with a powerful development environment for developing desktop applications. In addition, it also has support for Eclipse.
In addition, Qt Jambi makes it easy for developers who wish to combine C++ code with Java code, or port C++ code to Java by including a tool that will create a Java API based on C++ header files.
Qt Jambi also makes it easy for Java developers who wish to port Swing applications by allowing you combine Swing top-level windows and Qt Jambi top-level windows. In addition, the Qt Jambi team is looking into the possibility of being able to combine on a widget basis, so that Swing widgets could be children of Qt Jambi widgets, and vice versa.
Like Qt for C++, Qt Jambi is being released under Trolltech's dual licensing model. It's free for use with GPL software, and can be commercially licensed for other software.
A 30 day trial of Jambi is available, and as a special promotion, if you download in June or July, you will be entered to win a MacBook.
You can also check out a Webstart Demo featuring more than 20 sample applications of Qt Jambi.
The official press release is available here. In addition, there is an interesting intervew at Dr. Dobbs Portal with Naren Karattup, product director of development tools at Trolltech.
Java now has official ports of both major Linux GUI toolkits (GTK and Qt). I wrote an article awhile back titled Desktop Java and Desktop Linux: A Match Made in Heaven? where I argued that Java had a good shot at becoming the default platform for new Linux desktop applications now that it is GPL. And with Trolltech now supporting Java, and Swing's GTK support making major advances, that possibility is looking brighter than ever.
What's your opinion?
38 replies so far (
Post your own)
Re: Trolltech Bets on Desktop Java. Releases Qt Jambi
I find it very hard to see this taking off. For a start, it seems you have to pay 1.5k per platform you develop for unless the app is GPL'ed. From memory, the Windows dev version of Qt is not GPL'ed, so it's hard then to take a Linux-developed GPL Qt app and provide it for windows.Secondly, almost all of the examples I saw could done easily with Swing and Java2D, even though they did look somewhat nicer in Qt with the nice style support.
So, I don't see the sweet spot in the market for this product... For C++ apps wanting to incorporate or retarget to Java, people will be generally looking for a free toolkit. For Java apps, people will look to SWT or Swing...
Andrew
Re: Trolltech Bets on Desktop Java. Releases Qt Jambi
Not to be mean or anything but Nimbus L&F looks way better. Though we are gonna have to wait till 2008 to make it in the JDK let alone till this version is on a majority of all computers.Re: Trolltech Bets on Desktop Java. Releases Qt Jambi
From memory, the Windows dev version of Qt is not GPL'ed, so it's hard then to take a Linux-developed GPL Qt app and provide it for windows.QT4 is GPL on Windows too.
Re: Trolltech Bets on Desktop Java. Releases Qt Jambi
So, I don't see the sweet spot in the market for this product...I think the main target group are already established Trolltech customers who want to have another option regarding programming languages when using Qt.
Trolltech sometimes adds tools or features that at the first glance seem werid, but usually those additions are there because they got a significant amount of requests from their customer base.
Re: Trolltech Bets on Desktop Java. Releases Qt Jambi
> Not to be mean or anything but Nimbus L&F looks way> better.
I have high hopes for the Nimbus lnf. I try the weekly builds with my apps, and it is making good progress. It's some way off unfortunately -- the tree widget is not really usable yet for example...
I think I still prefer the look of Qt. To my eye it looks really clean and always consistent within itself. I can't say the same thing about Swing Lnfs, particularly when used with 3rd party widgets.
Andrew
Re: Trolltech Bets on Desktop Java. Releases Qt Jambi
At first glance, this image viewer could be written in pure and simple Java with Swing in a matter of hours, and it would look just as good.Then pick a L&F, any L&F, and it would look probably better.
Why on earth would I expose my application to some fragile unknown library? I want to *avoid* native code, not interface with it, whenever feasible ofcourse.
Re: Trolltech Bets on Desktop Java. Releases Qt Jambi
Qt is a wonderful toolkit. I have used it extensively with C++ and Python and I really, really like it. I haven't used Qt 4 but it looks great too.Romain Guy's Java Weblog, #ProgX, Jext
Re: Trolltech Bets on Desktop Java. Releases Qt Jambi
Fragile and unknown? Qt has been around for a very long time and it's a great library that has been used in successful large-scale commercial applications: Adobe Photoshop Elements, Google Earth, Skype...Romain Guy's Java Weblog, #ProgX, Jext
Re: Trolltech Bets on Desktop Java. Releases Qt Jambi
Don't forget the biggest of them all....KDE!Re: Trolltech Bets on Desktop Java. Releases Qt Jambi
For GUI programming these days, I generally prefer Swing, for all platforms. It's speed and look and feel have improved so much, and the tools available are so awesome, and NetBeans platform is so good, that Swing is the way to go.However, I have always very much liked the QT GUI toolkit. Of all native toolkits, I've always considered it the best, easiest, best looking, and fastest. QT has long featured bindings for Perl, Python, Ruby, and yes, Java. But none of those were as powerful as the C++ version. And while C++ programming with QT is pretty easy, it would still be nice to use a full Java implementation, and take advantage of the Java language, the VM and the extensive APIs.
Thus, I think QT Jambi is quite cool. And I think it's going to help propel Java to the forefront of desktop Linux development. I also think QT Jambi is goint to be a nice alternative, for regular Java dektop devs, to Swing or SWT.
And I just downloaded the Java Web Start Qt Jambi demos. They look absolutely gorgeous, and are quite fast.
Re: Trolltech Bets on Desktop Java. Releases Qt Jambi
I'm sure that Qt itself is good, but I'm nervous about interfacing to it from Java. It's the stuff that'd happen between Java and Qt that I put question marks besides.For instance, and I'm just speculating here, I want to be able to draw things quickly in Java, and display it, without the pixels having to be transported to a native library. I'd wonder about thread safety, and buffer overruns and other corruptions that might happen as a result of an untested interface layer.
If things can be made to look good completely from within Java, why the need for Qt?
Re: Trolltech Bets on Desktop Java. Releases Qt Jambi
I really seriously dislike KDE. I find it slow to start. It could be because the KDE support processes aren't started yet, when started from a Gnome (I use IceWM actually) session. That's the part I also don't like, those support processes, they seem accessively large. It prints KDE stuff in my terminal, also don't like that.Just installed Fedora 7, tried KDE, expected to see something cool like Mac like zooming icons and a nice fluid experience. Not so. Perhaps I haven't tried hard enough.
Re: Trolltech Bets on Desktop Java. Releases Qt Jambi
I want to be able to draw things quickly in Java, and display it, without the pixels having to be transported to a native library.My guess would be that the drawing calls are passed to the native code, so effectively it will create the rendering.
I'd wonder about thread safety, and buffer overruns and other corruptions that might happen as a result of an untested interface layer.
Hmm, good question. But ifyou consider JNI an untested interface layer, wouldn't the same consideration also apply to other native parts of the class library?
Re: Trolltech Bets on Desktop Java. Releases Qt Jambi
It could be because the KDE support processes aren't started yet, when started from a Gnome (I use IceWM actually) session.This is very likely the main cause. Though its mostly the first startup, any latter is usually faster since the configuration cache is up to date and does not have to be rebuilt.
In any case it is possible to start the basic infrastructure beforehand by running kdeinit.
That's the part I also don't like, those support processes, they seem accessively large
Well, kdeinit will appear large, since it links the main KDE libraries to overcome a runtime linker shortcomming.
dcopserver and kded should be fairly small, unless of course one accidentally looks at the numbers reported by ps or top (not reporting correct sizes due to counting shared parts wrongly)
It prints KDE stuff in my terminal, also don't like that.
If it is caused by output through the KDE logging facility, it is likely that you can disable it through the kdebugdialog tool program.