[Development] Cross-platform high-DPI Qt tech preview
We are happy to share the results of our work on cross-platform high-DPI scaling in Qt, which is planned for Qt 5.6. It is now at a stage where it can be tested by others. You can get the code from our branch in qtbase: wip/highdpi. The branch is open for business, and contributions are welcome. We also have a IRC channel: #qt-highdpi on Freenode. There will also be a session in the Qt Contributors’ Summit this weekend. :) Quick Getting Started There are three ways to test the high-DPI scaling: 1) Set QT_SCALE_FACTOR (to a number != 1) and run your favorite Qt app. 2) Try the DPI scale slider in tests/manual/highdpi . 3) Set QT_AUTO_SCREEN_SCALE_FACTOR=1 on Windows or X11 multi-screen setups. The rest of this mail will describe the changes in detail. This project is a part of a larger effort of making Qt more resolution independent. There are two approaches in development: 1) Adding resolution independent units to QML / Qt Quick. 2) Scaling with devicePixelRatio. This project is part of “Scaling with devicePixelRatio”: implementing devicePixelRatio scaling in cross-platform Qt code. We have had unofficial scaling support for X11 and Windows in Qt 5.4 and 5.5. That was implemented completely in the platform plugins. The main benefits of now moving the scaling logic to QtGui are: 1) Support for devicePixelRatio scaling on platforms that have limited or no native support. (X11, Windows, Android, Embedded linux) 2) Improving the developer experience: any devicePixelRatio can be simulated on any hardware. 3) Support for “de-scaling” on platforms that natively scales: Qt application can operate entierly in device pixels. Sidebar: How does devicePixelRatio scaling work again? devicePixelRatio scaling works by virtualizing the main coordinate system seen by applications. The “pixel” coordinate system is split into two: device independent pixels and device pixels. Window and event geometry is specified in device independent pixels which are closely related to visual size. Backing stores and graphics output in general are in device pixels which are closely related to the display resolution. Project Scope devicePixelRatio scaling is best implemented as a part of the Windowing system, at least for production use. Depending in the level of operating system support the Qt scaling Depending in the level of operating system support the Qt scaling will have known edge case bugs. This also varies with the use case: A single screen with a fullscreen window is relatively simple, multi-screen desktop environments are more complex. Officially, we aim to support only integer scale factors. However, fractional scale factors do work, since we use qreal everywhere. This means that developers can test and evaluate the effects of fractional scale factors, and it also gives the end user the option to decide whether the results are acceptable or not. Implementation Overview The high-DPI patches inserts a coordinate scaling layer in the lower parts of QtGui and introduces a new coordinate system: native pixels. The platform plugins now operate in native pixels and are mostly unaware of the scaling layer added to QtGui. Native pixels are internal to Qt and are not exposed to applications. Proper layering now becomes more important, effectively restricting where certain API can be called from. * In the platform plugins: Don’t use QWindow. QPlatformWindow now has geometry accessor convenience functions. * In the platform plugins: Don’t call QGuiApplication, go through QWindowSystemInterface. * In QtGui: Don’t use QPlatformFoo classes outside of the corresponding QFoo class (QPlatformWindow, QPlatformScreen) * In auto tests: Don’t call QWindowSystemInterface, use the QTest event synth. functions. These are not set-in-stone rules. If you find you need to break one of them, add QHighDpi scaling calls. API For Setting Scale Factors (note that since this mail goes to development@ we’re also discussing private API here, which may change or be removed.) Environment variables: * QT_DEVICE_PIXEL_RATIO: Now deprecated (but still supported in 5.6). * QT_SCALE_FACTOR: Sets a global scale factor for the process. * QT_AUTO_SCREEN_SCALE_FACTOR: Enables a per-screen scale factor defined by the platform plugin based on the physical DPI of each screen. Currently implemented on Xcb and Windows. Private API: QPlatformScreen:pixelDensity() : Tells Qt to apply the given scale factor to all windows on a screen. QHighDpiScaling::setScreenFactor(QScreen *, factor): set a screen scaling factor at run-time. Currently used by the tests/manual/highdpi manual test. API For Accessing devicePIxelRatio The devicePixelRatio is the product of the OS and Qt scale factors. The preferred accessor functions are: QWindow::devicePixelRatio() QPaintDevice::devicePixelRatioF() For QtGui implementation work the principal functions for converting between native and device indepe
Re: [Development] Q_OBJECT and "override"
On 06/04/2015 04:52 PM, Konstantin Ritt wrote: > #define Q_OBJECT \ > > public: \ > > Q_OBJECT_CHECK \ > > QT_WARNING_PUSH \ > > Q_OBJECT_NO_OVERRIDE_WARNING \ > > static const QMetaObject staticMetaObject; \ > > virtual const QMetaObject *metaObject() const; \ > > virtual void *qt_metacast(const char *); \ > > virtual int qt_metacall(QMetaObject::Call, int, void **); \ > > QT_WARNING_POP \ Oh, this is already in 5.5... I overlooked it somehow. Well, that makes this thread kinda pointless. Sorry about the noise (if the construct above indeed works). Christian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Q_OBJECT and "override"
On Thu, Jun 04, 2015 at 12:41:23PM +, Bornemann Joerg wrote: > > 1) Add "override" (or rather Q_DECL_OVERRIDE) to the definition of > > Q_OBJECT *and* all QObject-derived classes in Qt. > [...] > > 2) Remove "override" from all QObject-derived classes in Qt. > [...] > > 3) Explicitly disable the warning in the clang mkspecs. > [...] > > 4) Let users deal with the problem by making them turn the warning off. > [...] > > 1) is the thing to do, but OTOH it's a lot of work with questionable gain. > 1b) would be making the addition conditional on an external define. this way each (sub-)project (including qt modules) can decide if/when it adjusts. fwiw, i don't think the gain would be questionable at all. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Q_OBJECT and "override"
#define Q_OBJECT \
public: \
Q_OBJECT_CHECK \
QT_WARNING_PUSH \
Q_OBJECT_NO_OVERRIDE_WARNING \
static const QMetaObject staticMetaObject; \
virtual const QMetaObject *metaObject() const; \
virtual void *qt_metacast(const char *); \
virtual int qt_metacall(QMetaObject::Call, int, void **); \
QT_WARNING_POP \
QT_TR_FUNCTIONS \
private: \
Q_DECL_HIDDEN_STATIC_METACALL static void
qt_static_metacall(QObject *, QMetaObject::Call, int, void **); \
struct QPrivateSignal {};
Regards,
Konstantin
2015-06-04 17:27 GMT+03:00 Matthew Woehlke :
> On 2015-06-04 08:12, Christian Kandeler wrote:
> > as anyone who uses clang has probably already noticed, this compiler has
> > recently added "-Winconsistent-missing-override" to the collection of
> > flags enabled via "-Wall".
>
> What happens if you (push state and) disable the warning at the start of
> the Q_OBJECT expansion, and pop state after?
>
> Ideally this would tell clang to not consider those functions for the
> purpose of the warning. (And maybe the clang developers would be
> amenable to making it work that way if it doesn't currently.)
>
> p.s. I don't use clang, but if I did I would probably have this switched
> on as an *error*. Thus, I at least would like to see a solution that
> doesn't involve turning it off globally.
>
> --
> Matthew
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Q_OBJECT and "override"
On 2015-06-04 08:12, Christian Kandeler wrote: > as anyone who uses clang has probably already noticed, this compiler has > recently added "-Winconsistent-missing-override" to the collection of > flags enabled via "-Wall". What happens if you (push state and) disable the warning at the start of the Q_OBJECT expansion, and pop state after? Ideally this would tell clang to not consider those functions for the purpose of the warning. (And maybe the clang developers would be amenable to making it work that way if it doesn't currently.) p.s. I don't use clang, but if I did I would probably have this switched on as an *error*. Thus, I at least would like to see a solution that doesn't involve turning it off globally. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Q_OBJECT and "override"
On Thu, Jun 4, 2015 at 2:41 PM, Bornemann Joerg
wrote:
>
>> 1) Add "override" (or rather Q_DECL_OVERRIDE) to the definition of
>> Q_OBJECT *and* all QObject-derived classes in Qt.
> [...]
>> 2) Remove "override" from all QObject-derived classes in Qt.
> [...]
>> 3) Explicitly disable the warning in the clang mkspecs.
> [...]
>> 4) Let users deal with the problem by making them turn the warning off.
> [...]
>
> 1) is the thing to do, but OTOH it's a lot of work with questionable gain.
* snip *
> 2) and 4) are very wrong. IMO, we shouldn't do this.
> 3) could be a good compromise. There's a variant of this solution by turning
> the warning off
> at the beginning of every header and turning it on again at the end.
> We once had the QT_{BEGIN|END}_HEADER macros which could expand to
>
> #pragma clang diagnostic push
> #pragma clang diagnostic ignored "-Wannoyingwarning"
>
> and repectively
>
> #pragma clang diagnostic pop
>
> This way the warning can be turned on for user code.
>
>
> BR,
>
> Joerg
Is it really that much work? I hear there's tools to do so [1] and
it's the compiler telling whether it's correct or not.
Aleix
[1] http://clang.llvm.org/extra/ModernizerUsage.html
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 5.5.0 header diff
It's time for the header diffs, please help review the changes (Qt 5.4.2 to 5.5.0) to make sure nothing that was added to the public headers slipped through when it shouldn't be there. I'll send mails in reply to this one with the diffs attached (that will take a while). Cheers, Frederik Output of header-diff.pl origin/5.4.2..origin/5.5.0: Found module Qt3DCore in /home/frederik/dev/qt/qt-src- dev//qt3d/src/core/core.pro - Module has 41 public headers now fatal: bad revision 'origin/5.4.2..origin/5.5.0' - Git failed, skipping Found module Qt3DInput in /home/frederik/dev/qt/qt-src- dev//qt3d/src/input/input.pro - Module has 5 public headers now fatal: bad revision 'origin/5.4.2..origin/5.5.0' - Git failed, skipping Found module Qt3DRenderer in /home/frederik/dev/qt/qt-src- dev//qt3d/src/render/render.pro - Module has 74 public headers now fatal: bad revision 'origin/5.4.2..origin/5.5.0' - Git failed, skipping Found module QtAndroidExtras in /home/frederik/dev/qt/qt-src- dev//qtandroidextras/src/androidextras/androidextras.pro - No public headers for module QtAndroidExtras Found module QtConcurrent in /home/frederik/dev/qt/qt-src- dev//qtbase/src/concurrent/concurrent.pro - Module has 15 public headers now - QtConcurrent.diff created Found module QtCore in /home/frederik/dev/qt/qt-src- dev//qtbase/src/corelib/corelib.pro - Module has 191 public headers now - QtCore.diff created Found module QtDBus in /home/frederik/dev/qt/qt-src- dev//qtbase/src/dbus/dbus.pro - Module has 19 public headers now - QtDBus.diff created Found module QtGui in /home/frederik/dev/qt/qt-src-dev//qtbase/src/gui/gui.pro - Module has 128 public headers now - QtGui.diff created Found module QtNetwork in /home/frederik/dev/qt/qt-src- dev//qtbase/src/network/network.pro - Module has 34 public headers now - QtNetwork.diff created Found module QtOpenGL in /home/frederik/dev/qt/qt-src- dev//qtbase/src/opengl/opengl.pro - Module has 8 public headers now - QtOpenGL.diff created Found module QtOpenGLExtensions in /home/frederik/dev/qt/qt-src- dev//qtbase/src/openglextensions/openglextensions.pro - Module has 1 public headers now - QtOpenGLExtensions.diff created Found module QtPlatformSupport in /home/frederik/dev/qt/qt-src- dev//qtbase/src/platformsupport/platformsupport.pro - No public headers for module QtPlatformSupport Found module QtPrintSupport in /home/frederik/dev/qt/qt-src- dev//qtbase/src/printsupport/printsupport.pro - Module has 9 public headers now - QtPrintSupport.diff created Found module QtSql in /home/frederik/dev/qt/qt-src-dev//qtbase/src/sql/sql.pro - Module has 14 public headers now - QtSql.diff created Found module QtTest in /home/frederik/dev/qt/qt-src- dev//qtbase/src/testlib/testlib.pro - Module has 18 public headers now - QtTest.diff created Found module QtWidgets in /home/frederik/dev/qt/qt-src- dev//qtbase/src/widgets/widgets.pro - Module has 135 public headers now - QtWidgets.diff created Found module qtmain in /home/frederik/dev/qt/qt-src- dev//qtbase/src/winmain/winmain.pro - No public headers for module qtmain Found module QtXml in /home/frederik/dev/qt/qt-src-dev//qtbase/src/xml/xml.pro - Module has 3 public headers now - QtXml.diff created Found module QtBluetooth in /home/frederik/dev/qt/qt-src- dev//qtconnectivity/src/bluetooth/bluetooth.pro - Module has 19 public headers now - QtBluetooth.diff created Found module QtNfc in /home/frederik/dev/qt/qt-src- dev//qtconnectivity/src/nfc/nfc.pro - Module has 12 public headers now - QtNfc.diff created Found module QtQuickParticles in /home/frederik/dev/qt/qt-src- dev//qtdeclarative/src/particles/particles.pro - No public headers for module QtQuickParticles Found module QtQml in /home/frederik/dev/qt/qt-src- dev//qtdeclarative/src/qml/qml.pro - Module has 27 public headers now - QtQml.diff created Found module QtQmlDevTools in /home/frederik/dev/qt/qt-src- dev//qtdeclarative/src/qmldevtools/qmldevtools.pro - No public headers for module QtQmlDevTools Found module QtQuickTest in /home/frederik/dev/qt/qt-src- dev//qtdeclarative/src/qmltest/qmltest.pro - Module has 2 public headers now - QtQuickTest.diff created Found module QtQuick in /home/frederik/dev/qt/qt-src- dev//qtdeclarative/src/quick/quick.pro - Module has 24 public headers now - QtQuick.diff created Found module QtQuickWidgets in /home/frederik/dev/qt/qt-src- dev//qtdeclarative/src/quickwidgets/quickwidgets.pro - Module has 2 public headers now - QtQuickWidgets.diff created Found module QtDocGallery in /home/frederik/dev/qt/qt-src- dev//qtdocgallery/src/gallery/gallery.pro - Module has 14 public headers now fatal: bad revision 'origin/5.4.2..origin/5.5.0' - Git failed, skipping Found module Enginio in /home/frederik/dev/qt/qt-src- dev//qtenginio/src/enginio_client/enginio_client.pro - Module has 10 public headers now fatal: bad revision 'origin/5.4.2..origin/5.5.0' - Git failed, skipping Found module enginioplugin in /home/frederik/dev/qt/qt-src- dev//qt
Re: [Development] Q_OBJECT and "override"
> 1) Add "override" (or rather Q_DECL_OVERRIDE) to the definition of
> Q_OBJECT *and* all QObject-derived classes in Qt.
[...]
> 2) Remove "override" from all QObject-derived classes in Qt.
[...]
> 3) Explicitly disable the warning in the clang mkspecs.
[...]
> 4) Let users deal with the problem by making them turn the warning off.
[...]
1) is the thing to do, but OTOH it's a lot of work with questionable gain.
2) and 4) are very wrong. IMO, we shouldn't do this.
3) could be a good compromise. There's a variant of this solution by turning
the warning off
at the beginning of every header and turning it on again at the end.
We once had the QT_{BEGIN|END}_HEADER macros which could expand to
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wannoyingwarning"
and repectively
#pragma clang diagnostic pop
This way the warning can be turned on for user code.
BR,
Joerg
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Q_OBJECT and "override"
Hi, as anyone who uses clang has probably already noticed, this compiler has recently added "-Winconsistent-missing-override" to the collection of flags enabled via "-Wall". As a result, you now get literally thousands of warnings when building any non-trivial Qt project. This is because the expansion of the Q_OBJECT macro contains virtual overrides that are not marked with the "override" keyword, so all QObject-derived classes using Q_OBJECT and making use of the "override" keyword will trigger this warning. Adding the keyword in the Q_OBJECT definition does not help in itself, as now all derived classes *not* using "override" would trigger the warning. So how to deal with this? 1) Add "override" (or rather Q_DECL_OVERRIDE) to the definition of Q_OBJECT *and* all QObject-derived classes in Qt. Pros: Is the correct solution. Cons: Tedious work, will introduce some noise into the git history. 2) Remove "override" from all QObject-derived classes in Qt. Pros: Less work than 1) Cons: Entirely wrong. Discourages developers from using "override" in their code, for a start. 3) Explicitly disable the warning in the clang mkspecs. Pros: Easy to do. Cons: Users might want to enable the warning, but they can't, as they will then drown in warnings from our headers. 4) Let users deal with the problem by making them turn the warning off. Pros: Even easier to do. Cons: See 3). Also seems very lazy. Opinions? Christian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
