Slashdot Mirror
TrollTech Releases Qt 3.0
Dr. Sp0ng writes: "TrollTech released Qt 3.0 today. Among the new features are platform- and database-independent data-access features, data-aware GUI widgets, a much-updated Qt Designer, and much better internationalization and font handling features. It breaks binary compatibility but keeps almost complete source compatibility with Qt 2.x. The KDE team has already begun work on KDE 3.0, which will use the new toolkit."
And all I can say is, what a joy to work with this QT toolkit is.
Before I wrote software which uses QT, I wrote it using Motif. The designer that comes with QT is light-years ahead of any designer I've used for Motif. The "slot/socket" mechanism that it uses allows me to use a more abstract GUI design. And the geometry management is much nicer as well.
Just thought I'd throw those thoughts in. No, I don't work for Trolltech. Lykke til Trolltech!
Hope I said that right. It's been years.
Amen!
The really cool thing about wxWindows is that at any time somebody could write wxQt, and immediately all wxWindows programs could integrate with KDE as well as they currently integrate with GNOME.
I haven't regretted for a second choosing wxWindows, even if nobody ever writes wxQt, but I sure do like my KDE desktop.
OK, not so many points as I thought...
The short answer is yes, there has been. The biggest problem has been with the C++ libraries, and g++ is finally standardising on a stable ABI.
As for Trolltech, they've always worked hard to maintain binary compatiblity (eg minor releases are binary compatible), indeed there were more
problems with binary compatiblity caused by libstdc++ issues than with Qt itself. I'm not
sure that KDE has been as stable, though this
should improve. (The move to DCOP resulted in growing pains)
To get some appreciation of how fragile binary compatibliity is, read this. Binary compatibility is fundamentally
difficult to preserve in C++, and I don't think there's any clean way around it. Fundamental
changes in interface or exposed structure
(that means anything besides opaque pointers) will break binary compatibility.
Personally, I think the fundamentals need to be
nailed down. C++ and C libraries need to preserve
binary compatiblity. On the other hand, I don't
think there's a problem with other libraries, so long as they maintain binary compatiblity across minor releases. (users could install multiple versions of the same library)
No, it was never just a GUI library. It also included a container class library, strings, streams, graphics file manipulation, and more recently, it has an OO socket implementation, and XML support (Sax and DOM) You're on to something with your Java comment though -- think of it as a C++ version of the Java standard library, if you like.
But won't you still lose binary compatibility when you change the source sufficiently? For instance, don't most C++ compilers use offsets to refer to the various instance variables, and won't those offsets change as you add or remove variables?
I suppose for virtual methods calls you could preserve binary compatibility. Does Qt use virtual methods for everything?
And if everything was virtualized, wouldn't C++ be about as efficient as Objective C (or maybe even GCJ'd Java)? Or is there some fancy translation that C++ will do when linking, for a one-time-only cost (for each application startup, but not every call)?
I know little about the internals of C++ compiled code and linking, so I really don't know.
Having looked at MSFC (yuck!), GTK and Qt, I find that Qt is the toolkit that makes UI programming the easiest
I agree MFC is nasty (I almost had to use Glockenspiel CommonView 10+ years ago, and MS just stole the entire team to write MFC version 1 - I'd already written my own C++ wrapper by then).
except for two things [...] You don't have to bother deleting Qt Objects. It's done by Qt [...] How is this bad?
When you have a large body of code evolving over a period of time, you often want to check such things as resource leakage. This normally means checking that all allocations match up with deallocations (with a GC-ed resource you do this by checking all your GC code works and by checking people use the GC properly). You check this by matching up alloc and de-allocs of whatever resource it is.
If you have a single block of code that runs
alloc resource
use resource
free resource
then you can easily see that this resource is handled properly (ignore true exceptions for now).
On the other hand
alloc resource
if resource allocated
use resource
free resource
end-if
is also correct, but
alloc resource
use resource
if some-condition
free resource
blah-blah-blah
if some-other-condition
free resource
is usually wrong - it breaks the idiom - reviewing this code should set off alarm bells as allocs and frees don't directly match. If the code is genuinely correct (say the 2 conditions are mutually exclusive) then you have to mark it in some way to say "this misuse of the idiom is correct" - often you "mark it" by refactoring the code to use the idiom
alloc resource
use resource
do-the-commonstuff-here
free resource
In C++ the standard idiom is "object construction is resource allocation", and this makes exception handling and some of the refactoring easier - you allocate the resource in the constructor and free it in the destructor. Again, for the reader/reviewer it is easy to see where allocs and frees match up and prove the use is correct
class blah
{
blah() { alloc resource }
~ blah { free resource }
reset { free resource; alloc resource }
}
Again, this is not language specific, but idioms that make it easy to see when your code is correct. That's why adding a function to the above class
set(r) { free resource; resource = r; }
is nasty - you have an unbalanced freeing of a resource so to prove its correct you have to show that everyone who calls set knows how to use it properly. This seems to be the Qt idiom.
How is this bad ? Add 5 years of development with a rotating team of 10 developers (say turnover of 2 a year) and management, and a medium sized code base of 250,000 lines of code across 25 libraries and a dozen executables.... it's 10pm on the night before a release - do you know where all your allocs and frees are ?? On a small project or a small codebase you can hold it in your head "don't worry about these special cases" but in the larger case it makes for problems, and I put enough bugs in my own code without idioms that encourage me to introduce more. I can think of ways to code around it (a wrapper that allocates the class and gives it to the Qt framework, a bit like auto_ptr) but why doesn't Qt do this for me ?
Long answer to a short question - sorry....
T
I spent a lot of money on booze, birds and fast cars. The rest I just squandered. - George Best