syncqt is run twice when using the top level configure (as in
the CI system). The pri_install_files and pri_install_pfiles
variables are not populated if the file already exists when
generating the compatibility headers.
Therefore, headers.pri ends up with different content in
each syncqt run. In the first run, the compatibility headers
are part of SYNCQT.HEADER_FILES. In the second run, they
are not part of it since the header files already exist.
Change-Id: I4908fb934a639a3c9f6af1796d56a40fd4df2d50
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@nokia.com>
Implemented as in other shared classes (e.g. QPen).
Change-Id: Ic827540b535fc5506165b5395b796a53a00bb096
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
by using QVarLengthArray so we can avoid the manual clean-up code.
Change-Id: I35e2f7150d777c1760f722553e6fe7a20f6ecc46
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
qdoc prints many error messages without including the
source file path and the line number for where the error
occurs. This makes it difficult to find the place to
fix the error. This update corrects some of those error
messages. Further updates will fix the others.
Change-Id: I9c0eed96482c61643a2d83c5135368413e63ae52
Reviewed-by: Casper van Donderen <casper.vandonderen@nokia.com>
Including a qpa/ header here doesn't really work very well
for other modules using qguiapplication_p.h.
Change-Id: I7620b40bc4731d5a74fe11537637f376c578a786
Reviewed-by: Girish Ramakrishnan <girish.1.ramakrishnan@nokia.com>
QLocale::textDirection() was missing Divehi as a
right to left language.
Change-Id: Ib2395afe0e1dfbac23cb607dbf7833e6c12b2ce9
Reviewed-by: Denis Dzyubenko <denis.dzyubenko@nokia.com>
Introduce a flag matching the Qt::UI_Effect enumeration and
return it as hint.
Replace the separate boolean flags in QApplication by a single
integer using the flags.
Change-Id: I29e33d4d23d13723ddb1b3f62fe781b9c0747572
Reviewed-by: Morten Johan Sørvig <morten.sorvig@nokia.com>
This is to avoid a deadlock that happens when a user thread is
accessing the QNetworkConfigurationManager at the same time the
plugin emits a signal.
i.e.
plugin is holding engine lock
user thread is holding manager lock and blocked trying to acquire
the engine lock
In the manager slot, it tries to acquire the manager lock.
By using queued connection, there are no locks held at the time the
manager slot is called.
Change-Id: I95f28028b5e77f77b2b9b7e31cbd1b78a8fe3097
Reviewed-by: Martin Petersson <Martin.Petersson@nokia.com>
QNetworkSession::open can synchronously emit an error, therefore
we need to queue this.
Otherwise QNetworkReply::finished is emitted before the user has
had a chance to connect the signals.
Task-number: QTBUG-18824
Change-Id: I703d5e31d2934afafabdf0a77ea3aaf5336e8dec
Reviewed-by: Martin Petersson <Martin.Petersson@nokia.com>
Normally we do not have to change moc version if a new type is added,
but for this particular case we need to do it. It is so because the old
moc could generate wrong type id (QMetaType::Char) for signed char.
Change-Id: I20be2a24adc59a305674595dafe23fb1774b475d
Reviewed-by: Kent Hansen <kent.hansen@nokia.com>
Have QDialog::~QDialog() call deleteNativeDialog_sys() on the helpers,
so that we don't risk leaking any resources allocated in the helper.
QFileDialog does this now, but not QColorDialog or QFontDialog. The
Cocoa plugin worked around this problem by calling
deleteNativeDialog_sys() itself, but the Windows plugin does not do
this, resulting in leaks.
Change-Id: I380d87c95686c8f3cb260f9242299be27329280d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
To give applications that want it the option to use a fixed timestep for
animations, and to avoid having values of 60 hard-coded (we have a
couple of those in qtdeclarative/src/quick already), we need to know the
refresh rates of the screens we are rendering to.
Change-Id: Ife49162e830440ad7eab563a27e8aebbbafc5fc5
Reviewed-by: Girish Ramakrishnan <girish.1.ramakrishnan@nokia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
qpa header files were not installed under qpa/.
Change-Id: I243c3a7e83a342f7485791a1a29b65c9a8f25d6b
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
This StandardKey was never defined in Qt4, and should be added to
simplify cross-platform Shortcut handling for this Action.
Comment concerning the sort-order requirement in QKeyBinding is
expanded to discuss the role of Modifier Keys in the Sort Order.
Task-number: QTBUG-25517
Change-Id: I8c26404010f1e55164e25fe6a586d9795869c25f
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Jens Bache-Wiig <jens.bache-wiig@nokia.com>
C++ distinguish between "char", "signed char" and
"unsigned char", they are three independent types.
Fix QVariant behavior on ARM. On ARM "char" may mean
"unsigned char", but we depends on the sign during
a numerical conversions.
Change-Id: I610ce3fb88ed5964b67f3ae442d264fe16b2d261
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
qIsControlChar() doesn't handle SMP code points, it is outdated
and is not used anymore; drop it
Change-Id: I934ace1e44eb2652e426fccc579b563d31197fca
Reviewed-by: Girish Ramakrishnan <girish.1.ramakrishnan@nokia.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
when SMP sybmol is present in the font.
this is a simple typo fix, actually
Change-Id: I54a4df43ece1a36f5c7997d121b7655afb2069e3
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
The implicit cast to QJsonValue was being ignored probably because the
compiler was generating a default QJsonValueRef assignment operator
Change-Id: I3a041595497308868dd7e4aab71027ce21bf8f0b
Reviewed-by: Denis Dzyubenko <denis.dzyubenko@nokia.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Those components are not known to FindGTK2.cmake.
Change-Id: I4a7fe35d7d118168c24285f3ea8f57822b2facff
Reviewed-by: Alexander Neundorf <neundorf@kde.org>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
This doesn't compile with a typical cross-compilation setup, which
generally won't include cups headers. The commit should have been
rejected, but wasn't, due to a bug in the Qt Project CI.
Since it now causes all other modules depending on qtbase to fail their
CI, it must be reverted to minimize disruption while the commit can be
amended and/or the test toolchain updated to include cups headers.
This reverts commit 80f7a38890.
Change-Id: I315ae275b37de358a74af28ab7bd691c9849acba
Reviewed-by: Sergio Ahumada <sergio.ahumada@nokia.com>
Reviewed-by: Toby Tomkins <toby.tomkins@nokia.com>
CUPS is the only supported print system on UNIX, LPR/PS support has
already been dropped but some LPR specific code still remains.
* Move qt_getCupsPrinterPaperSizes from qprinterinfo_unix to
QCUPSSupport
* Remove qprinterinfo_unix as no longer used
* Remove LPR related code from QPdfPrintEngine
* Remove all QT_NO_LPR uses
* Remove most QT_NO_CUPS uses, use QT_NO_PRINTER where necessary
Some QT_NO_CUPS uses remain in QPdfPrintEngine, these will be removed
in a following change implementing a CUPS plugin.
Change-Id: I439b6fad9cf88c3d24aa48e49475f49ad310dbad
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
The main reasons for doing this are:
1. _qpa.h end up in the master QtGui include file. QtGui is meant for
userland applications. qpa code is neither binary nor source compatible.
Inadvertant use of QPA api makes the user code binary-incompatible.
2. syncqt creates forwarding headers for non-private header files. This
gives people the impression that this is public API.
As discussed on the mailing list, even though QPA api is internal and subject
to change, it needs to treated differently from private headers since they
will be used by in-qtbase and out-of-qtbase plugins.
This commit does the following:
1. The _qpa in QPA header files is dropped.
2. syncqt now treats any file with qplatform prefix as a special file and
moves it to qpa/ directory. The recommended way of using QPA API in plugins
is: #include <qpa/qplatformfoo.h>. This allows the user include QPA API
from multiple modules (for example, qplatformfoo might be in QtPrintSupport)
3. The user needs to explicitly add QT += <module>-private to get access to
the qpa api.
4. Creates compat headers for the olden style qplatformfoo_qpa.h and QPlatformFoo
includes.
This commit does not change the cpp filenames. This requires a more careful
merging of existing non qpa cpp files and existing cpp files on a case by
case basis. This can be done at anytime.
The following files are not renamed as part of this changed but will be fixed
as part of a future change:
src/gui/kernel/qgenericpluginfactory_qpa.h
src/gui/kernel/qgenericplugin_qpa.h
src/gui/kernel/qwindowsysteminterface_qpa.h
files were renamed using
for x in `find . -name "qplatform*_qpa.h"`; do git mv $x "${x/_qpa.h/.h}"; done
for x in `find . -name "qplatform*_qpa_p.h"`; do git mv $x "${x/_qpa_p.h/_p.h}"; done
includes were renamed using script
for file in `find . -name "*.h" -or -name "*.cpp" -or -name "*.mm"`; do
sed -i -e 's,.*#.*include.*<\(Qt.*/\)\?\(QPlatform.*\)>,#include <qpa/\L\2.h>,g' \
-e 's,.*#.*include.*"\(Qt.*/\)\?\(QPlatform.*\)",#include <qpa/\L\2.h>,g' \
-e 's,.*#.*include.* "\(qplatform.*\)_qpa.h",#include <qpa/\L\1.h>,g' \
-e 's,.*#.*include.*"\(qplatform.*\)_qpa_p.h",#include <qpa/\L\1_p.h>,g' \
-e 's,.*#.*include.*<\(Qt.*/\|Qt.*/private/\|private/\)\?\(qplatform.*\)_qpa\(.*\)>,#include <qpa/\2\3>,g' \
-e 's,.*#.*include.*"\(Qt.*/\|Qt.*/private/\|private/\)\?\(qplatform.*\)_qpa\(.*\)",#include <qpa/\2\3>,g' \
$file
done
Change-Id: I04a350314a45746e3911f54b3b21ad03315afb67
Reviewed-by: Morten Johan Sørvig <morten.sorvig@nokia.com>
Reviewed-by: Samuel Rødal <samuel.rodal@nokia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@nokia.com>
The use of these went away in Qt 4 commit
f7d61dab69308f0993c8a5f2232226d1713ac4a7.
Change-Id: I0bcd52cf59f653e5b699fa7cfaf4be510bac6b88
Reviewed-by: Samuel Rødal <samuel.rodal@nokia.com>
Change-Id: Ie19c338ed6449ea1509306cbda5dc251295783ae
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
The overload of this method was renamed
in b64426248d but this one was not.
Change-Id: I60a6ddf0fcf9deea31ccf51e7b0db16c66023356
Reviewed-by: David Faure <faure@kde.org>
Reviewed-by: Thorbjørn Lund Martsum <tmartsum@gmail.com>
Some return values were empty, or missing. Use QByteArrayLiteral.
Change-Id: Ib9f124dea1245c000c53098164bf29e78eaa13d2
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
- Add a method returning a QMultiMap<int index, QString key>
to QFactoryLoader, determined from metadata(), correctly
reflecting the data structure ('Keys' being a list)
- Add convenience templates to create plugins via factory
interfaces
Change-Id: I247749aa3245f635e476605db1c4cd9c74b74dea
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
We already have the necessary enablers in QOpenGLExtensions.
Change-Id: I90d763516d8b92c09c878133552200c94a46fbf2
Reviewed-by: Gunnar Sletta <gunnar.sletta@nokia.com>
Document that physicalSize() should return the size in millimeters.
Change-Id: Idf1283aa9b303bcb95361688f2ef663979bc6516
Reviewed-by: Gunnar Sletta <gunnar.sletta@nokia.com>
This also tests by consequence that the behaviour of QByteArrays
containing NULs is consistent. Right now, that means the QByteArray
processing stops at the NUL, which is the same behaviour as if a
pointer to the byte array's data were used. (it's what happens if
there's no QByteArray overload and the const char* one is called)
Change-Id: If56a822f95866e8cb5b153d07b48198bb83fb386
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
This commit completes the previous commit so that both QString and
QStringBuilder now operate on UTF-8 input.
A small fix was required in QStringBuilder: an if clause isn't enough
to separate the two append versions. Since there are no QString
functions that append to char*, if we're converting to a QByteArray,
we need to go through a QString first in a separate function.
Change-Id: Ic503340c5d0c32d420c90c91cc2e0fc1ae9230f3
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
This is a crude change, not the most efficient way. I'll clean up and
make it prettier later on, when I've had the chance to optimise the
UTF-8 codec too.
Change-Id: I78e30e8d3bddf6ad0210c9c4cedb9a7ce63d1a7d
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
This operation should be a no-op anyway, since at this point in time,
the fromAscii and toAscii functions simply call their fromLatin1 and
toLatin1 counterparts.
Task-number: QTBUG-21872
Change-Id: I052a3412a568ad639f2bf169b4491b56dddff1c7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The file has been UTF-8 encoded for years, which means that the line:
QString longerBLOB( "abcdefghijklmnopqrstuvxyz¿äëïöü¡ " );
Loaded a mojibake into QString. Then, this data was stored as a blob
in the database by calling longerBLOB.toLatin1() (a QByteArray), and
reloaded for check using toString().
Once the QString default codec changes to UTF-8, the mojibake would
get fixed, and the test would fail. Make sure it doesn't happen.
Change-Id: If12d6124c973e4a1c1b7978d90fffb9aa5545c66
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Change-Id: I405e8d1cfbf7f0607f8525f9c8c93053109478d9
Reviewed-by: Andreas Holzammer <andreas.holzammer@kdab.com>
Reviewed-by: Kevin Krammer <kevin.krammer@kdab.com>
Reviewed-by: Samuel Rødal <samuel.rodal@nokia.com>
If QtCore is built with Qt 5.0 API, the Q_CORE_EXPORT does not appear
anywhere and these functions wouldn't get exported, despite being
defined. So make sure that they get the Q_CORE_EXPORT attribute.
Change-Id: I0684ea1b9ad634c13dca12c97683032e44f6a290
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
Change-Id: Iaf1a6495ee96859af9c5c25a54ea1fc463910cd3
Reviewed-by: Alexander Neundorf <neundorf@kde.org>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
This operation should be a no-op anyway, since at this point in time,
the fromAscii and toAscii functions simply call their fromLatin1 and
toLatin1 counterparts.
Task-number: QTBUG-21872
Change-Id: Icb3ab0e1f4f3173563f3de36115b5457cf1ba856
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
