Re: [Development] Proposal for allowing handling of HTTP redirects in QNAM

2013-12-26 Thread Richard Moore
On 25 December 2013 07:54, Mandeep Sandhu mandeepsandhu@gmail.com wrote: 3. QNetworkReply stores both, the original as well as the final url. What about the intermediate ones in a chain of redirects? Another question that springs to mind is what should the QNetworkReply object returned

Re: [Development] Proposal for allowing handling of HTTP redirects in QNAM

2013-12-26 Thread Mandeep Sandhu
Your thoughts? The download progress signal will have to be emitted for the intermediate requests. Things like operation() and url() are stored in the request object which can't be changed by the QNAM at all. If people want all the details then they must implement their own redirection

Re: [Development] Proposal for allowing handling of HTTP redirects in QNAM

2013-12-26 Thread Richard Moore
On 26 December 2013 12:45, Mandeep Sandhu mandeepsandhu@gmail.com wrote: Your thoughts? The download progress signal will have to be emitted for the intermediate requests. Things like operation() and url() are stored in the request object which can't be changed by the QNAM at all. If

Re: [Development] Proposal for allowing handling of HTTP redirects in QNAM

2013-12-26 Thread Thiago Macieira
On quinta-feira, 26 de dezembro de 2013 18:15:56, Mandeep Sandhu wrote: We could emit download progress for each intermediate request, but won't that look strange to a user as the bytes received _possibly_ bytes total values will keep changing across these requests? Or is that acceptable

Re: [Development] Proposal for allowing handling of HTTP redirects in QNAM

2013-12-26 Thread Richard Moore
On 26 December 2013 13:11, Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 26 de dezembro de 2013 18:15:56, Mandeep Sandhu wrote: We could emit download progress for each intermediate request, but won't that look strange to a user as the bytes received _possibly_ bytes total

Re: [Development] Proposal for allowing handling of HTTP redirects in QNAM

2013-12-26 Thread Mandeep Sandhu
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 the next already. The downloadProgress signal gives info about the received

Re: [Development] Proposal for allowing handling of HTTP redirects in QNAM

2013-12-26 Thread Mandeep Sandhu
On Thu, Dec 26, 2013 at 8:12 PM, Richard Moore r...@kde.org wrote: On 26 December 2013 13:11, Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 26 de dezembro de 2013 18:15:56, Mandeep Sandhu wrote: We could emit download progress for each intermediate request, but won't that

Re: [Development] Proposal for allowing handling of HTTP redirects in QNAM

2013-12-26 Thread Richard Moore
On 26 December 2013 17:10, Mandeep Sandhu mandeepsandhu@gmail.com wrote: On Thu, Dec 26, 2013 at 8:12 PM, Richard Moore r...@kde.org wrote: On 26 December 2013 13:11, Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 26 de dezembro de 2013 18:15:56, Mandeep Sandhu wrote: We

[Development] [Q] Good way to handle QEvent::DeferredDelete

2013-12-26 Thread Elvis Lee(KwangWoong Lee)
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. Another is calling QCoreApplication::sendPostedEvents(0, QEvent::DeferredDelete)

Re: [Development] [Q] Good way to handle QEvent::DeferredDelete

2013-12-26 Thread Robin Burchell
Hi Elvis, On 27 Dec 2013, at 03:23, Elvis Lee(KwangWoong Lee) kwangwoong@lge.com wrote: 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. Another

Re: [Development] [Q] Good way to handle QEvent::DeferredDelete

2013-12-26 Thread Elvis Lee(KwangWoong Lee)
Hi Robin, So, your application code will be invoked when there is something to respond to (an event) - like a timer, socket activity, user input, etc. When that is done, the control has returned to Qt, and Qt goes back to sleeping, waiting for new events. At some point (I’m not sure if