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

186 lines
6 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)
[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
if(Wayland_Client_FOUND AND XKB_FOUND)
add_subdirectory(wayland_client)
endif()
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
Stop including KDE4_INCLUDES globally Depend on libraries specifically instead.
2014-03-18 16:53:22 +00:00
KF5::Service
[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
Maybe now Jenkins is happy
2013-05-13 08:19:52 +00:00
${X11_Xcursor_LIB}
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] 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
########################################################
# 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] 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
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
)
add_executable( testScriptedEffectLoader ${testScriptedEffectLoader_SRCS})
target_link_libraries(testScriptedEffectLoader
Qt5::Concurrent
Qt5::Script
Qt5::Test
KF5::ConfigGui
KF5::GlobalAccel
KF5::I18n
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
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)
Reference in a new issue Copy permalink