qt5base-lts/tests
Tor Arne Vestbø 0a93db4d82 Unify application palette handling between QGuiApplication and QApplication
The logic is now mostly handled in QGuiApplication, with QApplication
only dealing with the widget-specific palettes and interaction between
the style and the palette.

The application now picks up changes to the platform theme and will
re-resolve the current application palette appropriately. This also
works even if an explicit application palette has been set, in which
case any missing roles are filled in by the theme.

The palette can now also be reset back to the default application
palette that's fully based on the theme, by passing in the default
constructed palette (or any palette that doesn't have any roles set).
This is also correctly reflected in the Qt::AA_SetPalette attribute.

Conceptually this means QGuiApplication and QApplication follow the
same behavior as QWidget, where the palette falls back to a base or
inherited palette for roles that are not set, in this case the theme.

Behavior-wise this means that the default application palette of the
application does not have any roles set, but clients should not have
relied on this, nor does QWidget rely on that internally.

It also means that setting a palette on the application and then
getting it back again will not produce the same palette as set,
since the palette was resolved against the theme in the meantime.
This is the same behavior as for QWidget, and although it's a
behavior change it's one towards a more sane behavior, so we
accept it.

[ChangeLog] Application palettes are now resolved against the platform's
theme palette, the same way widget palettes are resolved against their
parents, and the application palette. This means the application palette
reflected through QGuiApplication::palette() may not be exactly the same
palette as set via QGuiApplication::setPalette().

Change-Id: I76b99fcd27285e564899548349aa2a5713e5965d
Reviewed-by: Vitaly Fanaskov <vitaly.fanaskov@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2020-01-13 16:53:05 +01:00
..
auto Unify application palette handling between QGuiApplication and QApplication 2020-01-13 16:53:05 +01:00
baselineserver QAbstractSocket: deprecate 'error' member-function 2020-01-10 12:54:53 +01:00
benchmarks QNetworkReply: deprecate the 'error' getter 2020-01-13 15:50:47 +01:00
global
libfuzzer Fuzzing: Move fuzz target to match path of tested code 2020-01-07 21:15:09 +01:00
manual rhi: Add render-to-cubemap manual test 2020-01-13 15:52:58 +01:00
shared Remove usages of Q_OS_WINCE 2019-05-23 13:51:05 +02:00
testserver docker-compose now brings up the docker images tagged as "latest" 2019-12-05 15:40:00 +01:00
README
tests.pro

This directory contains autotests and benchmarks based on Qt Test. In order
to run the autotests reliably, you need to configure a desktop to match the
test environment that these tests are written for.

Linux X11:

   * The user must be logged in to an active desktop; you can't run the
     autotests without a valid DISPLAY that allows X11 connections.

   * The tests are run against a KDE3 or KDE4 desktop.

   * Window manager uses "click to focus", and not "focus follows mouse". Many
     tests move the mouse cursor around and expect this to not affect focus
     and activation.

   * Disable "click to activate", i.e., when a window is opened, the window
     manager should automatically activate it (give it input focus) and not
     wait for the user to click the window.