Generate a pri file for public and private interfaces, but map CONFIG +=
internal_module to a cmake option and skip the former if set.
Task-number: QTBUG-75666
Change-Id: I3f4baf1277094f4c22149a9e8769734baf9a235f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Qt on macOS has traditionally not included a BOM in the UTF-16 data,
but due to iOS requiring it it was changed in 4e196159. This had the
unfortunate side effect of breaking macOS applications that were not
prepared for the BOM, even if the public.utf16-plain-text UTI can have
an optional BOM, most notably Microsoft Excel. It also resulted in the
public.utf8-plain-text having a BOM, as that's automatically generated
by macOS based on the UTF-16 content we give it. Having a BOM in UTF-8
is technically fine, but not required, and recommended against.
The fact that iOS requires a BOM is a bit dubious, and most likely a
result of applications or system frameworks decoding the data using
NSUTF16StringEncoding, which assumes big-ending byte ordering if there
is no BOM, as opposed to public.utf16-plain-text which assumes native
byte ordering. Since we can't fix iOS our best bet is to include a BOM.
For macOS though, we revert back to the old behavior of not including
a BOM, since that seems to surprise macOS frameworks and applications
the least, even if having a BOM in public.utf16-plain-text should be
fully supported.
Longer term we should look at what kind of UTIs we generate. Most apps
on macOS do not generate public.utf16-plain-text, but instead generate
public.utf16-external-plain-text, which differs from the former in that
it assumes big-endian byte-ordering when there's no BOM. On iOS apps
seem to generate public.utf8-plain-text, and do not generate any UTF-16
UTIs. Moving Qt over to these UTIs would fix the problem as well, but
is a larger change that needs more research.
Change-Id: I4769c8b7d09daef7e3012e99cacc3237f7b0fc1a
Fixes: QTBUG-61562
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Also clean up QTextCodec usage in qmake build and some includes
of qtextcodec.h.
Change-Id: I0475b82690024054add4e85a8724c8ea3adcf62a
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
- Move ivars into @implementation
- Use instancetype where applicable
- Use dot notation for property access
- Use subscript operator for dictionaries and arrays
- Format selectors consistently
- Use proper style for init methods
- Use generics instead of void pointers where possible
- Use "range for" loops instead of indexing
- Replace or replace IBAction/IBOutlet with void
Change-Id: I1667812a51d4dfe44ae80fe337cb1f4bc9699d92
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Creating a precompiled header exclusively for a one- or two-file module
is wasteful. The time that it takes to build the precompiled source is
on the same order as a regular compilation, so enabling precompiled
headers for those modules just makes the build slower.
Also make it possible to override the precompiled header by just setting
PRECOMPILED_HEADER to empty.
Change-Id: I0e1a09998253489388abfffd14b5f221288c4826
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Since QMacPasteboardMimeTiff was moved out of the cocoa
plugin and into platformsupport, we take the opportunity to
give the code some overhaul as well.
Change-Id: I7d5425d336ba41474698915008b2086e98ea49dc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This will add copy/paste/dnd support for QPixmap and QImage
to all darwin platforms (and not just macOS, as it is today).
Task-number: QTBUG-57428
Change-Id: Iefc876c0a347077322f195b55c49f2c1c4b4a34b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The current implementation of QMacPasteboardMimeUnicodeText
didn't contain any logic to handle unicode text with a byte
order mark (BOM). According to the
docs (*), 'public.utf16-plain-text' can have an optional BOM.
Because of that, Qt would fail encoding UTF-16 text from the
pasteboard if it had a BOM.
Additionally, perhaps because of a bug in iOS 10, UTF-16 text
placed on the pasteboard by Qt ends up being encoded wrong by
native apps, unless the text has a BOM.
Rather than hard-coding UTF-16 encoding/decoding in qmacmime, we
now leave it to QTextCodec. QTextCodec will add a BOM by
default, and can handle decoding of UTF-16 both with, and
without, a BOM.
*: https://developer.apple.com/library/content/documentation/Miscellaneous/Reference/UTIRef/Articles/System-DeclaredUniformTypeIdentifiers.html
Task-number: QTBUG-56229
Change-Id: I3a08deb0262350c67e5622cf23eb3c3a4907ec39
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
lumping together all kinds of unrelated stuff has caused problems with
spurious dependencies from the beginning. as the modularization infra is
now in a state which supports many small private libraries just fine,
take advantage of it.
Change-Id: Ic40f47ce76a308bbfd32deae281f6f064fe1ef4c
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Conflicts:
qmake/library/qmakebuiltins.cpp
qmake/library/qmakeevaluator.cpp
qmake/library/qmakeevaluator.h
qmake/project.h
QMakeEvaluator:
* evaluateConditional(): one side changed return type, the other
changed a parameter type.
* split_value_list(): one side changed a parameter adjacent to where ...
* expandVariableReferences(): ... the other killed one overload and
changed the survivor
src/corelib/io/qlockfile_unix.cpp
One side changed a #if condition, the other moved NETBSD's part of
what it controlled.
src/corelib/tools/qdatetime.cpp
One side fixed a reachable Q_UNREACHABLE in toMSecsSinceEpoch(), the
other moved it from the private class to the public one, in the midst
of the "short date-time" optimization, which confused diff entirely.
One side changed a QStringLiteral to QLatin1String, the other rewrote
adjoining code.
src/network/kernel/qauthenticator.cpp
Both rewrote a line, equivalently; kept the dev version.
src/platformsupport/fontdatabases/mac/qfontengine_coretext.mm
src/platformsupport/fontdatabases/mac/qfontengine_coretext_p.h
One side changed #if-ery that the other removed.
tools/configure/configureapp.cpp
One side added a check to -target parsing; the other killed -target.
tests/auto/testlib/selftests/expected_cmptest.lightxml
tests/auto/testlib/selftests/expected_cmptest.teamcity
tests/auto/testlib/selftests/expected_cmptest.txt
tests/auto/testlib/selftests/expected_cmptest.xml
tests/auto/testlib/selftests/expected_cmptest.xunitxml
Regenerated using generate_expected_output.py
I note that quite a few other expected_* come out changed, now.
There was no git-conflict in
src/widgets/kernel/qformlayout.cpp
but it didn't compile; one side removed some unused methods; the other
found uses for one of them. Put FixedColumnMatrix<>::removeRow(int)
back for its new user.
Change-Id: I8cc2a71add48c0a848e13cfc47b5a7754e8ca584
Conflicts:
qmake/library/qmakeevaluator.cpp
One side changed the iterator to use ranged-for, the other changed its
body; they only conflicted because the latter had to add braces around
the body, intruding on the for-line. Trivial resolution.
Change-Id: Ib487bc3bd6e3c5225db15f94b9a8f6caaa33456b
Now that the minimum deployment target (and thus SDK) is 10.9 for OS X
and 7.0 for iOS, all code paths affecting platform versions lower than
the aforementioned are removed.
Change-Id: Id985c7259c4ac069319d88f2c29c9559ae9e8641
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Apple Mail will pick up and attempt to use the vCard
flavor, which then fails since the data Qt placed
on the clipboard is not actually a valid vCard.
Place data in the vCard format on the clipboard
only if the mime type is “text/vcard”.
[ChangeLog][OS X] Pasting text from Qt applications
to Apple Mail now works.
[ChangeLog][OS X] “text/vcard” is now required as
the mime type when placing vCards on the clipboard.
Task-number: QTBUG-48953
Change-Id: Id029b20317f2c5ad8ae225912484de3c97498d29
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
Pass -xplatform macx-tvos-clang to configure to build.
Builds device and simulator by default.
Added ‘uikit’ platform with the common setup.
Also added QT_PLATFORM_UIKIT define (undocumented).
qmake config defines tvos (but not ios).
tvOS is 64bits only (QT_ARCH is arm64) and requires bitcode to be
embedded in the binary. A new ‘bitcode’ configuration was added.
For ReleaseDevice builds (which get archived and push to the store),
bitcode is actually embedded (-fembed-bitcode passed to clang). For all
other configurations, only using bitcode markers to keep file size
down (-fembed-bitcode-marker).
Build disables Widgets in qtbase, and qtscript (unsupported,
would require fixes to JavaScriptCore source code).
Qpa same as on iOS but disables device orientation, status bar, clipboard,
menus, dialogs which are not supported on tvOS.
Change-Id: I645804fd933be0befddeeb43095a74d2c178b2ba
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
QUrl::setScheme() parses and canonicalises the scheme, so that
scheme() always returns a lower-case string anyway; no need to
.toLower() it.
Change-Id: Ied00814b63f159386a42552dcf06346ee56f9f97
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new LGPL header instead of LGPL21 one
(in those files which will be under LGPL v3)
Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Cocoa is basically just AppKit + CoreData. Since we do not use CoreData
in Qt, there is no reason to link to it or (transitively) import its
headers.
This is just a mechanical replacement of -framework Cocoa with
-framework AppKit and <Cocoa/Cocoa.h> with <AppKit/AppKit.h>
Change-Id: Ibcfc8a03c0ddff27a67fbc87dd7bd58a4b648956
Reviewed-by: Mika Lindqvist <postmaster@raasu.org>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
Some CFStringRefs created with CFStringCreate* methods were not being
released. Using the QCFString helper class to perform auto release.
Change-Id: I36d15c0d35118524089e99ea3cd53c41342d6308
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
com.apple.traditional-mac-plain-text is not in use on iOS
according to Apples UTType reference. So we enable it only
for OS X by moving it into the cocoa port.
The order in which we instanciate convertors matters when
the application is reading data from the pasteboard.
But since QMacPasteboardMimePlainText should come before the
other "text/plain" convertors on OS X, moving it to the cocoa
port is safe as those convertors are instanciated after
those in qmacmime.
Change-Id: I76b9b14e5ce78f34e0f1ecbfee71e48a27a4687b
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Application like Safari on iOS posts rtf to the
pasteboard when copying html. With this converter added, you
can then paste rtf as html into Qt
Change-Id: I6b62bcc9cfc0b16a47d44bd8d74062226522526d
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Copying a URL from Safari to Qt app does not work. The reason
is that it lies on the pasteboard as public.text, which we
don't support.
This patch will implement support for public.text.
The UTI public.text is documented as text with an unspecified
encoding. On iOS, this turns out to be UTF8 (which also matches
[UIPasteboard generalPasteboard].string).
Task-number: QTBUG-38551
Change-Id: I216dab206d3bff2dde99927ed7e5a3d85309f2a2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
The UnicodeText converter is a bit special since it can convert
to both utf8 and utf16 for text/plain. But since flavorFor("text/plain")
can only return one UTI, it returns utf16. And this means that
canConvert will return false if given utf8 as argument.
On iOS this is often the only format available on the pasteboard, which
means that pasting text from another app app will fail.
This patch will ensure that it returns true for both utf8 and
utf16.
Change-Id: I31697f1815c19113393a8ef48f2ead4d7f1078ec
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Simon Hausmann
Alexandru Croitor
Tor Arne Vestbø
Tobias Hunger
Liang Qi
Jake Petroules
Thiago Macieira
Richard Moe Gustavsen
Oswald Buddenhagen
Edward Welbourne
Andy Shaw
Morten Johan Sørvig
Mike Krus
Liang Qi
Edward Welbourne
Jani Heikkinen
Simon Hausmann
Jake Petroules
Gabriel de Dietrich
Dyami Caliri
Matti Paaso
Samuel Gaist
Richard Moe Gustavsen