Submitted by Trolltech has released version 3.3.5 of Qt, featuring new compatibility with OSX Tiger, Visual Studio 2005 and GCC4. It also features bug fixes to many of its tools and classes, and as is normal with minor-point Qt releases, features binary and source compatibility with earlier releases in the Qt 3.3 series.
I’m curious to know something here. I don’t really understand what it means when it says “Compatibility with VS 2005.” Does that mean it can compile C#, and VB code? I really don’t know, as I’m not too deep into programming yet, but just a little curious is all. I get the feeling this isn’t the case, but you never know.
Qt can’t compile anything – that’s Visual Studio’s job.
Qt is the GUI toolkit – makes the windows and icons etc.
Compatibility means that you can compile Qt applications using VCC2005, probably using C++, not C# and certainly not VB.
“Compatibility means that you can compile Qt applications using VCC2005, probably using C++, not C# and certainly not VB.”
This compatibility has always been there with Qt (by virtue of the fact that is standard C++ with a couple of build tools, ‘uic’ and ‘moc’). The “new compatibility” that is spoken of is the fact that the visual form designer, resource tool and round-trip code editing are fully integrated into VS .NET. It makes Qt a more serious choice, for those spoilt with the comfort of .NET forms, Delphi and other well-integrated RAD tools.
qt-3.3.4 already worked with gcc4 anyway. So what’s that “new compatibility”?
3.3.4 didn’t work well without patches.
AFAIK it is really only usable with c++ (barring java, python or ruby bindings created by third parties). What that means is that you can use VS 2005 to create c++ programs that use Qt (as opposed to notepad and a command line compiler for example). I wouldn’t mind being wrong here though hehe
It only means you can native compile Qt 3.3.5 with the new Visual Studio version. If you want to use Qt portions within managed .NET code you have to use .NET interop capabilities (COM via ActiveQt or wrapper classes).
> features binary and source compatibility
> with earlier releases in the Qt 3.3 series
Absence of incompatibility from Qt’s side is nice, but binary incompatibility from GCC’s side is a real problem. A stable CXXABI (finally, after -?- years) on Linux would be very, very great. But that’s, unfortunately, nothing that Trolltech can do something about. I’m convinced that Trolltech, known for high-quality products, would do a much better job here, but unfortunately GCC’s manufacturer (some foundation from Boston) doesn’t get its job done. This is a real problem for C++ products like Qt on the Linux platform. Nobody knows whether such a product will actually run in 24 months from now. Now recompilation tips, please. I’m talking about commercial-grade software, the kind of software Qt is intended for.
Two words: static linking.
cheers,
dalibor topic
You know, avoiding static linking is the reason why we dropped goddamn motif in the first place.
So, thanks, but I’d rather not go back to 1992.
“GCC’s manufacturer (some foundation from Boston)”
Nope. GCC is being “manufactured” by the FSF anymore. It’s mainly Red Hat. So please, educate yourself and stop whining about the FSF.
Hopefully whith progresses of the Linux Standard Base, these issues will be addressed.
I might be mistaken, but I believe that GCC 4.0 pledges ABI compatibility going foreword for C++ (I think they were saying that at one point)… So that problem should fall into the ‘solved’ category now. Not that it matters much if you run a free software system, and you can A) Compile from source, B) Recompile your distros source packages (for DEBs and RPMs), C) Just wait for your bloody distro to update… Really, the only people that should have to deal with static compiles are closed vendors, and I don’t care about them anyway
[OK, so long as I can keep some of my Loki games running 
]
Hope they will put diff (or xdelta) files for 3.3.4->3.3.5 and 4.0.0->4.0.1 on their ftp server.
I really can’t understand why most of the softwares don’t get diff or xdelta distributed also. It should at least for the previous release.
P.S. I know OpenSUSE is getting a kind of this stuff. Thanks Novell.
GCC’s steering comitte, which makes the important decisions:
http://gcc.gnu.org/steering.html
As I said in my previous post, it’s mainly Red Hat.
GCC’s steering comitte, which makes the important decisions:
http://gcc.gnu.org/steering.html
As I said in my previous post, it’s mainly Red Hat.
3 People of 13 is “mainly Red Hat”?
If there is a group of me and 3 other people…does that group consist of “mainly me”?
Everybody knows gcc is maintained by Red Hat. Please, stop acting like you don’t know.
“Everybody knows gcc is maintained by Red Hat.”
That is not the point. You(?) said that the steering commitee is mainly Red Hat. I said that I would not agree from reading the page you linked. Nothing to do with maintainership.
“Please, stop acting like you don’t know.”
Well, I must admit that I did not. (And truth to be told I could not care less.)
I always assumed that GCC was a project of the FSF and that Red Hat has many developers on payroll that work on GCC (and deserves much credit for that).
Personally I do not care who maintains GCC as long as someone does 😉
> GCC’s steering comitte, which makes the important
> decisions:
> http://gcc.gnu.org/steering.html
> As I said in my previous post, it’s mainly Red Hat.
Red Hat? Ha Ha, good joke
You know that, for example, SuSE did >90% of the work of the AMD64 port of gcc+tools?
Red Hat happily used the AMD64-gcc when it was ready.
http://www.x86-64.org/contributors/gcc
Yes, it’s mainly Red Hat, but who cares?
> Yes, it’s mainly Red Hat
Did noone tell you that proof by repetition is not valid?
> but who cares?
Obviously you, otherwise you would not keep on repeating it….
But hey, if it makes you happy…. 😉