Slashdot Mirror
A Taste of Qt 4
Karma Sucks writes "In 'A Taste of Qt 4', Trolltech reveals that it is positioning Qt 4 directly against Java. Qt 4 promises to be smaller and faster than its predecessors and there will be a boatload of new features including support for non-GUI applications and accessibility under Linux using Sun's ATK. More controversial is the introduction of a new and elegant foreach construct. Incidentally, for those still opposed to Qt's moc preprocessor, Havoc has some interesting comments. It is possible the idea will be adapted to provide GObject introspection in the future."
"Trolltech reveals that it is positioning Qt 4 directly against Java."
And what about Mono?
When KDE released version 3.2, there was a noticable speed improvment for most users. Will we get to see another good speed boost when/if KDE moves to QT4? Here's hoping.
*twitch*
I wonder what sort of shared trademark deal is going on there actually..
-ashot
excuse me for the following expression :
.. what's the case ?
qt vs java ? WTF ?
this is like comparing a ford vs. titanic.
java is much more than some simple thread/socket apis
and visual components.
java has technologies from j2me to j2ee including
huge transactioning clusters which work with thousands
of clients. show me an qt based application server like jboss.
there are none.
so how could you POSSIBLY compare these things ?
java runs anywhere from sun to x86, you don't have to
compile anything if you switch the platform.
with qt you have to. that's the trouble most users don't want to take.
java can work in a cluster where machines are ranged
x86's to ultrasparcs and Apple's G4's. Qt isn't able
to do it. so
it's hard to write a memory leaking application in java
(i know it can be done, i have seen some "java programmers"
who are experts on it, but usually it doesn't happen),
every forgotten free() or a typo in a c/c++ program can
cause you memory leaks.
it's very hard to get a segmentation fault in java, in the
opposite of that you get a catchable exception which
you can handle as you like, as in c i belive everyone
reading this forum has opened the bloody gdb and looked
"where the f do i go wrong here... ?".
gush. who ever wrote the article should be ashamed a bit.
there is absolutely no point in the whole thing whatsoever.
you may define one define that qt the standard of c++ as
j2sdk is for java, but you couldn't obviously compare a c++
library to the whole java business.
I'd tell you the chances of this story being a dupe, but you wouldn't like it.
A Qt widget set target against the Parrot virtual machine would be lovely.
.Net has well, all that Windows stuff (I'm not a big windows graphics programmer)
Just think.
Java has Swing / Eclipse and the old one whose name I can't remember but I did use it a lot but its 7:30am and the coffee hasn't hit me yet.
A Parrot/Qt set would give Perl, Python, Ruby etc a nice graphics toolkit targettable against multiple platforms. Yes I know about Tk/Tcl and WxWindows.
Uurgh. Must get coffee. And train
regards, treefrog
For server-side programming, they'll need their own sort of Servlet API _or_ at least something that connects to Apache (see mod_cpp). There are conceivable ways to implement memory protection for such C++ Servlets, e.g. running each separate Servlet as it's own multithreaded application (another name for SpeedyCGI?)
Why would I use being free() with Qt?
Honest question, not flame.
I read a comment in Doctor Dobbs' Journal more than a year ago to the effect that Qt doesn't teach good C++ practices because most, but not all, objects are managed by the toolkit, in such a way that they must be allocated but never released. People do lots of new() but never any delete().
Is that true?
A friend of mine has some work in this area... Server-side programming in C++...T++ are not very useble yet, but proof it could be done.
http://www.sgi.com/tech/stl/for_each.html would do the trick (and would help in avoiding a large body for for-loop).
So Qt 4 is "positioned directly against Java". Fantastic! Except I read just a few days ago (also here on slashdot) that Qt will keep on blockading the release of a free-of-charge and publicly available version of their Win32 library port.
Now, call me cynical, but how in the hell are you gonna compete with Java, whose foremost strength is the (alleged) platform independency if you kill yourself right away for the most commonly used platform?
As pointed out by many readers already, Mac OS X is not free or Open Source, and does not have a statistically proven larger base of FOSS developers. So offering free Qt library for OS X while categorically denying Win32 is nothing but complete BS. And this new PR crap about "positioning against Java" is simply too laughable seen in this light.
Btw, I prefer KDE over Gnome, so I'm not an "enemy" of Qt per se.
For most people who were in the pre-DotCom Boom you will recall that WebObjects via Objective-C really paved the way for Web Server-Side Development.
The decision to switch it to J2EE was political and at the time, necessary, in order to compete with all the hype.
Remember however, that this "CODE" wasn't washed down the drain. WebObjects leveraged Foundation and AppKit directly. The beauty of Cocoa is that augmenting WebObjects back to Cocoa/Objective-C is extremely trival for Apple.
I would be highly surprised if Steve doesn't decide to throw out the trump with Portable Distributed Objects (PDO) for say OS X version 11 and have it seemlessly work with .NET and J2EE.
What a lot of people who also worked once at NeXT know is that lots of the technologies that were never released are slowly being reincarnated into various pieces of the pie.
As a KDE user you can look forward to a (most likely) KDE 4.0 release that'll start faster and run faster, have smaller memory requirements, look better and have better accesibillity.
And you say there's nothing to be excited about as a KDE user?
So when will KDE 4.0 be released? I have no idea (and I'm not a KDE developer so I have no influence at all - I have just followed the KDE losely for quite a while) but my wild guess would be fall 2005 :)
On Linux, Qt is in the unique position of being seen as one of the native APIs.
I thought that honor belonged solely to Motif...
Put identity in the browser.
Uh... it should have mentioned "positioning QT4 against J2ME", instead of just Java.
It's about graphical toolkits used in cell phones.
First, we need to clear up the confustion from the following statement:
"Qt is positioned as superior alternative to Java".
Trolltech cannot possibly mean that. What they meant to say is: "Qt is an alternative to Java when it comes to cross platform client applications using a GUI". While Qt may do some non-GUI things, too, it's totally different from Java (clue: Qt is not a programming language) and from the Java platform (it doesn't come with a VM, it doesn't have its own bytecode, etc...). What remains is that it's an alternative to Java if you want to deploy applications across Windows, Mac, and Linux. Giving Trolltech the benefit of doubt, this is what they meant.
Having done client-side programming for many years, i can see that there is something to that. I once hoped that Qt would develop into a viable alternative because AWT/Swing was so slow.
However, since then Sun has done their homework and made Swing fast (indistinguishable from native, for the most part), and they are continuing to work on performance in release 1.5. There is still a lot of room for improvement. Things like Apple's library caching - where they pre-compile the native libraries and cache the machine code on the hard disk which makes a Java apps start as fast as a native apps, more hardware acceleration for Swing etc.
Once we get performance out of the way (i have not seen Qt, but i assume it's fast), there is nothing Qt could offer that Java didn't do better.
For example, you don't have to deal with c++. Java is not perfect, but it's - yes we can say that in public - definitely more productive than c++, in the same way that c++ is more productive than asm machine code.
Add to that extensive networking libraries, array bounds checking (buffer overflow exploits not possible in java, imagine that), garbage collection, serious instead of optional OO, and the list could go on and on, no recompiling, runs on more platforms than Qt, free deploy license...
You could argue that COM teaches bad practice because you never explicitly deallocate a COM object. You just call unlock() on it.
Perhaps using a garbage collector is bad practice, too. We should probably therefore stay away from any project like Boehm GC that provides garbage collection in C and C++.
Or maybe automatic ways of managing object destruction are useful tools that make programming easier... I wonder which?
Don't expect to port to Windows without paying the Trolls.
Why on earth not? If you've only ever agreed to the GPL license on their X11 version, there is absolutely nothing they can do to stop you from porting the library, like these people are doing.
But how will they make shared data thread-safe implicitly!? Usually, for MPC, data is just copied. But if different threads share pointers, the access must be synchronized. Will QObjects become Monitors, like Java's Objects?
"Somebody who uses Java is not going to switch to Qt as Java is still simpler."
I wrote Java GUI applications for a few years before having been exposed to C++ (much less Qt). I learned C++ solely so I could use GTK--.
A year later, I found Qt and found myself using it more than I used Java (I had since become disillusioned with GTK--).
Today, I only write Java code if I would otherwise be stuck writing VB. In all other cases, I write C++ with Qt.