yukijoou/kwin
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
kwin/autotests/CMakeLists.txt

310 lines
9.5 KiB
Text
Raw Normal View History

[kwin] Introduce a new Effect Loading mechanism Effect loading gets split by the kind of effects KWin supports: * Built-In Effects * Scripted Effects * Binary Plugin Effects For this a new AbstractEffectLoader is added which will have several sub-classes: * BuiltInEffectLoader * ScriptedEffectLoader * PluginEffectLoader * EffectLoader The EffectLoader will be what the EffectsHandlerImpl is using and it just delegates to the three other types of loaders. Thus the handler doesn't need to care about the different kinds of effects. The loading is supposed to be completely async and the EffectLoader emits a signal whenever an Effect got loaded. The EffectsHandlerImpl is supposed to connect to this signal and insert it into its own Effect management. Unloading is not performed by the loader, but by the EffectsHandler. There is one important change which needs to be implemented: the ordering cannot be provided by the loader and thus needs to be added to the Effects directly. So far only the BuiltInEffectsLoader is implemented. It's not yet integrated into the EffectsHandlerImpl, but a unit test is added which tries to perform the various operations provided by the loader and the BuiltInEffects. The test should cover all cases except the Check Default functionality which is only used by Blur and Contrast effects. This cannot be mocked yet as the GLPlatform doesn't allow mocking yet.
2014-03-22 08:48:07 +00:00
add_definitions(-DKWIN_UNIT_TEST)
optimize string operations -use qstringliteral only when necessary (i.e. not in concat or comparison) -use qbytearray instead of qstring when dealing with latin1 input and output (glplatform) -use qstringref to extract numbers from strings (glplatform) -define qt_use_qstringbuilder to optimize all string concatenations -anidata: use ctor init lists, add windowType member initialization REVIEW: 125933
2015-11-05 14:14:06 +00:00
remove_definitions(-DQT_USE_QSTRINGBUILDER)
[autotest] Welcome to integration testing KWin This is the beginning of a new testing era for KWin: finally we are able to test against a running KWin. This works by making use of the new virtual framebuffer backend for Wayland. It starts a specific Application subclass which is mostly a fork of ApplicationWayland. The individual tests are able to influence the socket name and the size of the virtual screen. This is supposed to be done in initTestCase. To know when KWin is fully started one can use the workspaceCreated signal of KWin::Application. KWin is not started in another process, but the kwin library is used, so the test has pretty much full introspection to everything going on inside KWin. It can access the Workspace, WaylandServer, fake input events through InputRedirection and so on. Once the test KWin is running it's possible to connect to it using KWayland::Client library. This allows to introspect the Workspace to see whether all worked as expected (e.g. correct stacking order, active window and so on). This first autotest is mostly meant to illustrate how to setup a test and how one can use KWayland::Client to interact with the mock KWin. For more tests it is suggested to move the connections to the Wayland server in the init() and cleanup() methods. The change also affects the qpa plugin: the specific check to only run in binaries called kwin_wayland doesn't hold any more. This can now be overwritten by an env variable. Please note that this first test will probably fail in the CI system as it might not have XWayland which is needed by KWin.
2015-10-02 13:04:57 +00:00
add_subdirectory(wayland)
[autotest] Add a test case for KWin::LibInput::Device Summary: The usage of libinput is completely mocked. The test covers all the constant properties read by Device. There are some features which are not yet tested: * alphaNumericKeyboard * supportedButtons * enabled The setters for leftHanded and pointerAcceleration are also covered including the variants where it can fail. Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1648
2016-05-20 13:48:11 +00:00
if (HAVE_INPUT)
add_subdirectory(libinput)
endif()
[kwin-wayland] Create dedicated thread for wayland connection The Wayland event queue is moved into a dedicated thread and a new class is created for just creating the connection and listening for events. The WaylandBackend creates the thread and uses an event queue for the main thread. REVIEW: 119761
2014-08-13 10:54:02 +00:00
Adding unit test for ScreenPaintData and WindowPaintData
2012-06-03 07:15:10 +00:00
########################################################
# Test ScreenPaintData
########################################################
set( testScreenPaintData_SRCS test_screen_paint_data.cpp )
[kwin] Port autotests away from kde4_add_unit_test
2014-03-18 10:49:53 +00:00
add_executable(testScreenPaintData ${testScreenPaintData_SRCS})
Stop including KDE4_INCLUDES globally Depend on libraries specifically instead.
2014-03-18 16:53:22 +00:00
target_link_libraries( testScreenPaintData kwineffects Qt5::Test Qt5::Widgets KF5::WindowSystem)
[kwin] Port autotests away from kde4_add_unit_test
2014-03-18 10:49:53 +00:00
add_test(kwin-testScreenPaintData testScreenPaintData)
ecm_mark_as_test(testScreenPaintData)
Adding unit test for ScreenPaintData and WindowPaintData
2012-06-03 07:15:10 +00:00
########################################################
# Test WindowPaintData
########################################################
set( testWindowPaintData_SRCS test_window_paint_data.cpp )
[kwin] Port autotests away from kde4_add_unit_test
2014-03-18 10:49:53 +00:00
add_executable(testWindowPaintData ${testWindowPaintData_SRCS})
Use Qt5:: in target link libraries in KWin
2013-08-20 07:10:18 +00:00
target_link_libraries( testWindowPaintData kwineffects Qt5::Widgets Qt5::Test )
[kwin] Port autotests away from kde4_add_unit_test
2014-03-18 10:49:53 +00:00
add_test(kwin-testWindowPaintData testWindowPaintData)
ecm_mark_as_test(testWindowPaintData)
Move handling of Virtual Desktops into a VirtualDesktopManager The ownership for virtual desktops is moved from Workspace into a new VirtualDesktopManager. The manager is responsible for providing the count of virtual desktops and keeping track of the currently used virtual desktop. All methods related to moving between desktops are also moved from Workspace to the new manager, though all methods related to Clients on Virtual Desktops remain in Workspace for the time being. This is to have the new manager as independent from KWin core as possible. An rather important change for the handling of virtual desktops is that the count and the id of a desktop is now an unsinged integer instead of an integer. The reason for that is that we cannot have a negative count of desktops as well as it is not possible to be on a desktop with a negative identifier. In that regard it is important to remember that a Client can be on a desktop with a negative identifier. The special value for a Client being on all desktops is handled by using -1 as a desktop. For the time being this is not adjusted but instead of comparing the virtual desktop ids one should prefer to use the convenient methods like isOnDesktop and isOnAllDesktops. This would allow in future to internally change the representation for on all desktops.
2012-11-16 07:23:47 +00:00
########################################################
# Test VirtualDesktopManager
########################################################
[kwin] Fix TestVirtualDesktops * enable compilation * Remove KActionCollection
2014-01-07 12:45:25 +00:00
set( testVirtualDesktops_SRCS
test_virtual_desktops.cpp
../virtualdesktops.cpp
)
[kwin] Port autotests away from kde4_add_unit_test
2014-03-18 10:49:53 +00:00
add_executable(testVirtualDesktops ${testVirtualDesktops_SRCS})
[kwin] Fix TestVirtualDesktops * enable compilation * Remove KActionCollection
2014-01-07 12:45:25 +00:00
target_link_libraries( testVirtualDesktops
Qt5::Test
Qt5::Widgets
KF5::I18n
KF5::GlobalAccel
KF5::ConfigCore
KF5::WindowSystem
)
[kwin] Port autotests away from kde4_add_unit_test
2014-03-18 10:49:53 +00:00
add_test(kwin-testVirtualDesktops testVirtualDesktops)
ecm_mark_as_test(testVirtualDesktops)
Improved resolving whether a window is on local machine Most windows use the hostname in WM_CLIENT_MACHINE, but there are windows using the FQDN (for example libreoffice). So instead of "foo" it is "foo.local.net" or similar. The logic so far has been unable to properly determine whether windows with FQDN are on the local system. In order to solve this problem the handling is split out into an own class which stores the information of hostname and whether it is a local machine. This is to not query multiple times. To determine whether the Client is on the local system getaddrinfo is used for the own hostname and the FQDN provided in WM_CLIENT_MACHINE. If one of the queried names matches, we know that it is on the local machine. The old logic to compare the hostname is still used and getaddrinfo is only a fallback in case hostname does not match. The problem with getaddrinfo is, that it accesses the network and by that could block. To circumvent this problem the calls are moved into threads by using QtConcurrent::run. Obviously this brings disadvantages. When trying to resolve whether a Client is on the local machine and a FQDN is used, the information is initially wrong. The new ClientMachine class emits a signal when the information that the system is local becomes available, but for some things this is just too late: * window rules are already gathered * Session Management has already taken place In both cases this is an acceptable loss. For window rules it just needs a proper matching of the machine in case of localhost (remote hosts are not affected). And the case of session management is very academic as it is unlikely that a restoring session contains remote windows. BUG: 308391 FIXED-IN: 4.11 REVIEW: 108235
2013-01-07 07:07:27 +00:00
########################################################
# Test ClientMachine
########################################################
set( testClientMachine_SRCS
test_client_machine.cpp
../client_machine.cpp
)
[kwin] Port autotests away from kde4_add_unit_test
2014-03-18 10:49:53 +00:00
add_executable( testClientMachine ${testClientMachine_SRCS} )
Improved resolving whether a window is on local machine Most windows use the hostname in WM_CLIENT_MACHINE, but there are windows using the FQDN (for example libreoffice). So instead of "foo" it is "foo.local.net" or similar. The logic so far has been unable to properly determine whether windows with FQDN are on the local system. In order to solve this problem the handling is split out into an own class which stores the information of hostname and whether it is a local machine. This is to not query multiple times. To determine whether the Client is on the local system getaddrinfo is used for the own hostname and the FQDN provided in WM_CLIENT_MACHINE. If one of the queried names matches, we know that it is on the local machine. The old logic to compare the hostname is still used and getaddrinfo is only a fallback in case hostname does not match. The problem with getaddrinfo is, that it accesses the network and by that could block. To circumvent this problem the calls are moved into threads by using QtConcurrent::run. Obviously this brings disadvantages. When trying to resolve whether a Client is on the local machine and a FQDN is used, the information is initially wrong. The new ClientMachine class emits a signal when the information that the system is local becomes available, but for some things this is just too late: * window rules are already gathered * Session Management has already taken place In both cases this is an acceptable loss. For window rules it just needs a proper matching of the machine in case of localhost (remote hosts are not affected). And the case of session management is very academic as it is unlikely that a restoring session contains remote windows. BUG: 308391 FIXED-IN: 4.11 REVIEW: 108235
2013-01-07 07:07:27 +00:00
target_link_libraries( testClientMachine
Fix linking and includes Seems like there were some changes, we need more explicit linking.
2013-10-02 13:23:56 +00:00
Qt5::Concurrent
Use Qt5:: in target link libraries in KWin
2013-08-20 07:10:18 +00:00
Qt5::Test
Qt5::X11Extras
Qt5::Widgets
Track used cursor theme and size in Cursor Reads the settings from kcminputrc. Unfortunately there is no update when the settings change. This needs fixing in the cursors KCM first.
2013-06-27 07:06:16 +00:00
KF5::ConfigCore
Port to KF5 renaming changes
2013-12-11 20:41:47 +00:00
KF5::WindowSystem
[kwin] Use imported targets for all XCB libs Requires 04f78489265b6e52cabd2980dfc417abeee3a695 from ECM
2014-02-25 14:48:39 +00:00
XCB::XCB
XCB::XFIXES
Make Jenkins happy Yes, it linked on my system.
2013-05-13 07:58:04 +00:00
${X11_X11_LIB} # to make jenkins happy
Improved resolving whether a window is on local machine Most windows use the hostname in WM_CLIENT_MACHINE, but there are windows using the FQDN (for example libreoffice). So instead of "foo" it is "foo.local.net" or similar. The logic so far has been unable to properly determine whether windows with FQDN are on the local system. In order to solve this problem the handling is split out into an own class which stores the information of hostname and whether it is a local machine. This is to not query multiple times. To determine whether the Client is on the local system getaddrinfo is used for the own hostname and the FQDN provided in WM_CLIENT_MACHINE. If one of the queried names matches, we know that it is on the local machine. The old logic to compare the hostname is still used and getaddrinfo is only a fallback in case hostname does not match. The problem with getaddrinfo is, that it accesses the network and by that could block. To circumvent this problem the calls are moved into threads by using QtConcurrent::run. Obviously this brings disadvantages. When trying to resolve whether a Client is on the local machine and a FQDN is used, the information is initially wrong. The new ClientMachine class emits a signal when the information that the system is local becomes available, but for some things this is just too late: * window rules are already gathered * Session Management has already taken place In both cases this is an acceptable loss. For window rules it just needs a proper matching of the machine in case of localhost (remote hosts are not affected). And the case of session management is very academic as it is unlikely that a restoring session contains remote windows. BUG: 308391 FIXED-IN: 4.11 REVIEW: 108235
2013-01-07 07:07:27 +00:00
)
[kwin] Port autotests away from kde4_add_unit_test
2014-03-18 10:49:53 +00:00
add_test(kwin-testClientMachine testClientMachine)
ecm_mark_as_test(testClientMachine)
Do not use a shared pointer for the Xcb::Wrapper It's not really needed, the required functionality can be achieved in a more implicit way. The reply pointer is managed by the Wrapper class as long as the method take() is not invoked. This method follows the semantics of QScopedPointer::take(). That is the pointer is set to null and the responsibility to free the pointer is passed to the callee. By this change we do not have the overhead of creating a QSharedPointer. In addition the Wrapper provides a copy ctor and assignment operator also using the semantics of take().
2013-01-14 08:20:59 +00:00
########################################################
# Test XcbWrapper
########################################################
set( testXcbWrapper_SRCS
test_xcb_wrapper.cpp
)
[kwin] Port autotests away from kde4_add_unit_test
2014-03-18 10:49:53 +00:00
add_executable( testXcbWrapper ${testXcbWrapper_SRCS} )
Do not use a shared pointer for the Xcb::Wrapper It's not really needed, the required functionality can be achieved in a more implicit way. The reply pointer is managed by the Wrapper class as long as the method take() is not invoked. This method follows the semantics of QScopedPointer::take(). That is the pointer is set to null and the responsibility to free the pointer is passed to the callee. By this change we do not have the overhead of creating a QSharedPointer. In addition the Wrapper provides a copy ctor and assignment operator also using the semantics of take().
2013-01-14 08:20:59 +00:00
target_link_libraries( testXcbWrapper
Use Qt5:: in target link libraries in KWin
2013-08-20 07:10:18 +00:00
Qt5::Test
Qt5::X11Extras
Qt5::Widgets
KWin::Application holdes a KSharedConfigPtr with the config This allows the integration tests to provide their own configuration as they need it. Setting the configuration should be done before invoking start()
2016-01-29 08:48:02 +00:00
KF5::ConfigCore
[kwin] Add missing target link libraries Missing libs caused compile error if built standalone.
2014-03-18 13:38:00 +00:00
KF5::WindowSystem
[kwin] Use imported targets for all XCB libs Requires 04f78489265b6e52cabd2980dfc417abeee3a695 from ECM
2014-02-25 14:48:39 +00:00
XCB::XCB
Do not use a shared pointer for the Xcb::Wrapper It's not really needed, the required functionality can be achieved in a more implicit way. The reply pointer is managed by the Wrapper class as long as the method take() is not invoked. This method follows the semantics of QScopedPointer::take(). That is the pointer is set to null and the responsibility to free the pointer is passed to the callee. By this change we do not have the overhead of creating a QSharedPointer. In addition the Wrapper provides a copy ctor and assignment operator also using the semantics of take().
2013-01-14 08:20:59 +00:00
)
[kwin] Port autotests away from kde4_add_unit_test
2014-03-18 10:49:53 +00:00
add_test(kwin-testXcbWrapper testXcbWrapper)
ecm_mark_as_test(testXcbWrapper)
Light-weight wrapper class for an xcb_window_t The idea behind this class is to relieve the developer from having to call xcb_destroy_window once it is no longer needed. That is having a RAII approach to windows. In addition the class provides some simple method wrappers for the most common use cases inside KWin: * map * unmap * setGeometry - basically a moveResizeWindow * ...
2013-01-29 13:03:05 +00:00
Add Xcb::GeometryHints class It's a convenient class to encapsulate the ICCCM WM_SIZE_HINT. Instead of exposing just the properties it provides accessors for the interesting parts and applies sanity checks.
2015-01-21 13:54:20 +00:00
if (XCB_ICCCM_FOUND)
add_executable( testXcbSizeHints test_xcb_size_hints.cpp )
target_link_libraries( testXcbSizeHints
Qt5::Test
Qt5::X11Extras
KWin::Application holdes a KSharedConfigPtr with the config This allows the integration tests to provide their own configuration as they need it. Setting the configuration should be done before invoking start()
2016-01-29 08:48:02 +00:00
KF5::ConfigCore
Add Xcb::GeometryHints class It's a convenient class to encapsulate the ICCCM WM_SIZE_HINT. Instead of exposing just the properties it provides accessors for the interesting parts and applies sanity checks.
2015-01-21 13:54:20 +00:00
KF5::WindowSystem
XCB::XCB
XCB::ICCCM
)
add_test(kwin-testXcbSizeHints testXcbSizeHints)
ecm_mark_as_test(testXcbSizeHints)
endif()
Light-weight wrapper class for an xcb_window_t The idea behind this class is to relieve the developer from having to call xcb_destroy_window once it is no longer needed. That is having a RAII approach to windows. In addition the class provides some simple method wrappers for the most common use cases inside KWin: * map * unmap * setGeometry - basically a moveResizeWindow * ...
2013-01-29 13:03:05 +00:00
########################################################
# Test XcbWindow
########################################################
set( testXcbWindow_SRCS
test_xcb_window.cpp
)
[kwin] Port autotests away from kde4_add_unit_test
2014-03-18 10:49:53 +00:00
add_executable( testXcbWindow ${testXcbWindow_SRCS} )
Light-weight wrapper class for an xcb_window_t The idea behind this class is to relieve the developer from having to call xcb_destroy_window once it is no longer needed. That is having a RAII approach to windows. In addition the class provides some simple method wrappers for the most common use cases inside KWin: * map * unmap * setGeometry - basically a moveResizeWindow * ...
2013-01-29 13:03:05 +00:00
target_link_libraries( testXcbWindow
Use Qt5:: in target link libraries in KWin
2013-08-20 07:10:18 +00:00
Qt5::Test
Qt5::X11Extras
Qt5::Widgets
KWin::Application holdes a KSharedConfigPtr with the config This allows the integration tests to provide their own configuration as they need it. Setting the configuration should be done before invoking start()
2016-01-29 08:48:02 +00:00
KF5::ConfigCore
[kwin] Add missing target link libraries Missing libs caused compile error if built standalone.
2014-03-18 13:38:00 +00:00
KF5::WindowSystem
[kwin] Use imported targets for all XCB libs Requires 04f78489265b6e52cabd2980dfc417abeee3a695 from ECM
2014-02-25 14:48:39 +00:00
XCB::XCB
Light-weight wrapper class for an xcb_window_t The idea behind this class is to relieve the developer from having to call xcb_destroy_window once it is no longer needed. That is having a RAII approach to windows. In addition the class provides some simple method wrappers for the most common use cases inside KWin: * map * unmap * setGeometry - basically a moveResizeWindow * ...
2013-01-29 13:03:05 +00:00
)
[kwin] Port autotests away from kde4_add_unit_test
2014-03-18 10:49:53 +00:00
add_test(kwin-testXcbWindow testXcbWindow)
ecm_mark_as_test(testXcbWindow)
[kwin] Introduce a new Effect Loading mechanism Effect loading gets split by the kind of effects KWin supports: * Built-In Effects * Scripted Effects * Binary Plugin Effects For this a new AbstractEffectLoader is added which will have several sub-classes: * BuiltInEffectLoader * ScriptedEffectLoader * PluginEffectLoader * EffectLoader The EffectLoader will be what the EffectsHandlerImpl is using and it just delegates to the three other types of loaders. Thus the handler doesn't need to care about the different kinds of effects. The loading is supposed to be completely async and the EffectLoader emits a signal whenever an Effect got loaded. The EffectsHandlerImpl is supposed to connect to this signal and insert it into its own Effect management. Unloading is not performed by the loader, but by the EffectsHandler. There is one important change which needs to be implemented: the ordering cannot be provided by the loader and thus needs to be added to the Effects directly. So far only the BuiltInEffectsLoader is implemented. It's not yet integrated into the EffectsHandlerImpl, but a unit test is added which tries to perform the various operations provided by the loader and the BuiltInEffects. The test should cover all cases except the Check Default functionality which is only used by Blur and Contrast effects. This cannot be mocked yet as the GLPlatform doesn't allow mocking yet.
2014-03-22 08:48:07 +00:00
########################################################
# Test BuiltInEffectLoader
########################################################
set( testBuiltInEffectLoader_SRCS
test_builtin_effectloader.cpp
mock_effectshandler.cpp
../effectloader.cpp
)
add_executable( testBuiltInEffectLoader ${testBuiltInEffectLoader_SRCS})
target_link_libraries(testBuiltInEffectLoader
[kwin] Add a ScriptedEffectLoader This implementation of the AbstractEffectLoader is able to to load the scripted KWin Effects. It uses KServiceTypeTrader to find all the candidates to load.
2014-03-23 08:23:30 +00:00
Qt5::Concurrent
[kwin] Introduce a new Effect Loading mechanism Effect loading gets split by the kind of effects KWin supports: * Built-In Effects * Scripted Effects * Binary Plugin Effects For this a new AbstractEffectLoader is added which will have several sub-classes: * BuiltInEffectLoader * ScriptedEffectLoader * PluginEffectLoader * EffectLoader The EffectLoader will be what the EffectsHandlerImpl is using and it just delegates to the three other types of loaders. Thus the handler doesn't need to care about the different kinds of effects. The loading is supposed to be completely async and the EffectLoader emits a signal whenever an Effect got loaded. The EffectsHandlerImpl is supposed to connect to this signal and insert it into its own Effect management. Unloading is not performed by the loader, but by the EffectsHandler. There is one important change which needs to be implemented: the ordering cannot be provided by the loader and thus needs to be added to the Effects directly. So far only the BuiltInEffectsLoader is implemented. It's not yet integrated into the EffectsHandlerImpl, but a unit test is added which tries to perform the various operations provided by the loader and the BuiltInEffects. The test should cover all cases except the Check Default functionality which is only used by Blur and Contrast effects. This cannot be mocked yet as the GLPlatform doesn't allow mocking yet.
2014-03-22 08:48:07 +00:00
Qt5::Test
Port scripted effect loading from KService to KPackage Advantage: no more ksycoca cache for loading scripted effects.
2015-07-06 14:50:33 +00:00
KF5::Package
[kwin] Introduce a new Effect Loading mechanism Effect loading gets split by the kind of effects KWin supports: * Built-In Effects * Scripted Effects * Binary Plugin Effects For this a new AbstractEffectLoader is added which will have several sub-classes: * BuiltInEffectLoader * ScriptedEffectLoader * PluginEffectLoader * EffectLoader The EffectLoader will be what the EffectsHandlerImpl is using and it just delegates to the three other types of loaders. Thus the handler doesn't need to care about the different kinds of effects. The loading is supposed to be completely async and the EffectLoader emits a signal whenever an Effect got loaded. The EffectsHandlerImpl is supposed to connect to this signal and insert it into its own Effect management. Unloading is not performed by the loader, but by the EffectsHandler. There is one important change which needs to be implemented: the ordering cannot be provided by the loader and thus needs to be added to the Effects directly. So far only the BuiltInEffectsLoader is implemented. It's not yet integrated into the EffectsHandlerImpl, but a unit test is added which tries to perform the various operations provided by the loader and the BuiltInEffects. The test should cover all cases except the Check Default functionality which is only used by Blur and Contrast effects. This cannot be mocked yet as the GLPlatform doesn't allow mocking yet.
2014-03-22 08:48:07 +00:00
kwineffects
kwin4_effect_builtins
)
add_test(kwin-testBuiltInEffectLoader testBuiltInEffectLoader)
ecm_mark_as_test(testBuiltInEffectLoader)
[kwin] Add a ScriptedEffectLoader This implementation of the AbstractEffectLoader is able to to load the scripted KWin Effects. It uses KServiceTypeTrader to find all the candidates to load.
2014-03-23 08:23:30 +00:00
########################################################
# Test ScriptedEffectLoader
########################################################
include_directories(${KWIN_SOURCE_DIR})
set( testScriptedEffectLoader_SRCS
test_scripted_effectloader.cpp
mock_effectshandler.cpp
../effectloader.cpp
../scripting/scriptedeffect.cpp
../scripting/scriptingutils.cpp
[scripting] Add dedicated logging category
2015-07-31 11:24:56 +00:00
../scripting/scripting_logging.cpp
[kwin] Add a ScriptedEffectLoader This implementation of the AbstractEffectLoader is able to to load the scripted KWin Effects. It uses KServiceTypeTrader to find all the candidates to load.
2014-03-23 08:23:30 +00:00
)
add_executable( testScriptedEffectLoader ${testScriptedEffectLoader_SRCS})
target_link_libraries(testScriptedEffectLoader
Qt5::Concurrent
Qt5::Script
Qt5::Test
KF5::ConfigGui
KF5::GlobalAccel
KF5::I18n
Port scripted effect loading from KService to KPackage Advantage: no more ksycoca cache for loading scripted effects.
2015-07-06 14:50:33 +00:00
KF5::Package
[kwin] Add a ScriptedEffectLoader This implementation of the AbstractEffectLoader is able to to load the scripted KWin Effects. It uses KServiceTypeTrader to find all the candidates to load.
2014-03-23 08:23:30 +00:00
kwineffects
kwin4_effect_builtins
)
add_test(kwin-testScriptedEffectLoader testScriptedEffectLoader)
ecm_mark_as_test(testScriptedEffectLoader)
[kwin] Add a PluginEffectLoader This is a specialized subclass of AbstractEffectLoader to load binary effect plugins. It used the KPluginTrader to find all candidates to load. The loader is able to detect incorrect ABI versions through the pluginVersion() and uses the methods exposed by the new KWin::EffectPluginFactory to check whether the Effect is supported and should be enabled by default. The unit test for this loader comes with two plugins: one is able to be loaded and provides a supported and enabledByDefault method which can be tweaked during the test to get all the conditions we want to test for. The second plugin uses an incorrect plugin version and thus cannot get loaded.
2014-03-25 10:39:07 +00:00
########################################################
# Test PluginEffectLoader
########################################################
set( testPluginEffectLoader_SRCS
test_plugin_effectloader.cpp
mock_effectshandler.cpp
../effectloader.cpp
)
add_executable( testPluginEffectLoader ${testPluginEffectLoader_SRCS})
target_link_libraries(testPluginEffectLoader
Qt5::Concurrent
Qt5::Test
Port scripted effect loading from KService to KPackage Advantage: no more ksycoca cache for loading scripted effects.
2015-07-06 14:50:33 +00:00
KF5::Package
[kwin] Add a PluginEffectLoader This is a specialized subclass of AbstractEffectLoader to load binary effect plugins. It used the KPluginTrader to find all candidates to load. The loader is able to detect incorrect ABI versions through the pluginVersion() and uses the methods exposed by the new KWin::EffectPluginFactory to check whether the Effect is supported and should be enabled by default. The unit test for this loader comes with two plugins: one is able to be loaded and provides a supported and enabledByDefault method which can be tweaked during the test to get all the conditions we want to test for. The second plugin uses an incorrect plugin version and thus cannot get loaded.
2014-03-25 10:39:07 +00:00
kwineffects
kwin4_effect_builtins
)
add_test(kwin-testPluginEffectLoader testPluginEffectLoader)
ecm_mark_as_test(testPluginEffectLoader)
########################################################
# FakeEffectPlugin
########################################################
add_library(fakeeffectplugin MODULE fakeeffectplugin.cpp)
set_target_properties(fakeeffectplugin PROPERTIES PREFIX "")
target_link_libraries(fakeeffectplugin kwineffects)
########################################################
# FakeEffectPlugin-Version
########################################################
add_library(effectversionplugin MODULE fakeeffectplugin_version.cpp)
set_target_properties(effectversionplugin PROPERTIES PREFIX "")
target_link_libraries(effectversionplugin kwineffects)
[auto-tests] Add an initial test for Screens This is a very interesting auto test as Screens uses both Workspace and Client. Thus it operates in the "impossible to mock" area. The solution is to provide mock includes in autotests and ensure that when building the auto-test the mock header includes will be picked first. There is now a mock class for Workspace and Client providing just the API pieces used inside Screens. As Screens is abstract and we cannot properly interact with QDesktopWidget there is also a MockScreens class inheriting from Screens and mocking the required functionality (by just operating on a list of QRects). The auto-test itself is only performing checks on the abstract class. The mock class is indirectly tested by Screens calling into the virtual methods. The test case is not yet complete, but looking quite good already.
2014-09-17 08:29:03 +00:00
########################################################
# Test Screens
########################################################
set( testScreens_SRCS
test_screens.cpp
[autotests] Adjust to changes regarding AbstractClient We need a Mock for AbstractClient and our mock Client needs to inherit from it.
2015-04-29 12:13:20 +00:00
mock_abstract_client.cpp
[auto-tests] Add an initial test for Screens This is a very interesting auto test as Screens uses both Workspace and Client. Thus it operates in the "impossible to mock" area. The solution is to provide mock includes in autotests and ensure that when building the auto-test the mock header includes will be picked first. There is now a mock class for Workspace and Client providing just the API pieces used inside Screens. As Screens is abstract and we cannot properly interact with QDesktopWidget there is also a MockScreens class inheriting from Screens and mocking the required functionality (by just operating on a list of QRects). The auto-test itself is only performing checks on the abstract class. The mock class is indirectly tested by Screens calling into the virtual methods. The test case is not yet complete, but looking quite good already.
2014-09-17 08:29:03 +00:00
mock_client.cpp
mock_screens.cpp
mock_workspace.cpp
../screens.cpp
[screens] Replace DesktopWidgetScreens by XRandRScreens A new implementation of the Screens interface is added which uses XRandR directly instead of relying on QDesktopWidget. The implementation is provided in a new implementation file screens_xrandr.cpp. XRandRScreens comes with a unit test. Unfortunately it's rather difficult to provide a proper unit test against XRandR. Xvfb (which is obviously used on the CI system) doesn't provide the XRandR extension. Also on a "normal" developer system one would not want to just execute the test as the results are not predictable (number of available outputs?) and the test would mess up the setup resulting in nobody wanting to execute the test. As a solution to both problems the unit test starts Xephyr as a nested X server. This allows to have at least some limited tests against XRandR. Nevertheless there are a few things which I was not able to test: * multiple outputs * no output at all The nested X Server approach makes the interaction rather complex. Qt opens it's connection against the main X Server thus QX11Info provides a wrong connection and also KWin::connection() which is heavily used by xcbutils and thus all the RandR wrappers have the wrong connection. To circumvent this problem the test is GUILESS. In case it would call into any code using QX11Info, it would probably either runtime fail or crash. REVIEW: 117614
2014-04-17 15:33:11 +00:00
../x11eventfilter.cpp
[auto-tests] Add an initial test for Screens This is a very interesting auto test as Screens uses both Workspace and Client. Thus it operates in the "impossible to mock" area. The solution is to provide mock includes in autotests and ensure that when building the auto-test the mock header includes will be picked first. There is now a mock class for Workspace and Client providing just the API pieces used inside Screens. As Screens is abstract and we cannot properly interact with QDesktopWidget there is also a MockScreens class inheriting from Screens and mocking the required functionality (by just operating on a list of QRects). The auto-test itself is only performing checks on the abstract class. The mock class is indirectly tested by Screens calling into the virtual methods. The test case is not yet complete, but looking quite good already.
2014-09-17 08:29:03 +00:00
)
kconfig_add_kcfg_files(testScreens_SRCS ../settings.kcfgc)
add_executable( testScreens ${testScreens_SRCS})
target_include_directories(testScreens BEFORE PRIVATE ./)
target_link_libraries(testScreens
Qt5::Test
Qt5::X11Extras
KF5::ConfigCore
KF5::ConfigGui
KF5::WindowSystem
)
add_test(kwin_testScreens testScreens)
ecm_mark_as_test(testScreens)
Add an auto-test for ScreenEdges The new test does not cover ScreenEdges completely, so far the following areas are handled: * creating of the edges * reserving of edges * trigger callback * cursor pushback * blocking of edges for fullscreen active clients
2014-09-26 12:01:44 +00:00
[screens] Replace DesktopWidgetScreens by XRandRScreens A new implementation of the Screens interface is added which uses XRandR directly instead of relying on QDesktopWidget. The implementation is provided in a new implementation file screens_xrandr.cpp. XRandRScreens comes with a unit test. Unfortunately it's rather difficult to provide a proper unit test against XRandR. Xvfb (which is obviously used on the CI system) doesn't provide the XRandR extension. Also on a "normal" developer system one would not want to just execute the test as the results are not predictable (number of available outputs?) and the test would mess up the setup resulting in nobody wanting to execute the test. As a solution to both problems the unit test starts Xephyr as a nested X server. This allows to have at least some limited tests against XRandR. Nevertheless there are a few things which I was not able to test: * multiple outputs * no output at all The nested X Server approach makes the interaction rather complex. Qt opens it's connection against the main X Server thus QX11Info provides a wrong connection and also KWin::connection() which is heavily used by xcbutils and thus all the RandR wrappers have the wrong connection. To circumvent this problem the test is GUILESS. In case it would call into any code using QX11Info, it would probably either runtime fail or crash. REVIEW: 117614
2014-04-17 15:33:11 +00:00
########################################################
# Test XrandRScreens
########################################################
set( testXRandRScreens_SRCS
test_xrandr_screens.cpp
[autotests] Adjust to changes regarding AbstractClient We need a Mock for AbstractClient and our mock Client needs to inherit from it.
2015-04-29 12:13:20 +00:00
mock_abstract_client.cpp
[screens] Replace DesktopWidgetScreens by XRandRScreens A new implementation of the Screens interface is added which uses XRandR directly instead of relying on QDesktopWidget. The implementation is provided in a new implementation file screens_xrandr.cpp. XRandRScreens comes with a unit test. Unfortunately it's rather difficult to provide a proper unit test against XRandR. Xvfb (which is obviously used on the CI system) doesn't provide the XRandR extension. Also on a "normal" developer system one would not want to just execute the test as the results are not predictable (number of available outputs?) and the test would mess up the setup resulting in nobody wanting to execute the test. As a solution to both problems the unit test starts Xephyr as a nested X server. This allows to have at least some limited tests against XRandR. Nevertheless there are a few things which I was not able to test: * multiple outputs * no output at all The nested X Server approach makes the interaction rather complex. Qt opens it's connection against the main X Server thus QX11Info provides a wrong connection and also KWin::connection() which is heavily used by xcbutils and thus all the RandR wrappers have the wrong connection. To circumvent this problem the test is GUILESS. In case it would call into any code using QX11Info, it would probably either runtime fail or crash. REVIEW: 117614
2014-04-17 15:33:11 +00:00
mock_client.cpp
mock_screens.cpp
mock_workspace.cpp
../screens.cpp
Move XRandrScreens to the x11/standalone plugin By moving XRandrScreens the creation of screens gets simplified a lot as there is no need to have windowing system specific init code. It all just goes through the platform. This also marks the point where the first X11 specific code is removed from kwin_wayland. Reviewers: #plasma, sebas Subscribers: plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1355
2016-04-08 08:32:37 +00:00
../plugins/platforms/x11/standalone/screens_xrandr.cpp
[screens] Replace DesktopWidgetScreens by XRandRScreens A new implementation of the Screens interface is added which uses XRandR directly instead of relying on QDesktopWidget. The implementation is provided in a new implementation file screens_xrandr.cpp. XRandRScreens comes with a unit test. Unfortunately it's rather difficult to provide a proper unit test against XRandR. Xvfb (which is obviously used on the CI system) doesn't provide the XRandR extension. Also on a "normal" developer system one would not want to just execute the test as the results are not predictable (number of available outputs?) and the test would mess up the setup resulting in nobody wanting to execute the test. As a solution to both problems the unit test starts Xephyr as a nested X server. This allows to have at least some limited tests against XRandR. Nevertheless there are a few things which I was not able to test: * multiple outputs * no output at all The nested X Server approach makes the interaction rather complex. Qt opens it's connection against the main X Server thus QX11Info provides a wrong connection and also KWin::connection() which is heavily used by xcbutils and thus all the RandR wrappers have the wrong connection. To circumvent this problem the test is GUILESS. In case it would call into any code using QX11Info, it would probably either runtime fail or crash. REVIEW: 117614
2014-04-17 15:33:11 +00:00
../xcbutils.cpp # init of extensions
../x11eventfilter.cpp
)
kconfig_add_kcfg_files(testXRandRScreens_SRCS ../settings.kcfgc)
add_executable( testXRandRScreens ${testXRandRScreens_SRCS} )
target_link_libraries( testXRandRScreens
Qt5::Test
Qt5::Gui
KF5::ConfigCore
KF5::ConfigGui
KF5::WindowSystem
XCB::XCB
XCB::RANDR
XCB::XFIXES
XCB::SYNC
XCB::COMPOSITE
XCB::DAMAGE
XCB::GLX
XCB::SHM
)
add_test(kwin-testXRandRScreens testXRandRScreens)
ecm_mark_as_test(testXRandRScreens)
Add an auto-test for ScreenEdges The new test does not cover ScreenEdges completely, so far the following areas are handled: * creating of the edges * reserving of edges * trigger callback * cursor pushback * blocking of edges for fullscreen active clients
2014-09-26 12:01:44 +00:00
########################################################
# Test ScreenEdges
########################################################
set( testScreenEdges_SRCS
test_screen_edges.cpp
[autotests] Adjust to changes regarding AbstractClient We need a Mock for AbstractClient and our mock Client needs to inherit from it.
2015-04-29 12:13:20 +00:00
mock_abstract_client.cpp
Add an auto-test for ScreenEdges The new test does not cover ScreenEdges completely, so far the following areas are handled: * creating of the edges * reserving of edges * trigger callback * cursor pushback * blocking of edges for fullscreen active clients
2014-09-26 12:01:44 +00:00
mock_client.cpp
mock_screens.cpp
mock_workspace.cpp
../atoms.cpp
../screens.cpp
../screenedge.cpp
../virtualdesktops.cpp
[autotest] Add workaround for broken no-XRandr in screen edge test With Qt 5.5 the physicalSize of a screen is broken if the X system does not provide the XRandR extension. This caused our screen edge test to fail on the CI system (Xvfb) due to approach window being based on the dpi. The problem itself is addressed for Qt in: https://codereview.qt-project.org/126808 This change just worksaround till the change has made it into our CI system (at which point the expected fails will break). Reviewed-By: David Edmundson
2015-09-30 13:06:01 +00:00
../xcbutils.cpp # init of extensions
Create screen edge through the Platform Removes a diversion between X11 and Wayland. The base class Platform creates an instance of class Edge with plugin implementations being able to create a different type. The X11StandalonePlugin does that and creates a WindowBasedEdge. For this the implementation of WindowBasedEdge is moved from screenedges into the plugin. Unfortunately an ifdef is needed to make the screenedge test still work as expected. This should be improved in future, e.g. have a good way to load the platform plugin from the tests. Reviewers: #plasma Subscribers: plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1419
2016-04-15 11:47:56 +00:00
../plugins/platforms/x11/standalone/edge.cpp
Add an auto-test for ScreenEdges The new test does not cover ScreenEdges completely, so far the following areas are handled: * creating of the edges * reserving of edges * trigger callback * cursor pushback * blocking of edges for fullscreen active clients
2014-09-26 12:01:44 +00:00
)
kconfig_add_kcfg_files(testScreenEdges_SRCS ../settings.kcfgc)
qt5_add_dbus_interface( testScreenEdges_SRCS ${CMAKE_CURRENT_SOURCE_DIR}/../org.freedesktop.ScreenSaver.xml screenlocker_interface)
add_executable( testScreenEdges ${testScreenEdges_SRCS})
target_include_directories(testScreenEdges BEFORE PRIVATE ./)
target_link_libraries(testScreenEdges
Qt5::DBus
Qt5::Test
Qt5::X11Extras
KF5::ConfigCore
KF5::ConfigGui
KF5::I18n
KF5::GlobalAccel
KF5::WindowSystem
XCB::XCB
[autotest] Add workaround for broken no-XRandr in screen edge test With Qt 5.5 the physicalSize of a screen is broken if the X system does not provide the XRandR extension. This caused our screen edge test to fail on the CI system (Xvfb) due to approach window being based on the dpi. The problem itself is addressed for Qt in: https://codereview.qt-project.org/126808 This change just worksaround till the change has made it into our CI system (at which point the expected fails will break). Reviewed-By: David Edmundson
2015-09-30 13:06:01 +00:00
XCB::RANDR
XCB::XFIXES
XCB::SYNC
XCB::COMPOSITE
XCB::DAMAGE
XCB::GLX
XCB::SHM
Add an auto-test for ScreenEdges The new test does not cover ScreenEdges completely, so far the following areas are handled: * creating of the edges * reserving of edges * trigger callback * cursor pushback * blocking of edges for fullscreen active clients
2014-09-26 12:01:44 +00:00
)
add_test(kwin_testScreenEdges testScreenEdges)
ecm_mark_as_test(testScreenEdges)
Reference in a new issue Copy permalink