General and Desktop

You cannot change a file on disk, XML or otherwise, without writing to it. Would you care to explain why you are so vehemently against rewriting it using QXmlStreamWriter or QDomDocument, as those are your best bets for doing what you would like to do? Your demands for another concept are very confusing (as well as worded somewhat rudely.) Even if you didn't want to use the XML classes to parse and rewrite your file, you would still have to read it and process it and write it out somehow. It sounds as if you're wanting a magic method to shove some white space into arbitrary parts of in the middle of a preexisting file. That is simply impossible to do without rewriting your file some way.

This is good news! Now be a good boy, and add [Solved] to the beginning of a stream header. When I create the installer on Windows, use the "Dependency Walker":http://www.dependencywalker.com/ . This is a GUI application that shows the dependencies needed to run the application (this does not apply to plug-ins).

sierdzio: Thank you for your response. While waiting for an answer I downloaded QT5 to my Mac (Mountain Lion) and I was able to run a couple of examples and create a desktop widget application immediately after QT5 self installed in my machine. For the time being this satisfies my needs. I will follow your advice if at some point I have to work with QT5 for Windows. Best regards FormaxMC

Check the: @QNetworkReply::sslErrors ( const QList<QSslError> & errors )@ signal documentation which states that you should call: @ignoreSslErrors() @ from the slot connect to the signal to receive the behaviour you want to.. Edit: you already found it! :-)

Hi, first you forgot const modifier for heightForWidth function. Second I didn't tested on top level window which seems to be the problem, see "Trading Height for Width":http://doc.qt.digia.com/qq/qq04-height-for-width.html

I'm afraid it's not possible. I'm adding scripting into my app using prototypes to wrap objects. Take a took to it.

So it's more likely to be a Qt bug.

ok. i already post it bug report. https://bugreports.qt-project.org/browse/QTCREATORBUG-8471

Yes, the new "worker object" method is not ideal. Its main weakness is the extra complexity and overhead. I guess we'll need to ask ourselves which poison is more tolerable for the scenario at hand: A lengthy approach, or a counter-intuitive approach? Unfortunately, the documentation update did not pass the review process in time for the Qt 5 release -- there were more pressing issues for the reviewers to take care of, and I think not all the higher-ups are interested in making the change. Let's see if they get through for the Qt 5.0.1 release, scheduled for late January 2013.

Call moveToThread() from the current thread to "push" the object to a different thread. Qt has that constraint because it's dangerous to "pull" an object from a different thread: What will happen if the object is moved, while it is in the middle of processing data in its original thread?

thx too

[quote author="astodolski" date="1355144658"]Thanks, that's helpful. However, shouldn't there be some even basic migration notes included to support a release candidate?[/quote]Looks like there is: http://qt-project.org/doc/qt-5.0/qtdoc/portingguide.html [quote]Where exactly is "here"? Looking at the front end for reporting looks like there are lots. Understand I was following Eddy's suggestion. It may have been better solved on the this forum than calling it in as a bug. That's why I started the thread.[/quote]Sorry for being vague; I meant "we don't have a bug on our hands here". Did the modifications to the .pro file help?

Hi! I'm having a very similar problem (perhaps even the same). I have a qtextedit, and when I copy the content using Ctrl+C and the shutdown the application I end up with the same assertions. You can work around this by clearing the clipboard when the application shuts down, but whats the correct way? BR, Ulf.

So in my case QLayoutItem::widget() returns a 0, I didn't really bother to check it out once did the trick... still can save a runtime type check call

Ok. I wanted to see if the reply wasn't finished before your connect (so the signal would be emitted before being connected to your slot). Maybe you can try "QNetworkAccessManager::finished()":http://qt-project.org/doc/qt-4.8/qnetworkaccessmanager.html#finished instead of QNetworkReply signal. I am not sure it will change anything, but I have no other idea :( .