Qt 4.5.3 is now available. 4.5.3 is a patch level release providing various bug-fixes over the 4.5.2 release that we issued in late-June. This release also includes new versions of the Qt SDK (2009.04) and the Qt Visual Studio Add-in (1.1.0).
You can get Qt 4.5.3 at http://qt.nokia.com/downloads and you can see the changelog here.
For those using the public git repository, a “v4.5.3″ tag will appear in the repository soon.
As always, your feedback on Qt is appreciated. If you have comments or bug reports, we’d love to hear from you. If you want to contribute to Qt, all the information you need to get started can be found at qt.gitorious.org.
Possibly related posts:
30 comments
Is Snow Leopard officially supported with 4.5.3?
http://qt.nokia.com/developer/changes/changes-4.5.3
Lists far less bug fixes than the Task Tracker lists for 4.5.3.
So where’s the “truth”?
@Axel: As best we can tell 4.5.3 works fairly well on Snow Leopard, but no, it is not officially supported by the 4.5.x series.
@Philippe: the changes file contains those fixes that our developers felt were worth advertising. The changes file is not intended as a complete list of the changes (run “git diff v4.5.2..v4.5.3″ in the public repo for that), but rather is a summary of the most important fixes.
You don’t really want to read about the dozens of license header changes I made in the changes file do you?
It’s hard not to notice that the S60 port is more important than the Apple OSX one, even if it means that there is no stable Qt release for the current OSX release.
Will this change in the future? Or the NokiaApple competition will always have this side effect?
(It’s a bit trollish, but I am just curious how serious is Nokia about Qt on OSX.)
@Axel: For more on our plans for Mac OS support, see http://labs.trolltech.com/blogs/2009/08/31/qt-46-on-mac-os-106/
good job!
The same problem on Snow Leopard like 4.5.2…. “The installer gets to “Validating Packages”, sits there for a long while with a small amount of the bar showing, and then fails the installation.”
What’s the matter?
The ongoing bug N251784, tasktracker 252295 is still broken in the Qt 4.5.3 release based on our mac testing. Tasktracker implies it was to be fixed in 4.5.3, but our testing shows this to not be the case. What this means is that you can’t properly display a centered QScrollArea on a mac without seeing display draw bugs when you resize a window or move splitters around. Intensely frustrating since properly displaying a centered graphics view is such a fundamental operation.
Is there where we’re supposed to vent about bugs that are not fixed yet? If so, I’d like to make a plug for tracker 257335. This one, which only appears to effect Mac/Carbon, is a nasty regression in the 4.5 series (things work fine in 4.4) and is what’s holding me back from deploying builds of our software using 4.5. Specifically, resizing the window causes garbage to show up in horizontal and vertical scroll bars. I wonder if this is related or the same as 252295? Regardless, 257335 is not marked as fixed in the tracker system. I’m quite disappointed this still isn’t fixed. I hope this doesn’t mean I’ll have to wait another 3 months for 4.6 or even more. It’ll be sad if I end up skip deploying with the 4.5.x series entirely.
No .bz2 for Qt 4.5.3
4.6.0 tech preview 1 didn’t have a .bz2 either.
Are you planning to drop .bz2 in general, or was this by mistake?
Thanks
@john dalton: That bug is actually marked as fixed in our internal bug-tracking system. TaskTracker hasn’t been updating for the last two weeks because we are in the process of migrating to a new bug-tracker.
@Alex: The plan at this stage is for us not to ship .bz2 source packages in the future. While they are a little smaller than the .tar.gz packages, they actually increase the bandwidth used on release days and make it take longer for the average user to download a package during the initial flurry of activity following a release. Having two version of the packages decreases the effectiveness of caching and torrents.
The Qt Visual Studio Add-in (1.1.0) yet generate custom builtin for .UI (and others) files with wrong macro “_(QTDIR)/…”: it must be “$(QTDIR)/…” ….
Thanks
Unfortunately, I’ve the same feelings regarding OSX support. There are some very talented engineers behind Qt for Mac OS X, only it seems they are too few to cope up with the ever growing ‘cool’ new features that are added every day to Qt. Maintenance must be a headache. I’ve reported quite a number of bugs for the Cocoa 64-bit port, however, some IMHO serious bugs not even got a priority by now, e.g. 260605 . Sure, the Cocoa port was a large undertaking and I’m really grateful you’ve done this. It made me renew my commercial license but my optimism regarding the timeline to get Cocoa to the point where Carbon was at Qt 4.4 got some scratches lately…
Anyway, I would like to give the Mac engineers a big hug and say thank you!
@Felix: 260605 is not actually a valid bug. I’ve updated the task information giving the reasoning why now (should appear within a hour or so)
I’ve just installed the Qt Visual Studio Add-in. It works. I like it (F1 hit opens Qt documentation in MSDN viewer, cool
). Thanks!
I have one question, is it possible to create single project with build configurations targeting both platforms, Windows (desktop) and Windows Mobile?
For example, I would like to have simple GUI application runnable on both, desktop and mobile systems, and how could I manage single project/solution?
Is MinGW-w64 officially supported for 4.5.3 or will it be in 4.6.0?
@AndyS: Thanks for the update. Actually I’m not calling QApplication::processEvents() but QWidget::close() on an instance of a widget. However, the widget never sends a destroyed(QObject*) signal despite having the attribute Qt::WA_DeleteOnClose set. The q->deleteLater(); call in bool
QWidgetPrivate::close_helper(CloseMode mode) (Qt sources) does have no effect in this case. I’m returning to the event loop and am not calling processEvents() or exec(). Please have a look at the example code I sent with the bug report.
@AndyS: Never mind, your explanation makes sense. I’m calling QWidget::close() via an Cocoa AppleScript handler that most probably circumvents the Qt event loop. I’ll try the proposed solution. Again, many thanks.
Using Visual Studio 2008 Pro, the Visual Studio Add-in (1.1.0) generate bad custom operation for .UI and MOCS, by generating operations with the “_(QTDIR)” macro, instead of the correct “$(QTDIR)”.
Any ideas on how to solve this? Other operations works fine.
Thanks.
Why doesn’t the Mac port of the official “opensource” sdk not include 64bit? Why does it not include Cocoa too?
I have the same feelings on Mac support, is not only difficult to code beautiful Mac Apps (a tutorial showing how to duplicate some of the now common looks found in Mac apps will be great, for example the find text area in the tool bar or how to use widgets in the status bar in a non ugly way) but also disappointed to find basic visual problems on the Cocoa version. In particular: calling setUnifiedTitleAndToolBarOnMac( true ) will draw all the other QMainWindow sub widgets (the center widget, the dock widgets) some pixels “inside” the tool bar.
A pity that a wonderful framework as Qt is suffers from this small details.
Best regards,
David
PS. AH! The visual bug in Snow Leopard for combo boxes has been fixed (and no, is not in the release notes)
@Narvill, @Alex
Unfortunately we were not able to reproduce the problem. Could you please send a mail with a detailed description of the problem or the steps to reproduce it to qt-interest@trolltech.com?
This information would be really helpful in order to fix the problem.
Regards
Olli
@owolff
Mail sent with all detailed information (i hope) as required.
Regards,
Alex
I just downloaded the 4.5.3 evaluation source and attempted a build on Solaris 10 using the Sun Studio 11 compiler. I have all the patches applied to the compiler package. The build stopped in a template oriented part of the designer source. I can’t access the system right now as I’m not at work. There is
a ton of code wrapped up in that top down build. Is there are reasonable subset that will build the library and install it without all the examples? My immediate task is to take some 20 year old Motif/X11 code and track the time/effort required to covert a specified application to Qt with the Motif extensions.
This is a prelude to complete conversion in preparation for moving to a Windows platform. What “tools” are critical to build? I have the entire binary build on my Windows XP netbook. It works as expected. I’m hoping the Solaris build is as good.
I’m back in the office now. The build on Solaris 10/Sun Studio 11 fails when compiling tools/designer/src/uitools the ../lib/uilib/abstractformbuilder.cpp line 1748 says Error: Could not find a match for storeItemFlags needed in storeItemPropsNFlags(QFormInternal::QAbstractFormBuilder*, const QTableWidgetItem*, QList*) while instantiating abstractformbuilder.cpp line 1927 is instantiating
storeItemPropsNFlags(QFormInternal::QAbstractFormBuilder*, const QTableWidgetItem*, QList*). Instantiated from non-template code.
The same gripe is leveled against storeItemsProps for the lines. Does the “instantiated from non-template code raise a red flag here? A portability problem with a hard-coded item?
It appears that the template functions storeItemProps and storeItemPropsNFlags in uilib/abstractformbuilder.cpp lines 1747 and 1748 are not being handled properly by the Sun Studio 11 compiler on Solaris 10. The “missing” template functions cause a failure to match for calls to storeItemPropsNFlags(this, item, &properties) on line 1927.
After some research into the Sun compiler, I discovered that you can add to the CXXFLAGS the item -features=tmplrefstatic
to work around this problem. The build is running now. This change was made only to the Makefile that builds the designer uilib.
I was too optimistic. The change to add -features=tmprefstatic to CXXFLAGS must be performed in many places. Qt has repeated this violation of the C++ standard in multiple locations. My compiler is the Sun Studio 11 CC 5.8 with full patches applied.
Comments on this entry are closed.