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."
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"
Just keep the old major version around, what's the problem with that? I have both Qt 1.x and Qt 2.x installed already and I can happily run programs linked against both.
Windows has problems with having different versions of a dll installed at once leading to what is often called dll hell, but this is not a problem with Unix.
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.
Hi!
We will be releasing Qt/Windows 3.0 non-commercial and Qt/Mac 3.0 non-commercial within 1-2 weeks (current release date: 20/10/2001)
Michael
TrollTech A.S.
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
I call bullshit.
Here's a simple exercise: go to the nearest Windows machine, preferably one loaded with lots of apps of various vintages, and delete all but the newest VBRUN*.DLL, MFC*.DLL, etc. Then see how many of your apps work.
When Microsoft releases new widget sets, API's, etc., older applications do not automagically use them. Having, for example, MFC 2 and MFC 3 on your system isn't any different from having Qt 2 and Qt 3 on your system.
What Microsoft did get right, is the installation procedures: have multiple libraries sitting on the same machine if necessary, but don't bother the user about it -- it's not their problem.
Tired of FB/Google censorship? Visit UNCENSORED!
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...