Slashdot Mirror
Qt Jambi, Trolltech releases Qt for Java
Hardingfela writes "Trolltech has released a preview of its long awaited Java bindings for Qt 4. "Qt Jambi technology integrates Qt with the Java programming language, providing new possibilities for both Java and C++ programmers. This technology enables Java developers to take advantage of the powerful features of Qt from within Java Standard Edition 5.0 and Java Enterprise Edition 5.0" More information on the
Jambi press release and tech details in the Jambi whitepaper. To get your copy sign up to the preview license (final release will be also available under an open source license) and download."
Well, I for one welcome our new void setText(String overlords);
7h3$3 4r3n'7 7h3 Ðr01Ð$ ¥0 4r3 £00|{1n9 f0r. M0v3 4£0n9. --OB1
Mekka Hiney Ho.
Badass Resumes
When will we see bindings for the most popular language?
...but why do you care about Qt?
Everytime when their C++ bloat becomes *.o
The combination of fast, good looking Qt widgets, the clean way of writing applications with Qt and the ease of coding that java and Eclipse offer make for a very attractive platform for clean and fast development of graphical applications and great alternative to pure java or mono applications. As long as the Qt library can be easily distributed with the applications that use it, the fact that you're more than one framework should not be a problem.
If version 6 of java will not bring the improvements to the GUI that are promised, Qt + Java is a very attractive alternative for crossplatform development.
Personally, I like Qt's widgets a lot (even though version 4 has a few funny regressions) and the logic used for building the GUI is much nicer than what I know from Swing and AWT. I wish the trolls the best of luck and hope that KDE and free software in general may benefit from this development.
DNA is the ultimate spaghetti code.
+3 Insightful? I'm guessing the ones who modded that aren't programmers.
GUI programming in C is a *pain*, it's awful beyond words. I hate GUI programming, but python + qt (pyqt) actually works very well for that, Qt with C++ requires that awful moc, but at least it's survivable.
If the parent knew anything about Qt and C, he wouldn't have suggested it at all.
For the record, yes, I have done Qt programming with C++ and python, a lot of C coding (for about 10 years), so I'm familiar with all the different aspects in this, unlike, obviously, the parent.
by Anonymous Coward on Monday July 31, @01:31PM
It will take 10,000 days to code anything useful.
Another, although not as funny, reference to Jambi from Pee-wee's Playhouse.
Now only if GTK+ decently supported Windows operating system versions, actually used native style/widgets, and weren't so mind-numbingly bad at performance. The native Java 6 Swing GUI stuff is actually faster than GTK+ now, despite still being in beta (try it yourselves and see!). "GTK+ enthusiasts" tend to be rabid about 'everyone should use this!', but it's overwhelmingly lackluster in performance and memory usage. People should make their own analysis and look into alternatives, not just take the GTK+ word for it. Qt is very well performing, very well behaving (it effectively wraps around native platform widget/engine stuff), and looks like a dream. GTK+ is (disclaimer: in my personal opinion) almost as bad as old X11 apps that just use ancient versions of Motif or Athena. GTK+ just doesn't blend in very well, and (again, opinion) leaves everything to be desired over more robust and compatible libraries.
"A Goddess rarely smiles for she is forced by others to be an island unto herself." - Zephiris
So will Qt Java be supporting widget primitives in Windows like it does for other languages? I'll bet it does, and that will be quite cool, as we will finally see Java apps that truly look & feel native!
I've been playing around with this for a few hours. Running some of their demos, things seem very snappy, and the applications look better than most Swing/AWT applications. I've always been fond of the way Qt works, and I think it will be nice to have the option of using it with Java.
Of course this is still a developer preview. After playing around with it for about 4 hours, I still can't get an application to launch, except for the demos that it ships with. This is probably due to my own ineptitude, but if I'm having trouble with it, I'm sure other developers will as well. I suspect that once there is an official release, things will be made easier (or the documentation will be made clearer) and there won't be so many problems.
PS: If anyone has played around with this and had success, maybe you can help me out. I created a project in eclipse, added the qtjambi.jar file into the classpath, set the PATH to qtjambi-linux-preview/bin and LD_LIBRARY_PATH to qtjabmi-linux-preview/lib, whenever I try to launch an application, I get
failed to load library: 'qtjambi'
Exception in thread "main" java.lang.UnsatisfiedLinkError: no qtjambi in java.library.path
...
Anyway, I think it will be really nice once I can figure out how to use it properly.
Famous Last Words: "hmm...wikipedia says it's edible"
C is a terribly inefficient language for GUI programming - it's all about time to market. How many commercial products can you name that use GTK? Meanwhile, Qt is successfully used all over the place, from Google to Adobe to all that phone stuff.
I appreciate (and not sarcastically) that you took the time to designate that this is your opinion. I'm no GTK+ fanboy, but I think it's cool that you had the class to state your opinions as just that: opinions.
Nah, it isn't all that bad. See, all you have to do is make a structure for your window. Then you set all the properties using preprocessor constants. Next you call some function and get a handle, which is like an object, but isn't. And, since it's a primitive, you can even use your window handle as a mouse handle, icon handle, etc. so it's really versatile! Also, creating a simple GUI in C is a short 50 lines of code, anyone can recite that from memory. Plus, you have the added advantage that C GUI code is tied to your architecture, so you can't port it from Win32 to X to MacOS without a lot of trouble. See? It isn't all that bad!
24 beers in a case, 24 hours in a day. Coincidence? I think not!
I think GTK+ looks fine, but performs slowly. In Linux it isn't bad, not as quick as QT (and I'm not talking KDE bloat but the underlying QT libraries), but sucks in Windows. FYI this is based off my impression of the only GTK+ app I have used in Windows, GIMP, but GIMP was much slower in Windows than Linux. The GUI just seemed laggy to me. Moving palettes around, menus, etc. just wasn't as snappy as in the Linux version or in other Windows apps (including QT apps).
24 beers in a case, 24 hours in a day. Coincidence? I think not!
Why?
+5 Insightful? I agree that GUI programming in C is a pain (and I speak from past experience on this), but GGP was simply asking a question. How come just because you don't want to do GUI programming in C means that someone else shouldn't be allowed to?
Trolltech is obviously trying to branch out and expand the uses of their toolkit to other popular languages. Java is a no-brainer. I wouldn't be surprised if they targeted C# after that. And support for C, which is still very popular, seems like it could be added via the precompiler that's required for their C++ binding.
Attention zealots and haters: 00100 00100
He wasn't showing class, he was being a wimp. He only threw that part in there to try to appease all the tightly-wound sphincterheads around here who would fly off the handle and mod him down. Everything here is opinion.
There's already an open source project called QtSharp http://qtcsharp.sourceforge.net/ that does just that, but it looks like the project has been dormant for a couple of years.
Even without using QtSharp, Qt provides a way to write ActiveX wrappers around Qt objects, which can then be dropped into C# forms and applications.
"To be absolutely certain about something, one must know everything or nothing about it." -- Olin Miller
Has anyone using the QT API noticed that its behavior when it hits an error isn't well-defined or easily detectable by the user of the library? For instance, look at QFileInfo's size member function.
Returns the file size in bytes, or 0 if the file does not exist or if the size is 0 or if the size cannot be fetched.
So, if it returns a zero, that could mean that there is a problem that your application may need to do something about or report, or the file does not exist, or the file exists but is zero bytes. How incredibly uninformative. But at least that member function documents its behavior it something bad happens. As I glanced through the other member functions, it became apparent that most of them do not bother to say what happens when the shit hits the fan. No return codes, no exceptions, no nothing.
Sadly, many of the classes in the library are like this. Sure, I could write an application using QT, but I wouldn't know how to handle failures simply because QT doesn't document the behavior in those cases. This is surprising, considering that QT is considered a quality library that is worthy of use in commercial applications. Granted, most of the time, we'll only execute the "happy path", and there will be no problems with this lack of documentation. However, we shouldn't throw caution to the wind and assume everything will be OK.
I can't help but think that this could have been avoided if QT would have embraced exceptions. Then, the API could avoid using C-like return codes and maintain its elegance but still report errors in a manner that is convenient for handling and documentation. QFileInfo::size() could be documented to throw QFileNotFoundException and QIOException, for example, making it easy for the user of the class to tell what happened. But they would have to rethink some of their code if they did this, because the naked-pointer-filled code that they have now would not be exception safe at all. I doubt that they will make the switch any time soon because everyone seems to be so happy with it the way it is today.
For those of us, who want to be more productive or rather expressive, can try ruby bindings: http://developer.kde.org/language-bindings/ruby/in dex.html
Its still doesn't works on M$ Windows(and if you managed to compile it on Windowz, then kindly send me howto?), but is a joy to develop on Linux.Just don't forget to throw in http://rubyforge.org/projects/rubyinline/ , when you want to do something that really takes CPU cycles and memory.
I can't really see the point of Java(yuck) bindings.Though people at KDE camp were happy, finally they can have fully functional java plugin for konqueror. bless them.
Maybe you need practice. Much of GNOME is written in C. My own schism tracker is written in C. I don't know what you find intolorable about C, but Java programmers are the erotic furries of programming, and C++ programmers seem to be completely oblivious as to what's wrong with their favorite language.
Probably because you're not any good at it.
You are completely detached from reality, aren't you?
Never mind that MOC isn't C++. It's a completely different (and incompatible) language designed to make up for an enormous deficiancy in C++. The fact that the QT people chose C++ for it's popularity instead of it being "a good language" should tell you something.
Post hoc...
So you've been wasting your time because you're still a mediocre programmer living in a fantasy world. And we're supposed to take your word at it? I'm not suggesting anyone take my word for anything- I can or do back up everything I have to say on any subject, including the one about you being nearly incompetent.
Consider for a moment that GNOME is a very large, very complicated, and very strongly backed interface, set of guidelines, libraries, applications, and a desktop. Now consider that the gross majority of it is written in C. Presume all you will about my professional history, are you really saying that you're smarter than everyone at SUN, IBM, Novell, Red Hat, and all the people who have made GNOME what it is today?
QT is a piece of shit. It's a terrible user interface that has had to be completely reinvented incompatibly four times in a language with perhaps the smallest imaginable user base, and by singing its praises, you expect to be taken seriously?
On the off chance I'm completely wrong about you, take a twenty minute tour of Objective-C, Xcode, and Interface Builder, and then tell me that you still want to bear QT's children.
Because QT is written in a fictional programming language (called MOC) - something that makes it different from almost every other toolkit or GUI out there, it's very hard to take it seriously. Think about it: Rather than use a language that is actually good at object-oriented and event-driven programming, (like Python, or Objective-C, or Java), they chose to hang on the popularity bandwagon- they targetted C++ users for the sake of targetting popularity.
That mindset is extremely frustrating: I like to use the best tool for the job, and I've never found a job where C++ was the best tool for technical reasons- only ever because ``that's what the rest of the team is used to/trained with/proficient at'', and I'm sorry, that's a mind-blowingly stupid reason to keep those illiterate programmers around.
Targetting C (or even Objective-C) means that the toolkit or GUI actually has a real interface for programming and interoperability, and not some gross kind of preprocessor or glue code...