On quinta-feira, 26 de dezembro de 2013 22:39:03, Mandeep Sandhu wrote:
> > There is no downloadProgress for any intermediate requests. We know that
> > we're redirecting before we get the first byte of data out of the server.
> > At that point, we can abandon the QHttpNetworkReply and move on to t
On quinta-feira, 26 de dezembro de 2013 14:42:21, Richard Moore wrote:
> On 26 December 2013 13:11, Thiago Macieira
wrote:
> > There is no downloadProgress for any intermediate requests. We know that
> > we're redirecting before we get the first byte of data out of the server.
> > At that point,
On sexta-feira, 27 de dezembro de 2013 14:00:38, Elvis Lee wrote:
> But current problem is caused by QtDeclarative. Some object call
> deleteLater, and it's loopLevel is '1' In threaded renderer of QtQuick,
> there is an explicit call for sendPostedEvent(0, QEvent::DeferredDelete)
> Unfortunately,
On sexta-feira, 27 de dezembro de 2013 11:23:39, Elvis Lee wrote:
> Hello.
>
>
>
> I'm looking for good way to handle objects which have called deleteLater.
>
> According to what I understood until now, there are 2 ways to handle them.
>
> One is making control return to the event loop. Anothe
The archs arm, i386, i686, mips and s390 can get their memory exhausted when
building QtWebkit, so at least on Debian we are replacing -g with -gstabs for
those archs. As I understand this comes from a suggestion by Ossi.
I would like to know if you would like to have this replacement done in Qt
On Friday 27 December 2013, Mandeep Sandhu wrote:
> Got it. If there's some content in the 'body' part of the response and
> it points to the same server which sent a redirect, then we could
> reuse the existing connection.
>
> Though it might be a rare case where the redirects will have a 'body'
