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.
Post a Comment
Member since:
2005-07-03
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.
Member since:---
Member since:---
"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.
Member since:
2005-07-06
Member since:---
Member since:
---
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
Member since:
---
Member since:
---
> 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.
Member since:---
Member since:---
Member since:---
Member since:2005-07-07
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 ]
Member since:
---
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.
Member since:
---
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.
Member since:2005-06-29
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"?
Member since:---
Member since:2005-06-29
"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 ;-)
Member since:---
> 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
Member since:---
Member since:---
