Slashdot Mirror
In-Depth With Qt 4.4
QtPi writes "Trolltech has announced the availability of Qt 4.4, the cross-platform software development framework. Ars Technica has an in-depth look at the release, which include an integrated WebKit-based HTML rendering engine, the new Phonon multimedia framework, support for Windows CE, and significant improvements to the QGraphicsView system. 'Qt 4.4 brings a lot of rich new capabilities to the toolkit that are sure to please open source and commercial software developers. It sounds like Trolltech already has some nice plans for Qt 4.5, and we will hopefully get to hear more about the long-term roadmap after Nokia completes its acquisition.'"
Great as it is, I can't use it.
On Linux the libraries are now so damn big that non-KDE users wont install them.
On Windows the best development tools are moving away from C++.
On Mac it's just plain ugly.
I'm sure the embedded developers are loving it though.
How we know is more important than what we know.
I really look forward to the Phonon functionality. You can now finally write cross-platform players, capturers, encoders, indexers, mixers, filters and whatnot that'll work across all backends, as Qt is writing the backends for Windows (DirectShow) and OS X (Quicktime) as well. Note: I know not all of these features aren't in 4.4 some are pushed back to 4.5. I really hope this manages to unify the Linux multimedia experience. It's these kinds of deep changes I think are necessary for Linux to succeed in the long run, having to deal with xine/gstreamer/vlc/mplayer which all seem to work on different content but none on all is something the user shouldn't have to do. Having them all in one cross-backend API is a very big step forward.
Live today, because you never know what tomorrow brings
Google Earth is based on QT and it's avalaible for Windows / MacOS X / Linux.
I think that google engineers have studied several tools for developing this program for multiple operating systems and decided that QT was the best toolkit
Kernel Developer: Here's a nice, easy to use sound backend. Enjoy.
Userspace Soundserver developer: Hey, since the Kernel guys can't provide autosense and switching and networked audio, let's abstract it.
Multimedia Framework developer: Hey, because one multimedia backend isn't enough, and isn't portable across OSes, let's abstract it and make it support many different sound servers.
Phonon developer: Hey, because one abstraction's not enough, let's abstract it again!
At this point, you have to wonder, what the hell is the point? You're reinventing the abstraction that everyone else abstracted away. You're adding latency for no reason. You're forcing people to use a toolkit written in a silly language, with the complexity of binding it to other languages being astronomical. What's the win? What are you gaining from this? The answer is simple: GStreamer was Not Invented Here.
This is only tangentially related to the Qt 4.4 release, but it seems to me that, when combined with ActiveQT, this theoretically provides the first ActiveX wrapper around WebKit. This sort of thing would enable hobbyist C# or VB users to quickly get web-driven applications up and running.
As I understand it, at current ActiveQT is only available under the paid licenses, which makes it difficult to create a F/OSS Windows application that uses such a control (which I happen to want to do).
Are there any ActiveX wrappers to WebKit out there (whether using Qt or not) that are suitable for use in F/OSS projects, or - failing that - any other drop-in ways to get a standards compliant browser pane up and running?
That green slime had it coming.
I used to program Qt. I thought it was great. I needed to do some commercial development so I bought a licence. After a while I found that the build system on Windows/Cygwin/Mingw was pretty comprehensibly broken. So I submitted a bug report, detailing what was wrong with a few suggestions on how to fix it.
I got a reply that can be paraphrased as "We can't be bothered".
So I patched the code and sent them the patches.
Reply: "We still can't be bothered". The next release *STILL* had the bug in it.
That's when I stopped using Qt.
Yes, it might be a nice library, but the weiners who write it are still in the OSS mind frame, they think its their toy and they don't have to listen to their customers.
When I've paid money for something, I expect a higher level of support than something I use for free. I don't expect to have to maintain my own fork of the source just to get the bloody thing to compile. This is something that they've failed to realise and why I now use Gtkmm, a library system that *is* truely cross platform.
On a separate point: Once I realised quite how good Gtkmm is I was flabbergasted at how hokey Qt actually is. In comparison with most of the (correct) design decisions made by Gtkmm, Qt is riddled with absolute howlers, e.g. type-unsafe meta compiled signals/slots, arbitrary memory strategy, woeful integration into the STL and a designer that makes me cry with frustration every single time I use it.
(Posting anonymously because bad mouthing companies who have dicked you over now seems to be illegal)
Unfortunately a bolt-on Boehm garbage collector is not real GC. It has to guess what things are pointers and what aren't, so it can get confused by integers that happen to be a valid address. If you think that's unlikely to happen in practice, consider the scope for denial-of-service attacks by feeding in data designed to trick the GC. When dealing with security, theoretical possibilities become all too practical.
Real lambda functions (not Boost's weird simulation) will be cool.
-- Ed Avis ed@membled.com
Yeah, sorry, I meant the MOC.
I do not want to run the MOC myself, neither would I want to have to setup a build action for each file. I just want to press F5 and see my app compile. Anything else detracts from the development process.
I can't buy Qt4, my boss will not buy it.
I did signals/slots programmatically, and it's great. I studied the boilerplate code the MOC creates and simply copied it into templates. Now I don't have to use any special tools.
Another benefit from this is that I can use any function as a slot, even stand-alone functions themselves. I don't have to declare slots any more!!!
I understand that for Trolltech, the signals and slots mechanism is used as a kind of vendor lock in, but for me it's a nuisance, at best.
You can do similar things with Swing but with a LOT more work. Also you'll feel like you're working against the system the whole time you're programming it. I bought a book called "Filthy Rich Clients" after seeing some stuff at JavaOne last year. I got half way through it and realized everything was a hack.