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."
How far would Microsoft have gotten if they "broke binary compatibility" with major releases of Windows? Basically, not far at all. That's not to say that Windows has perfect backward compatibility, but I don't think it's too strong a statement to say that one of the reasons Microsoft has dominated is that they have given people an upgrade path for their old applications.
Of course, the downside to this philosophy is the incredibly crufty interfaces to a lot of the Windows functionality. But I think it's key to point out that users don't care at all about those things -- they just care that their applications work.
If the desktop dreamers ever want to see Linux on the desktop, then they need to not destroy everyone's applications if you want to upgrade. Just telling everone to "recompile your applications" is not going to fly well with the typical user.
Sometimes it's best to just let stupid people be stupid.
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.
While having open-source code makes source compatibility easier to handle than binary compatibility, I've been wondering if there has been any work towards improving binary compatibility between versions of major libraries.
This is an issue with C++... since most of KDE's widgets are subclasses of Qt widgets, they are very dependant on the signature of the Qt class. When the class signature changes (for example, when a function is added or removed, or a data member is added), the derived class needs to be recompiled or the linking will be all screwed up. This isn't an issue between minor revisions of the library as the API is stabilized, but with a major jump (2.3.1 -> 3.0), the API or implementation changes and things must be recompiled.
It's impressive that TrollTech (which is a great company, btw) managed to keep source compatibility so well. I'm a professional developer and we're using Qt for our app (which is currently ~20,000 lines), and exactly *1* line of code needed to be changed when we moved from 2.3.1 to the 3.0 betas.
You may write commercial/proprietary/non-free software only if you have purchased the Professional or Enterprise Edition. Qt for Windows is only available as Professional or Enterprise Editions.
So, basically, you can (have to) pay to get away from the GPL/QPL/whatever their license is called these days.
They also sell training.
See http://www.trolltech.com/developer/faqs/general.ht ml?cr=1
Ryan T. Sammartino
"Ancora imparo"
KDE is an impressive desktop, it works nicely, and has really grown. I always play with new releases on a Linux box, though my daily desktop in a Win2K laptop. It's fun to watch Linux's desktop grow, but I need too many Win32 only programs. My G4 Cube is fun as well, but I still have the Win32 problems, so the laptop stays.
However, looking at two "market" outcomes: Win32 vs. Cocoa|Carbon vs. Qt/KDE vs. Gtk, OR Win32 vs. Qt, and you clearly see which API system is more likely to allow competition on the desktop.
Java held great promise, but MS has succeeded in killing desktop Java. Without WORA, there is no real advantage to Java (the platform), but Qt has an interesting perspective.
As Qt Designer grows, it can become competitive to Visual Studio. Potentially, Qt becomes the glue that binds everything together.
If you can build a Qt application for Linux/MacOSX/Win32, or a Win32 app for Win32, there is an advantage to make the former. You still need to QA all the platforms that you support, but Qt lets you produce a product for multiple markets.
For a small company, Linux/MacOS provide a niche to target, but adding Win32 really makes this compelling. The windows market is MUCH more competitive, so being apple to primarily target niche markets but still selling to the dominate market is tempting.
Go Trolls go!
Alex
Okay, here goes.... why oh why is QT in need of database support. It is a cross platform GUI (last time I checked?). Aren't things like cross platform database access left to tools like Java?
===> An eye for an eye makes everyone blind - MG
That's not entirely accurate. You have to pay for using it if you are making money on it and you're developing closed-source apps.
You are free to make money off of Qt-based apps without paying TrollTech as long as you provide source to your customers as per the GPL. This is why distros are allowed to package KDE and any other GPL-licensed software such as Emacs, Gcc, and others.
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.
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)
QT is not free for cross platorm freeware.
Earlier we did not had a very good choice for cross platform GUI, AWT/SWING did not have the performance of native GUI and WxWindows was not powerfull/rich enough.
Then came QT and I thought wow ! this is it, for my next cool application, eventhough I will develop it on Linux, I can make it available for Windows as well as Mac users.
Then I realised its only free on X, you got to pay around 1500$ to get it on other platforms even if you want to write/ditribute a freeware app.
On Windows you pay 50$ after rebates to get a copy of VisualC++ 6.0. And for 50$ you get a compiler, GUI class library, and IDE and debugger. And just for the QT library its 30 times more than Visual C++, how can any hobby programmer afford it ?
I hope Trolltech come out with a more sensible pricing for freeware developers on Windows/Mac which should help QT to gain more acceptance in the non Linux programming community as well.
If you wish to offer non-GPLed code to the world, then yes, you'll need to purchase a license from TrollTech (a great company, from everything I hear). Personally, I really do hope that things go well for them. They're good guys. Does the KDE project have any plans to donate money in their direction?
Personally, I'm a gtk+ man, simply because I prefer C development, and like gtk's handling of classes, types and all that. I also prefer GNOME as a desktop environment. But KDE is sweet, to be sure. It just doesn't do quite what I like. Choice is a Good Thing(tm). I look forward to many years of desktop competition. It should be interesting.
Ahhh...so as long as they use Linux, not Windows, they can do this. Actually, on X11, you can use a number of "free" licenses for the end product, and be compensated for creating it as well.
w in -noncomm.html
The Linux Qt goes out as a "Free Edition" while the Windows Qt goes out as the "Non Commercial" edition, with different restrictions on each.
The GPL is not all-knowing is this case. Reading the GPL tells you nothing about the following, which applies to Qt-win:
"Terms of use"
"Developing and distributing applications"
"Private users may use the Qt non-commercial edition in a non-commercial setting to produce non-commercial applications."
"A non-commercial setting means that you must not use the package in the course of your employment or whilst engaged in activities that will be compensated. A non-commercial application is an application that cannot be sold, leased, rented or otherwise distributed for recompense."
Snipped from:
http://www.trolltech.com/developer/download/qt-
Seems odd to use different licences for different platforms, but I'm sure there is logic in it.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
Sun deserves a lot of credit. If you're going to introduce a Revolutionary New Approach to Programming, you shouldn't do it with inefficient, buggy VMs, or quickie compilers that don't properly exploit garbage collection. Thos mistakes gave Java a reputation for flakiness and inefficiency it still hasn't fully dispelled.
And if you want everybody to start using Java to develop desktop apps, you don't suddenly shut down your own application development efforts before they've had a chance to bring their product to market. But of course IBM, Oracle, and all the other biggies were doing that too. Coinciding with the downfall of the Network Computer.
And that's what really went wrong with desktop Java. Platform independence was never enough by itself to make Java widely adopted on the desktop. You had to give people a reason to abandon their investment in Windows-based solutions. That reason, was the Java-based NC, which was supposed to lower the Cost of Ownership for big corporate computer buyers. (And, not incidentally, give these same buyers a reason to buy proprietary Sun and IBM hardware instead of commodity PCs.) Unfortunately, nobody bought the NC idea, and the main market for Java desktop apps disappeared.
Some, but not all, of this history is repeating itself with Qt and KDE. Being technically superior to Windows wasn't enough for Java, and it won't be enough for the Linux desktop.
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.
You missed QSettings.
It's the registry on Windows, and ~/.foobar files on Unix.
http://doc.trolltech.com/3.0/qsettings.html
Cool, eh?
--
Warwick
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
Yahoo. You don't need a client-server architecture achieve remote usage. There's a program on Windows called Citrix ICA. It allows you to run programs remotely. On a T1, Excel runs only a little slower than running KSpread does locally! The real reason X runs as a seperate process isn't network transparency, but protection. The GUI needs to protected place where it can maintain data about the windowing system. On Windows, this windowing code is put in the kernel. Here, user apps can't crash it, but it can crash the kernel. The only other safe place is a seperate process. In theory, one could put the windowing system into a library, so all UI calls would be simple function calls, but on most chips, there is no way to protect library data structures from the user process. The old x86 segmentation mechanism used to be able to check a memory access based on the privelege level of the segment holding the calling code. If something like this could be done for pages (only the GUI's code pages would have the right to access GUI data), then we could get rid of this whole windowing process crap altogether. But, I digress. That wasn't my point in the first place. I was saying that you could put the window manage in a library and dynamically load it into the X server. The X sever doesn't need to be protected from the window manager, and putting it in a library would offer most of the flexibility of putting it in a seperate process. This would speed up a lot of the window/manipulation operations that are so slow in X today.
A deep unwavering belief is a sure sign you're missing something...