qtbase/src/gui/painting/qoutlinemapper.cpp: In member function ‘QT_FT_Outline* QOutlineMapper::convertPath(const QVectorPath&)’:
qtbase/src/gui/painting/qoutlinemapper.cpp:182:76: error: ‘void* memcpy(void*, const void*, size_t)’ copying an object of non-trivial type ‘class QPointF’ from an array of ‘const qreal’ {aka ‘const double’} [-Werror=class-memaccess]
memcpy(m_elements.data(), path.points(), count* sizeof(QPointF));
Change-Id: Ieca99f0262c57e58adbcf48ac923ae11bd428b00
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
qtbase/src/corelib/tools/qvector.h:782:16: error: ‘void* memmove(void*, const void*, size_t)’ writing to an object of type ‘class QRingChunk’ with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Werror=class-memaccess]
memmove(b + 1, b, (d->size - offset) * sizeof(T));
~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../../../include/QtCore/5.11.0/QtCore/private/qringbuffer_p.h:1,
Change-Id: I6583241223fe3fc76c0b792779993a34aa9485fe
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Alex Trotsenko <alex1973tr@gmail.com>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Has been flaky in CI.
Task-number: QTBUG-66708
Task-number: QTBUG-66216
Change-Id: I69878574a98139681100c1424d5bbf46cc4a87b8
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
The test's client processes are prepared for the server not being ready when
they try to connect and handle QLocalSocket::ServerNotFoundError by waiting and
trying again.
However, on Ubuntu 16.04 and 17.10 and possibly other systems, sometimes the
error returned by qt_safe_connect inside QLocalSocket is ECONNREFUSED instead of
ENOENT. This has caused flaky failures in CI, so wait and try again in the case
of QLocalSocket::ConnectionRefusedError also.
Task-number: QTBUG-66679
Task-number: QTBUG-66216
Change-Id: I61e3d5b052d84c5ba9d1746f2c71db37cedbf925
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
Has been failing a lot lately
Task-number: QTBUG-66247
Change-Id: Id940a573eb299379cacceb836890cbe0b3c896b7
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Based on the information we got from Unity developers, we need
to check for window's frame geometry to be set, not just window's
position to be set. On various window managers, a window is
'ready' once the frame geometry is set. This fixes autotest
flakiness of tests that use qWaitForWindowActive.
Task-number: QTBUG-66216
Change-Id: Icb664e7b802b474919f3b058c00681574522ccbe
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Windows does not send a mouse release by itself, which can
leave Quick controls believing the mouse is still pressed.
Synthesize an event.
Task-number: QTBUG-66447
Change-Id: Ia865edddc0c77a1b42b9ad2c38323379e74b6704
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
On Debian 9, the sanitize library exports only dlopen symbol, but
it doesn't export the other ones.
We need to check all dl symbols that we use, otherwise "-ldl" will
not be added to the libs list.
Task-number: QTBUG-64864
Change-Id: I3e62b82985348c40b8b61302ba589d5564598e18
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The coordinate conversion was wrong. Use
QCocoaScreen::mapFromNative() instead.
Task-number: QTBUG-53184
Change-Id: I50f18d68ba5d7e1cb5046523a608bfa2e076d7ea
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
We don't need xkb state APIs to check for keys on first level.
Change-Id: I728e6bfe09bce127ad8eae78ecee7cefd620f52e
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
This will allow us to reuse these functions on systems that
do not rely on X11, but use libxkbcommon for handling keyboard
input.
Task-number: QTBUG-65503
Change-Id: I78034238771be96fbb38e8187801fefbee1a5fed
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
This is a more correct fix for QTBUG-48795. The original fix
was unnecessarily using non-XKB code path for updating state
for all incoming key events. This would result in losing some
valuable bits from xkb state.
Task-number: QTBUG-48795
Change-Id: Ic4fb28b2d834272f1db2cbf5888cafb209707847
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
xkbcommon-keysyms.h is generated from X11 header files, so it
contains all the same values.
Removed all of #ifndef XK_* as those keysyms are present in
xkbcommon-keysyms.h (checked the header from 0.4.1, the minimal
required version). The same for XF86XK_* defines.
This will allow to reuse some of this code on platforms that
don't depend on X11, for details see QTBUG-65503.
Task-number: QTBUG-65503
Change-Id: I68083e11cea1f29d775a6ed46503a06b04b9a05c
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
- Use smart pointer for handling xkb state.
- Make it more clear (in the code and the comment) when a latin
keysym is used.
Change-Id: Iee8106c72177c22b1a8fe875027b1dda82196b36
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Now also digits from other alphabets e.g ۲ (arabic two) are mapped
to Qt::Key_* digit keys.
Re-factored logic:
- All known dead keys have direct mappings since
1d86e5f84a. Don't special treat them
in "unicode mapping" code path.
- Removed the ISO8859-1 legacy logic, which is leftover from Qt4
where keysym to Qt decoding was done from raw data. In Qt5 we always
get a utf8 string from xkb_state_key_get_utf8(). Furthermore,
ISO8859-1 and utf8 encode ASCII exactly the same way.
- Set Qt::KeypadModifier from key input handler methods. This logic
does not belong in keysymToQtKey().
Note:
KeyTbl[] and keysymToQtKey() have been duplicated in several places
in Qt. That stuff will be cleaned up as part of QTBUG-65503. This
change will make those cleanups easier.
Task-number: QTBUG-58865
Task-number: QTBUG-65503
Change-Id: Iaf10205a26804f7fc03eb8a16a0879f1bd7bf332
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
3edcd9420e added more robust support
for keyboard input on XKeyboard-less X servers. The various fallbacks
that we had did not work that well in practice. We can remove them now.
The xkb_keymap_new_from_names() function relies on reading XKB config
files from a file system. Since we don't use this function anymore, we
can also simplify xkb context creation (see XKB_CONTEXT_NO_DEFAULT_INCLUDES),
as we don't care about DFLT_XKB_CONFIG_ROOT (which we previously set
via -xkb-config-root for the bundled libxkbcommon).
This patch also changes the code to use smart pointers for managing
the global xkb context, keymap and state.
[ChangeLog][X11] The -xkb-config-root command line switch has been
removed as it it no longer needed when configuring with -qt-xkbcommon-x11.
Change-Id: I80eecf83adae90af5cd20df434c1fba0358a12fd
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Remove the Xlib dependency by extracting XConvertCase
from libxkbcommon sources (xkbcommon/src/keysym.c).
libxkbcommon >= 0.8.0 exposes case conversion APIs, but
we should prefer using the slightly adjusted version (see
the patch for more details).
This change also is necessary for follow-up cleanups.
Change-Id: Icf1716e0ad26f46a7aefb23722cfc57957754d5e
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If _Thread_local is used on a block-scope declaration, it must be
combined with either static or extern to decide linkage.
Change-Id: I228b3520767197c6cdf5134ff5a666ab2aca33ea
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This change amends 305dd1b61f, which lost
1514b4e8 and brought src/corelib/json/qjsonarray.cpp back, which got
removed in c9c9adeef9. In
a6b697ca13, it was moved to
src/corelib/serialization/qjsonarray.cpp in 5.11.
Change-Id: Ic6134a78d75a9c245934cf70a67a54c80a3e7c85
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
This change amends 305dd1b61f, which lost
40334303 and brought src/corelib/xml/qxmlstream_p.h back. In
a6b697ca13, it was moved to
src/corelib/serialization/qxmlstream_p.h in 5.11.
Change-Id: Ia1e9841b866ff49f7274b1b13fd224c0a20a017e
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
... and make use of it.
it's a logical continuation of the 'arch' term, and will be used also in
qt3d's configure.
Started-by: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: I940917d6763842499b18fffd1514c96889a0cc63
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- There is no need to mention qkeymapper, which is an internal
implementation detail.
- Describe the encoding of int.
- Add a note that calling possibleKeys() outside key event
handler context is not valid.
Change-Id: Ife9b7d1496f04b5a433ed2d56f29c4f01f174441
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
... which was trying to fix a rarely occurring situation where system
settings from a desktop environment does not set any latin keymap on
X. This is a DE bug and it has a simple workaround (details in the patch).
Ubuntu has fixed this issue sometime between 12.10 -> 14.04. Gnome 3
always appends 'us' layout, even if you have only e.g. 'gr' listed in
keyboard layouts (can be checked via setxkbmap -query). In KDE, the
global system shorcuts seem to stop working as soon as latin keymap
is not the first in the list, which means that KDE users won't be
affected as they will likely always have a latin keymap present in
the list.
This patch removes parts of 2b666d9576,
the parts that in the commit message I was referring to by this quote:
"lookupLatinKeysym() also handles the cases that did not work in Qt4
with XLookupString".
Since finding a latin key is not working by XLookupString() in this
rare case, then it would not work pretty much across the whole desktop.
And users would be more interested at finding a solution that works
across the desktop. We should not workaround this issue. Desktops that
are doing it wrong should learn about this and not repeat the same mistakes
on Wayland systems, where XKB keymap is assembled by compositor and passed
to clients. Clients should work with the provided keymap as is.
The missing-latin-keymap workaround is considered fragile for several
reasons - it might not work with legacy or enterprise X server key codes
and it relies on global _XKB_RULES_NAMES (there might be several connected
keyboards). And theoretical limitation: client might be running in a
restricted environment where we don't have access to keymaps on the
file system.
Change-Id: Ib445b2ea46174248cfa0e5da0eb642cd2a5cf2f6
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
This is a signal that is not actually supported by the
StatusNotificationIcon standard, but it comes to be important
for the Qt implementation of it, in fact qt apps might
not have a menu, when exporting the Menu path as /NO_DBUSMENU
or they could add this later in the execution.
So, currently there's no way for the StatusNotificationWatcher
to know when a menu has been added (or changed).
Adding a NewMenu signal won't cause any troubles, but will
allow watchers to be notified properly on menu addition.
Change-Id: I9a8b00213f5023950811af1d62cd91bc51744b78
Reviewed-by: Dmitry Shachnev <mitya57@gmail.com>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Commit cf4a611115 refactored out test
identifier buildup into a standalone function, but it returned the
QTestCharBuffer as a value type, which ultimately caused it to crash:
Unfortunately QTestCharBuffer is not copied correctly: Since it uses the
default copy ctor it will copy the buf pointer and create a deep copy of
the staticBuf pointer. When the dtor was later called it would then end up
calling free(buf) (where buf pointed to the staticBuf of the original
QTestCharBuffer).
Task-number: QTBUG-66607
Change-Id: Ifa290658be6f077a0d6613451c26aeeffc8df41c
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit 6ffb358822)
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
GTK's scale factor, which can differ from Qt's scale factor, must
be taken into account in the native GTK menu positioning function
qt_gtk_menu_position_func().
Task-number: QTBUG-55251
Change-Id: I4ad460baab54facd25564ad85ded383c9321d597
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Dmitry Shachnev <mitya57@gmail.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
When the table for a selected column can't be determined (e.g. because
there is no table for it), PQftable returns InvalidOid. This was not
covered and a query to determine the table name was executed every
time which slowed down calls to QSqlQuery::value(QString).
Task-number: QTBUG-65226
Change-Id: Idd8fbaaef7b01ca4151439f46cad2cce6f1c93e9
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
with 40e87491 merged, 'QMAKE_CXXFLAGS' variable in
'win32-g++' toolchain became defined via 'QMAKE_CFLAGS'.
the similar can be found in 'win32-clang-msvc' and
'win32-icc' toolchains too.
this works for now, because such definitions just duplicates code
from includes, like 'gcc-base.conf', 'msvc-desktop.conf', etc.
but it would became broken, if changes would be applied to
'QMAKE_CXXFLAGS' definitions in that includes, prior
to the redefinitions in 'win32-*/qmake.conf' toolchains.
thus 'QMAKE_CXXFLAGS' definitions in 'win32-*/qmake.conf' toolchains
should not depend on 'QMAKE_CFLAGS' and be done explicitly.
in order to apply this change correctly to 'win32-icc' toolchain,
its 'QMAKE_CFLAGS' variable should become dependent on definitions
in the includes, similar to 'win32-clang-msvc' and
'win32-msvc' toolchains.
Change-Id: I5e820e44a769a590ba63f70dcb3a115311093311
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
CGDisplayCreateImageForRect seems to have a weird behavior when mixing
highDPI and non-highDPI screens since it may take part of the
non-highDPI screen when the highDPI display is at the left or at the
top of the main monitor.
To workaround this issue, we capture the whole screen and then crop the
image to the desired size.
Task-number: QTBUG-47643
Change-Id: Ib2a3850a0a549964c7fe272abb563bd23518c234
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Without any content it was hard to see the window. Put some lipstick on it.
Change-Id: I0fefffb0a4deba7ac91e67a6153a9a27308fe493
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The latter would allow one final resize that would immediately
jump to 300x300.
Change-Id: I566e5e9dc1fb07f748f528f002166a8438344173
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
While both GCC and the GCC compatible clang support this attribute in
general, GCC doesn't support it when targeting macOS, ending up with
errors like these:
error: 'init_priority' attribute is not supported on this platform
This error isn't a property of the platform itself though, since
clang supports the attribute just fine on macOS.
The attribute is only used to work around an issue with dllimport
on windows, so limit its use to that platform, to avoid issues
with it potentially being unsupported on platforms other than
macOS as well.
This fixes compiling with GCC for macOS.
Change-Id: I0235e6365635d73233951566c10ad869b26a0fc6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Configuring Qt with -no-feature-ftp cause build to fail.
Change-Id: I47f1cdc400702d0211a9f620c8606983f08fa70c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This reverts commit 71090f0950. Changing
the link was wrong because we do not actually comply with the new RFC.
Task-number: QTBUG-66470
Change-Id: I940917d6763842499b18fffd15147cb93c27b7f4
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
They can be, if compiled with -Wl,-pie. Example:
$ file /usr/bin/ping
/usr/bin/ping: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0
And you can't detect via the interpreter, since libraries can have
them too:
$ file /lib64/libc-2.26.so libQt5Core.so.5.11.0
/lib64/libc-2.26.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2
libQt5Core.so.5.11.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.17.0
Change-Id: I940917d6763842499b18fffd15143bb80ce0e531
Reviewed-by: David Faure <david.faure@kdab.com>
QOpenGLProgramBinaryCache::setProgramBinary() should check
GL_LINK_STATUS after glProgramBinary(), but doesn't.
In practice, this means that SDDM is a white screen, and KDE is just
a gray task bar.
So far, Qt tries to check this using its internal ::link() function.
But in case the cached binary fails to load, Qt currently attempts to
link the inexistent program, resulting in a zero-length, fixed
pipeline shader.
Checking this already in ::setProgramBinary() makes the call to
::link() superfluous, so we remove that as well.
Done-with: Max Staudt <mstaudt@suse.com>
Done-with: Michal Srb <msrb@suse.com>
Done-with: Fabian Vogt <fvogt@suse.de>
Task-number: QTBUG-66420
Change-Id: Iabb51d0eb2c0c16bde696efff623e57d15f28d82
Reviewed-by: Jesus Fernandez <Jesus.Fernandez@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
contains() interprets the regexp as being implicitly
anchored, so the leading part of the path needs to be
explicitly matched.
Change-Id: I1efa07dc99bb2db1717d2a66621899e23c144164
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
