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
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
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
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
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
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
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
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
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)
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
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
11 matches
Mail list logo
