| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
Move away from using 0 as pointer literal.
Done using clang-tidy. This is not complete as
run-clang-tidy can't handle all of qtbase in one go.
Change-Id: I1076a21f32aac0dab078af6f175f7508145eece0
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
| |
Change-Id: I254d37d37f5583e0f7a76fb42b83d234afa29b77
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
|
|
|
|
|
|
|
|
| |
This was used to support QFlags f = 0 initialization, but with 0 used
as a pointer literal now considered bad form, it had been changed many
places to QFlags f = nullptr, which is meaningless and confusing.
Change-Id: I4bc592151c255dc5cab1a232615caecc520f02e8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also sanitize the initial WebAssembly hack. Both eglfs and wasm lack the concept
of true raster windows. A QWindow with RasterSurface is rendered with OpenGL
no matter what. The two platforms took two different approaches to work around
the rest of the machinery:
- wasm disabled the QOpenGLContext warning for non-OpenGL QWindows,
- eglfs forced the QWindow surfaceType to OpenGLSurface whenever it was
originally set to RasterSurface.
Now, the latter breaks since c4e9eabc309a275efc222f4127f31ba4677259b7, leaving
all raster window applications failing on eglfs, because flush in the backingstore
is now checking the surface type and disallows OpenGLSurface windows. (just like
how QOpenGLContext disallows RasterSurface windows)
To solve all this correctly, introduce a new platform capability,
OpenGLOnRasterSurface, and remove the special handling in the platform plugins.
Change-Id: I7785dfb1c955577bbdccdc14ebaaac5babdec57c
Fixes: QTBUG-77100
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Calling destroy from the QEglFSWindow dtor() triggers the virtual
invalidateSurface() to be called on a partly destroyed object. As the
child windows deregister themselves from their screens on
invalidateSurface() this is dangerous: It leaves a dangling pointer in
the screen.
Fixes: QTBUG-75075
Change-Id: Idd3fea18562d41973f364340df875a50dbd5691e
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you run an application under eglfs, it falls with segfault on the
exit. For example, examples/gui/analogclock,
examples/widgets/widgets/analogclock, examples/opengl/cube,
examples/opengl/qopenglwidget, etc. (I have added the function
keyPressEvent to exit by qApp->quit(), if needed).
It isn't appear in applications using QQuickView or QGLWindow.
This is because QCoreApplication destructor, where the variable self = 0
(therefore, qGuiApp = 0), is called before than
QOpenGLVertexArrayObject::destroy(), where qGuiApp is accessed
(qGuiApp->thread()).
Task-number: QTBUG-73824
Change-Id: I1dc55d5e811bfe8a8ea2178752e8771f8644d356
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
.qmake.conf
src/corelib/animation/qvariantanimation.cpp
src/corelib/global/qglobal.cpp
src/corelib/global/qlogging.cpp
src/corelib/io/qprocess_win.cpp
src/corelib/json/qjsonarray.cpp
src/corelib/tools/qsimd_p.h
src/corelib/tools/qtimezoneprivate_p.h
src/corelib/xml/qxmlstream_p.h
src/gui/kernel/qsimpledrag.cpp
src/gui/kernel/qsimpledrag_p.h
src/plugins/generic/generic.pro
src/plugins/platforms/cocoa/qcocoamenu.mm
src/widgets/styles/qmacstyle_mac.mm
tests/auto/concurrent/qtconcurrentmap/BLACKLIST
tests/auto/corelib/io/qfileinfo/tst_qfileinfo.cpp
tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp
tests/auto/gui/kernel/qwindow/BLACKLIST
tests/auto/widgets/dialogs/qmessagebox/BLACKLIST
Change-Id: I508d686cf20f7f8cc6a7119b9bc7c3bbb505c58e
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The Embedded Android build (Boot to Qt Android injection) is defined by
having both Q_OS_ANDROID and Q_OS_ANDROID_EMBEDDED flags defined,
as well as having Qt config android-embedded.
This commit enables the possibility to build embedded Android builds.
(i.e. Qt build for Android baselayer only, without JNI)
Change-Id: I8406e959fdf1c8d9efebbbe53f1a391fa25f336a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The call to QPlatformWindow::setRect (for storing into d->rect) was
in the wrong place. It has to be the potentially-overridden value.
Amends 3a31c708790ba2bb3cf3dab32a17a83659a1acde
Task-number: QTBUG-57608
Change-Id: Id3c35e2dc178f7bd2f9643e8ae4754c8f2f39240
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The logic of deciding whether or not to send resize and move events
has been centralized in QGuiApplication. This ensures that if a
window with geometry 100,100+200x200 is moved and resized to e.g.
0,0+100x100, but the window manager denies the request (because the
window would e.g. overlap with system UI), and issues a geometry
update with the original geometry, 100,100+200x200, we will still
treat that as warrant of a move/resize event to the application,
so the application knows that its position and size is as before.
[ChangeLog][Qt Gui][QPA] QWindowSystemInterfacePrivate::handleGeometryChange
no longer takes the old geometry as an argument.
Task-number: QTBUG-57608
Change-Id: I1d471cc7a257fef958bdb1e56184fa95489403a3
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|/
|
|
|
|
|
|
|
| |
We can offload this to QGuiApplication, just like the geometry of the
QWindow is set. This ensures that all platforms behave the same, and
that the documentation of QPlatformWindow::setGeometry is adhered.
Change-Id: I19dbc32cb4fb146d716ec289c28030a547d3afaa
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
| |
Relevant for QWidget apps with multiple top-level widgets. With real
windowing systems a resize will result in an expose. Follow suit.
Task-number: QTBUG-57747
Change-Id: I9c6e9fa5e073f85a695df07d63176b1d2d657f25
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
configure
qmake/Makefile.unix.macos
qmake/Makefile.unix.win32
qmake/generators/win32/msvc_vcproj.cpp
src/3rdparty/pcre/qt_attribution.json
src/corelib/io/qsettings.cpp
src/corelib/kernel/qdeadlinetimer.cpp
src/platformsupport/kmsconvenience/qkmsdevice.cpp
src/platformsupport/kmsconvenience/qkmsdevice_p.h
src/plugins/platforms/eglfs/deviceintegration/eglfs_kms/qeglfskmsgbmscreen.cpp
src/plugins/platforms/eglfs/deviceintegration/eglfs_kms_egldevice/qeglfskmsegldeviceintegration.cpp
src/plugins/platforms/eglfs/deviceintegration/eglfs_kms_egldevice/qeglfskmsegldevicescreen.cpp
src/plugins/platforms/eglfs/deviceintegration/eglfs_kms_support/qeglfskmsdevice.cpp
src/plugins/platforms/eglfs/deviceintegration/eglfs_kms_support/qeglfskmsscreen.h
tests/manual/qstorageinfo/printvolumes.cpp
tools/configure/configureapp.cpp
Change-Id: Ibaabcc8e965c44926f9fb018466e8b132b8df49e
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/network/socket/qnativesocketengine_winrt.cpp
tools/configure/configureapp.cpp
tools/configure/environment.cpp
Change-Id: Ieae6f2ee004a87f041751852b687484f91ee4480
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
It is possible to have support for EGL without having support for OpenGL
for example with OpenVG. Unfortanately many features of EGLFS require
OpenGL (Cursor, MultiWindow, QEGLPlatformContext, QBackingStore), so the
plugins become pretty useless on their own. This is necessary if you
still want to use Qt as a method to provide an EGL surface to render to
via QWindow. This is the method by which Qt Quick uses OpenVG to render
its content when available.
Change-Id: I34973b21bf1932865950ce6a78b71b3a29360d65
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
| |
Change-Id: I20eb0e33abfd70b6a5240e7b6b0aa0425f2d2ee7
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
|
|
|
|
|
|
|
|
| |
The change in QEglFSScreen::geometry() was not reflected in the
advanced backends that subclass it.
Change-Id: I6494a96f0b9afaea3722c61035d4b46bf2473897
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Running QWidget or other raster window-based apps with
QT_QPA_EGLFS_ROTATION=180 will now flip the screen as expected.
In addition, 90 and -90 are supported too. These will affect the
reported screen geometry as well.
The OpenGL mouse cursor is repositioned and rotated accordingly. For
true OpenGL content the rotation is ignored. Hardware mouse cursors
(DRM) ignore it as well for the time being.
[ChangeLog][Platform Specific Changes] QWidget-based applications
running on the eglfs platform plugin can now request 180 or 90 degrees
rotated output by setting the QT_QPA_EGLFS_ROTATION environment
variable.
Task-number: QTBUG-39959
Change-Id: I3570b515d0233c6c6a0e813899b935ee222eab62
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
This allows external integrations to be developed against it.
Also uniforms all class names as QEglFSFoo.
Change-Id: I72ff37c0fcdf1ccd37110b4c36874d6c99b2e743
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
|