| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Merge-request: 2411
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
|
| |
|
|
|
|
|
|
|
| |
configuration option on Windows and Symbian platforms.
Improved support of "-system-jpeg" "-system-mng" "-system-png" and "-system-tiff" configuration options on Windows (thanks to Mark Brand <mabrand@mabrand.nl>)
Merge-request: 2411
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The QFileNetworkReply is a wrapper around QFile that
has therefore similar performance. This avoids
the usage of the unperformant QNetworkAccessFileBackend.
The benchmark qfile_vs_qnetworkaccessmanager shows
that the QFileNetworkReply's performance is better
than 0.9x of QFile compared to QNetworkAccessFileBackend
which had about 0.5x of QFile.
Reviewed-by: Peter Hartmann
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On the Mac, it means "-framework ApplicationServices -framework Carbon
-framework AppKit" are no longer part of the default LIBS in Qt
applications. This required a lot of fixes where we used Mac-specific
code in Qt.
On X11, it was very straightforward, because we apparently use very
little of X11 outside QtGui.
I haven't changed the Windows-specific LIBS paths, because I don't
know how Windows behaves. Windows has DLLs, but it links to static
"import" libraries. So is it static linking or dynamic linking?
Reviewed-By: Marius Storm-Olsen
|
| |
|
|
|
|
|
|
| |
Factor our the Channel object to a new file. My goal is to
make QHttpNetworkConnection more maintainable before
implementing HTTP pipelining.
Reviewed-by: Peter Hartmann
|
| |
|
|
|
|
|
|
|
|
|
| |
into qnetworkcookiejar[h,_p.h,cpp].
one adjustment was necessary from the merge request:
The line 110 in qnetworkcookie.h needed to include
qnetworkcookiejar.h, not <QtNetwork/QNetworkCookieJar> .
Merge-request: 1015
Reviewed-by: Peter Hartmann
|
| |
|
|
| |
(cherry picked from commit fd9b788bd6a99630b06cffee4c9fa9f4c06b0ef1)
|
| |
|
