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

581 lines
34 KiB
C++
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
/********************************************************************
KWin - the KDE window manager
This file is part of the KDE project.
Copyright (C) 2014 Martin Gräßlin <mgraesslin@kde.org>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
*********************************************************************/
#include "../effectloader.h"
#include "../effects/effect_builtins.h"
#include "mock_effectshandler.h"
[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
#include "../scripting/scriptedeffect.h" // for mocking ScriptedEffect::create
[autotests] Add Q_CONSTRUCTOR_FUNCTION to X11 specific tests to force xcb The X11 specific tests need to run on QT_QPA_PLATFORM xcb otherwise they will crash. To enforce this without having to replace QTEST_MAIN a Q_CONSTRUCTOR_FUNCTION is used to invoke a function which does nothing except setting the env variable.
2016-09-08 13:08:45 +00:00
#include "testutils.h"
[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
// KDE
#include <KConfig>
#include <KConfigGroup>
// Qt
Remove Qt module declarations in includes Summary: Test Plan: Compiles Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D13359
2018-06-05 10:52:57 +00:00
#include <QtTest>
[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
#include <QStringList>
[autotests] Make lifespan of EffectsHandler outlive Effect Summary: In loading tests. Effects are deleted in a deleteLater potentially outside the scope of our test. Our MockEffectsHandler (which contains the global static "effects") has the lifespan of the test. Fixes failing unit test. Test Plan: Ran test Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D15167
2018-08-30 11:48:23 +00:00
#include <QScopedPointer>
[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
Q_DECLARE_METATYPE(KWin::CompositingType)
Q_DECLARE_METATYPE(KWin::LoadEffectFlag)
Q_DECLARE_METATYPE(KWin::LoadEffectFlags)
Q_DECLARE_METATYPE(KWin::BuiltInEffect)
Q_DECLARE_METATYPE(KWin::Effect*)
Introduce categorized logging for kwin core Done by Daniel Pastushchak for KDE during GCI-2014.
2014-12-05 10:42:15 +00:00
Q_LOGGING_CATEGORY(KWIN_CORE, "kwin_core")
[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
namespace KWin
{
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
ScriptedEffect *ScriptedEffect::create(const KPluginMetaData&)
[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
{
return nullptr;
}
Introduce an EffectsHandler::animationsSupported -> bool Summary: A new method to tell the effects system whether the compositor scene is able to drive animations. E.g. on software emulation (llvmpipe) it's better to not do any animations at all. This information can be used by effects to adjust their behavior, e.g. PresentWindows could skip transitions or effects can use it in their supported check to completely disable themselves. As a first step all scripted effects are considered to be unsupported if animations are not supported. They inherit AnimationEffect and are all about driving animations. The information whether animations are supported comes from the Scene. It's implemented in the following way: * XRender: animations are always supported * QPainter: animations are never supported * OpenGL: animations are supported, except for software emulation In addition - for easier testing - there is a new env variable KWIN_EFFECTS_FORCE_ANIMATIONS to overwrite the selection. Reviewers: #kwin, #plasma Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D2386
2016-08-10 07:24:53 +00:00
bool ScriptedEffect::supported()
{
return true;
}
[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
}
[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
class TestBuiltInEffectLoader : public QObject
{
Q_OBJECT
private Q_SLOTS:
Provide x11Connection as a property on the KWin::Application KWin::connection() uses the property to resolve the value instead of using QX11Info. In practice this doesn't change anything at the moment, but allows kwin_wayland to provide an xcb connection without depending on QX11Info. As we cannot make xcb_connection_t* available as a metatype, the property's type is set to void*.
2015-02-18 10:19:04 +00:00
void initTestCase();
[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
void testHasEffect_data();
void testHasEffect();
void testKnownEffects();
void testSupported_data();
void testSupported();
void testLoadEffect_data();
void testLoadEffect();
void testLoadBuiltInEffect_data();
void testLoadBuiltInEffect();
void testLoadAllEffects();
};
Provide x11Connection as a property on the KWin::Application KWin::connection() uses the property to resolve the value instead of using QX11Info. In practice this doesn't change anything at the moment, but allows kwin_wayland to provide an xcb connection without depending on QX11Info. As we cannot make xcb_connection_t* available as a metatype, the property's type is set to void*.
2015-02-18 10:19:04 +00:00
void TestBuiltInEffectLoader::initTestCase()
{
qApp->setProperty("x11Connection", QVariant::fromValue<void*>(QX11Info::connection()));
}
[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
void TestBuiltInEffectLoader::testHasEffect_data()
{
QTest::addColumn<QString>("name");
QTest::addColumn<bool>("expected");
QTest::newRow("blur") << QStringLiteral("blur") << true;
Drop "kwin4_effect_" prefix for BuiltIn Effects This removes all the hacks to add kwin4_effect_ to the name of the Effect and adjusts the desktop files of the effect configuration's parent component. Note: the scripted effects still start with kwin4_effect_ prefix. REVIEW: 117367
2014-04-04 09:49:31 +00:00
QTest::newRow("with kwin4_effect_ prefix") << QStringLiteral("kwin4_effect_blur") << false;
[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
QTest::newRow("case sensitive") << QStringLiteral("BlUR") << true;
[effects] Add a colorpicker effect Summary: The effect exports itself to DBus as object "/ColorPicker" and provides an own interface "org.kde.kwin.ColorPicker". It has one exported method to DBus "pick" which returns a QColor. When invoked an interactive position picking selection is started. If it ends the effect reads the color value at the picked position from the OpenGL color buffer. This implements T4568. Reviewers: #kwin, #plasma_on_wayland, broulik Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3480
2016-11-24 07:07:51 +00:00
QTest::newRow("Colorpicker") << QStringLiteral("colorpicker") << true;
[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
QTest::newRow("Contrast") << QStringLiteral("contrast") << true;
QTest::newRow("CoverSwitch") << QStringLiteral("coverswitch") << true;
QTest::newRow("Cube") << QStringLiteral("cube") << true;
QTest::newRow("CubeSlide") << QStringLiteral("cubeslide") << true;
QTest::newRow("DesktopGrid") << QStringLiteral("desktopgrid") << true;
QTest::newRow("DimInactive") << QStringLiteral("diminactive") << true;
QTest::newRow("DimScreen") << QStringLiteral("dimscreen") << true;
QTest::newRow("FallApart") << QStringLiteral("fallapart") << true;
QTest::newRow("FlipSwitch") << QStringLiteral("flipswitch") << true;
QTest::newRow("Glide") << QStringLiteral("glide") << true;
QTest::newRow("HighlightWindow") << QStringLiteral("highlightwindow") << true;
QTest::newRow("Invert") << QStringLiteral("invert") << true;
QTest::newRow("Kscreen") << QStringLiteral("kscreen") << true;
QTest::newRow("LookingGlass") << QStringLiteral("lookingglass") << true;
QTest::newRow("MagicLamp") << QStringLiteral("magiclamp") << true;
QTest::newRow("Magnifier") << QStringLiteral("magnifier") << true;
QTest::newRow("MinimizeAnimation") << QStringLiteral("minimizeanimation") << true;
QTest::newRow("MouseClick") << QStringLiteral("mouseclick") << true;
QTest::newRow("MouseMark") << QStringLiteral("mousemark") << true;
QTest::newRow("PresentWindows") << QStringLiteral("presentwindows") << true;
QTest::newRow("Resize") << QStringLiteral("resize") << true;
[effects] Add Scale effect Summary: The new effect scales windows as they appear and disappear. As the the most of window animation effects, it is a monolithic effect, i.e., if you enable scale effect, it will animate *both* the appearing and disappearing. The main difference between the Scale effect and the Scale in effect is that the Scale in effect only animates windows as they appear. There is no corresponding "the Scale out" effect, which is odd. Other points that differentiate the Scale effect from the Scale in effect: * it is more subtle; * it doesn't animate the log out screen; * it doesn't conflict with the Fade effect, etc. ... and overall, the Scale effect supersedes the Scale in effect. {F5904947} //Window open animation.// {F5904948} //Window close animation.// {F5905283, layout=center, size=full} //KCM.// Test Plan: * Enabled this effect * Opened/closed System Settings Reviewers: #kwin, #plasma, #vdg, davidedmundson Reviewed By: #kwin, #plasma, #vdg, davidedmundson Subscribers: ngraham, davidedmundson, fvogt, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D13461
2018-06-10 11:02:46 +00:00
QTest::newRow("Scale") << QStringLiteral("scale") << true;
[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
QTest::newRow("ScreenEdge") << QStringLiteral("screenedge") << true;
QTest::newRow("ScreenShot") << QStringLiteral("screenshot") << true;
QTest::newRow("Sheet") << QStringLiteral("sheet") << true;
QTest::newRow("ShowFps") << QStringLiteral("showfps") << true;
QTest::newRow("ShowPaint") << QStringLiteral("showpaint") << true;
QTest::newRow("Slide") << QStringLiteral("slide") << true;
QTest::newRow("SlideBack") << QStringLiteral("slideback") << true;
QTest::newRow("SlidingPopups") << QStringLiteral("slidingpopups") << true;
QTest::newRow("SnapHelper") << QStringLiteral("snaphelper") << true;
QTest::newRow("StartupFeedback") << QStringLiteral("startupfeedback") << true;
QTest::newRow("ThumbnailAside") << QStringLiteral("thumbnailaside") << true;
[effects] Add new effect for touch point visualization Summary: The new effect is based on the mouse click effect and uses the same rendering code (this could be improved by merging them better). Unlike mouse click there is no keyboard shortcut needed to activate: as soon as the effect is loaded all touch points are visualized. The visualization creates an animated circle for each touch down position, motion and up position. The ids are tracked and each touch id gets the same color. The first ten different touch ids get a different color. As touch ids are stable the first finger will always have the same color. Reviewers: #kwin, #plasma_on_wayland, bshah Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2464
2016-08-16 18:16:41 +00:00
QTest::newRow("Touchpoints") << QStringLiteral("touchpoints") << true;
[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
QTest::newRow("TrackMouse") << QStringLiteral("trackmouse") << true;
QTest::newRow("WindowGeometry") << QStringLiteral("windowgeometry") << true;
QTest::newRow("WobblyWindows") << QStringLiteral("wobblywindows") << true;
QTest::newRow("Zoom") << QStringLiteral("zoom") << true;
QTest::newRow("Non Existing") << QStringLiteral("InvalidName") << false;
QTest::newRow("Fade - Scripted") << QStringLiteral("fade") << false;
QTest::newRow("Fade - Scripted + kwin4_effect") << QStringLiteral("kwin4_effect_fade") << false;
}
void TestBuiltInEffectLoader::testHasEffect()
{
QFETCH(QString, name);
QFETCH(bool, expected);
KWin::BuiltInEffectLoader loader;
QCOMPARE(loader.hasEffect(name), expected);
}
void TestBuiltInEffectLoader::testKnownEffects()
{
QStringList expectedEffects;
expectedEffects << QStringLiteral("blur")
[effects] Add a colorpicker effect Summary: The effect exports itself to DBus as object "/ColorPicker" and provides an own interface "org.kde.kwin.ColorPicker". It has one exported method to DBus "pick" which returns a QColor. When invoked an interactive position picking selection is started. If it ends the effect reads the color value at the picked position from the OpenGL color buffer. This implements T4568. Reviewers: #kwin, #plasma_on_wayland, broulik Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3480
2016-11-24 07:07:51 +00:00
<< QStringLiteral("colorpicker")
[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
<< QStringLiteral("contrast")
<< QStringLiteral("coverswitch")
<< QStringLiteral("cube")
<< QStringLiteral("cubeslide")
<< QStringLiteral("desktopgrid")
<< QStringLiteral("diminactive")
<< QStringLiteral("dimscreen")
<< QStringLiteral("fallapart")
<< QStringLiteral("flipswitch")
<< QStringLiteral("glide")
<< QStringLiteral("highlightwindow")
<< QStringLiteral("invert")
<< QStringLiteral("kscreen")
<< QStringLiteral("lookingglass")
<< QStringLiteral("magiclamp")
<< QStringLiteral("magnifier")
<< QStringLiteral("minimizeanimation")
<< QStringLiteral("mouseclick")
<< QStringLiteral("mousemark")
<< QStringLiteral("presentwindows")
<< QStringLiteral("resize")
[effects] Add Scale effect Summary: The new effect scales windows as they appear and disappear. As the the most of window animation effects, it is a monolithic effect, i.e., if you enable scale effect, it will animate *both* the appearing and disappearing. The main difference between the Scale effect and the Scale in effect is that the Scale in effect only animates windows as they appear. There is no corresponding "the Scale out" effect, which is odd. Other points that differentiate the Scale effect from the Scale in effect: * it is more subtle; * it doesn't animate the log out screen; * it doesn't conflict with the Fade effect, etc. ... and overall, the Scale effect supersedes the Scale in effect. {F5904947} //Window open animation.// {F5904948} //Window close animation.// {F5905283, layout=center, size=full} //KCM.// Test Plan: * Enabled this effect * Opened/closed System Settings Reviewers: #kwin, #plasma, #vdg, davidedmundson Reviewed By: #kwin, #plasma, #vdg, davidedmundson Subscribers: ngraham, davidedmundson, fvogt, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D13461
2018-06-10 11:02:46 +00:00
<< QStringLiteral("scale")
[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
<< QStringLiteral("screenedge")
<< QStringLiteral("screenshot")
<< QStringLiteral("sheet")
<< QStringLiteral("showfps")
<< QStringLiteral("showpaint")
<< QStringLiteral("slide")
<< QStringLiteral("slideback")
<< QStringLiteral("slidingpopups")
<< QStringLiteral("snaphelper")
<< QStringLiteral("startupfeedback")
<< QStringLiteral("thumbnailaside")
[effects] Add new effect for touch point visualization Summary: The new effect is based on the mouse click effect and uses the same rendering code (this could be improved by merging them better). Unlike mouse click there is no keyboard shortcut needed to activate: as soon as the effect is loaded all touch points are visualized. The visualization creates an animated circle for each touch down position, motion and up position. The ids are tracked and each touch id gets the same color. The first ten different touch ids get a different color. As touch ids are stable the first finger will always have the same color. Reviewers: #kwin, #plasma_on_wayland, bshah Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2464
2016-08-16 18:16:41 +00:00
<< QStringLiteral("touchpoints")
[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
<< QStringLiteral("trackmouse")
<< QStringLiteral("windowgeometry")
<< QStringLiteral("wobblywindows")
<< QStringLiteral("zoom");
KWin::BuiltInEffectLoader loader;
QStringList result = loader.listOfKnownEffects();
QCOMPARE(result.size(), expectedEffects.size());
qSort(result);
for (int i = 0; i < expectedEffects.size(); ++i) {
QCOMPARE(result.at(i), expectedEffects.at(i));
}
}
void TestBuiltInEffectLoader::testSupported_data()
{
QTest::addColumn<QString>("name");
QTest::addColumn<bool>("expected");
QTest::addColumn<KWin::CompositingType>("type");
Introduce an EffectsHandler::animationsSupported -> bool Summary: A new method to tell the effects system whether the compositor scene is able to drive animations. E.g. on software emulation (llvmpipe) it's better to not do any animations at all. This information can be used by effects to adjust their behavior, e.g. PresentWindows could skip transitions or effects can use it in their supported check to completely disable themselves. As a first step all scripted effects are considered to be unsupported if animations are not supported. They inherit AnimationEffect and are all about driving animations. The information whether animations are supported comes from the Scene. It's implemented in the following way: * XRender: animations are always supported * QPainter: animations are never supported * OpenGL: animations are supported, except for software emulation In addition - for easier testing - there is a new env variable KWIN_EFFECTS_FORCE_ANIMATIONS to overwrite the selection. Reviewers: #kwin, #plasma Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D2386
2016-08-10 07:24:53 +00:00
QTest::addColumn<bool>("animationsSupported");
[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
const KWin::CompositingType xc = KWin::XRenderCompositing;
const KWin::CompositingType oc = KWin::OpenGL2Compositing;
Introduce an EffectsHandler::animationsSupported -> bool Summary: A new method to tell the effects system whether the compositor scene is able to drive animations. E.g. on software emulation (llvmpipe) it's better to not do any animations at all. This information can be used by effects to adjust their behavior, e.g. PresentWindows could skip transitions or effects can use it in their supported check to completely disable themselves. As a first step all scripted effects are considered to be unsupported if animations are not supported. They inherit AnimationEffect and are all about driving animations. The information whether animations are supported comes from the Scene. It's implemented in the following way: * XRender: animations are always supported * QPainter: animations are never supported * OpenGL: animations are supported, except for software emulation In addition - for easier testing - there is a new env variable KWIN_EFFECTS_FORCE_ANIMATIONS to overwrite the selection. Reviewers: #kwin, #plasma Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D2386
2016-08-10 07:24:53 +00:00
QTest::newRow("blur") << QStringLiteral("blur") << false << xc << true;
[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
// fails for GL as it does proper tests on what's supported and doesn't just check whether it's GL
Introduce an EffectsHandler::animationsSupported -> bool Summary: A new method to tell the effects system whether the compositor scene is able to drive animations. E.g. on software emulation (llvmpipe) it's better to not do any animations at all. This information can be used by effects to adjust their behavior, e.g. PresentWindows could skip transitions or effects can use it in their supported check to completely disable themselves. As a first step all scripted effects are considered to be unsupported if animations are not supported. They inherit AnimationEffect and are all about driving animations. The information whether animations are supported comes from the Scene. It's implemented in the following way: * XRender: animations are always supported * QPainter: animations are never supported * OpenGL: animations are supported, except for software emulation In addition - for easier testing - there is a new env variable KWIN_EFFECTS_FORCE_ANIMATIONS to overwrite the selection. Reviewers: #kwin, #plasma Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D2386
2016-08-10 07:24:53 +00:00
QTest::newRow("blur-GL") << QStringLiteral("blur") << false << oc << true;
[effects] Add a colorpicker effect Summary: The effect exports itself to DBus as object "/ColorPicker" and provides an own interface "org.kde.kwin.ColorPicker". It has one exported method to DBus "pick" which returns a QColor. When invoked an interactive position picking selection is started. If it ends the effect reads the color value at the picked position from the OpenGL color buffer. This implements T4568. Reviewers: #kwin, #plasma_on_wayland, broulik Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3480
2016-11-24 07:07:51 +00:00
QTest::newRow("Colorpicker") << QStringLiteral("colorpicker") << false << xc << true;
QTest::newRow("Colorpicker-GL") << QStringLiteral("colorpicker") << true << oc << true;
Introduce an EffectsHandler::animationsSupported -> bool Summary: A new method to tell the effects system whether the compositor scene is able to drive animations. E.g. on software emulation (llvmpipe) it's better to not do any animations at all. This information can be used by effects to adjust their behavior, e.g. PresentWindows could skip transitions or effects can use it in their supported check to completely disable themselves. As a first step all scripted effects are considered to be unsupported if animations are not supported. They inherit AnimationEffect and are all about driving animations. The information whether animations are supported comes from the Scene. It's implemented in the following way: * XRender: animations are always supported * QPainter: animations are never supported * OpenGL: animations are supported, except for software emulation In addition - for easier testing - there is a new env variable KWIN_EFFECTS_FORCE_ANIMATIONS to overwrite the selection. Reviewers: #kwin, #plasma Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D2386
2016-08-10 07:24:53 +00:00
QTest::newRow("Contrast") << QStringLiteral("contrast") << false << xc << true;
[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
// fails for GL as it does proper tests on what's supported and doesn't just check whether it's GL
Introduce an EffectsHandler::animationsSupported -> bool Summary: A new method to tell the effects system whether the compositor scene is able to drive animations. E.g. on software emulation (llvmpipe) it's better to not do any animations at all. This information can be used by effects to adjust their behavior, e.g. PresentWindows could skip transitions or effects can use it in their supported check to completely disable themselves. As a first step all scripted effects are considered to be unsupported if animations are not supported. They inherit AnimationEffect and are all about driving animations. The information whether animations are supported comes from the Scene. It's implemented in the following way: * XRender: animations are always supported * QPainter: animations are never supported * OpenGL: animations are supported, except for software emulation In addition - for easier testing - there is a new env variable KWIN_EFFECTS_FORCE_ANIMATIONS to overwrite the selection. Reviewers: #kwin, #plasma Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D2386
2016-08-10 07:24:53 +00:00
QTest::newRow("Contrast-GL") << QStringLiteral("contrast") << false << oc << true;
QTest::newRow("CoverSwitch") << QStringLiteral("coverswitch") << false << xc << true;
QTest::newRow("CoverSwitch-GL") << QStringLiteral("coverswitch") << true << oc << true;
QTest::newRow("CoverSwitch-GL-no-anim") << QStringLiteral("coverswitch") << false << oc << false;
QTest::newRow("Cube") << QStringLiteral("cube") << false << xc << true;
QTest::newRow("Cube-GL") << QStringLiteral("cube") << true << oc << true;
QTest::newRow("CubeSlide") << QStringLiteral("cubeslide") << false << xc << true;
QTest::newRow("CubeSlide-GL") << QStringLiteral("cubeslide") << true << oc << true;
QTest::newRow("CubeSlide-GL-no-anim") << QStringLiteral("cubeslide") << false << oc << false;
QTest::newRow("DesktopGrid") << QStringLiteral("desktopgrid") << true << xc << true;
QTest::newRow("DimInactive") << QStringLiteral("diminactive") << true << xc << true;
QTest::newRow("DimScreen") << QStringLiteral("dimscreen") << true << xc << true;
QTest::newRow("FallApart") << QStringLiteral("fallapart") << false << xc << true;
QTest::newRow("FallApart-GL") << QStringLiteral("fallapart") << true << oc << true;
QTest::newRow("FlipSwitch") << QStringLiteral("flipswitch") << false << xc << true;
QTest::newRow("FlipSwitch-GL") << QStringLiteral("flipswitch") << true << oc << true;
QTest::newRow("FlipSwitch-GL-no-anim") << QStringLiteral("flipswitch") << false << oc << false;
QTest::newRow("Glide") << QStringLiteral("glide") << false << xc << true;
QTest::newRow("Glide-GL") << QStringLiteral("glide") << true << oc << true;
QTest::newRow("Glide-GL-no-anim") << QStringLiteral("glide") << false << oc << false;
QTest::newRow("HighlightWindow") << QStringLiteral("highlightwindow") << true << xc << true;
QTest::newRow("Invert") << QStringLiteral("invert") << false << xc << true;
QTest::newRow("Invert-GL") << QStringLiteral("invert") << true << oc << true;
QTest::newRow("Kscreen") << QStringLiteral("kscreen") << true << xc << true;
QTest::newRow("LookingGlass") << QStringLiteral("lookingglass") << false << xc << true;
QTest::newRow("LookingGlass-GL") << QStringLiteral("lookingglass") << true << oc << true;
QTest::newRow("MagicLamp") << QStringLiteral("magiclamp") << false << xc << true;
QTest::newRow("MagicLamp-GL") << QStringLiteral("magiclamp") << true << oc << true;
QTest::newRow("MagicLamp-GL-no-anim") << QStringLiteral("magiclamp") << false << oc << false;
QTest::newRow("Magnifier") << QStringLiteral("magnifier") << true << xc << true;
QTest::newRow("MinimizeAnimation") << QStringLiteral("minimizeanimation") << true << xc << true;
QTest::newRow("MouseClick") << QStringLiteral("mouseclick") << true << xc << true;
QTest::newRow("MouseMark") << QStringLiteral("mousemark") << true << xc << true;
QTest::newRow("PresentWindows") << QStringLiteral("presentwindows") << true << xc << true;
QTest::newRow("Resize") << QStringLiteral("resize") << true << xc << true;
[effects] Add Scale effect Summary: The new effect scales windows as they appear and disappear. As the the most of window animation effects, it is a monolithic effect, i.e., if you enable scale effect, it will animate *both* the appearing and disappearing. The main difference between the Scale effect and the Scale in effect is that the Scale in effect only animates windows as they appear. There is no corresponding "the Scale out" effect, which is odd. Other points that differentiate the Scale effect from the Scale in effect: * it is more subtle; * it doesn't animate the log out screen; * it doesn't conflict with the Fade effect, etc. ... and overall, the Scale effect supersedes the Scale in effect. {F5904947} //Window open animation.// {F5904948} //Window close animation.// {F5905283, layout=center, size=full} //KCM.// Test Plan: * Enabled this effect * Opened/closed System Settings Reviewers: #kwin, #plasma, #vdg, davidedmundson Reviewed By: #kwin, #plasma, #vdg, davidedmundson Subscribers: ngraham, davidedmundson, fvogt, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D13461
2018-06-10 11:02:46 +00:00
QTest::newRow("Scale") << QStringLiteral("scale") << true << xc << true;
Introduce an EffectsHandler::animationsSupported -> bool Summary: A new method to tell the effects system whether the compositor scene is able to drive animations. E.g. on software emulation (llvmpipe) it's better to not do any animations at all. This information can be used by effects to adjust their behavior, e.g. PresentWindows could skip transitions or effects can use it in their supported check to completely disable themselves. As a first step all scripted effects are considered to be unsupported if animations are not supported. They inherit AnimationEffect and are all about driving animations. The information whether animations are supported comes from the Scene. It's implemented in the following way: * XRender: animations are always supported * QPainter: animations are never supported * OpenGL: animations are supported, except for software emulation In addition - for easier testing - there is a new env variable KWIN_EFFECTS_FORCE_ANIMATIONS to overwrite the selection. Reviewers: #kwin, #plasma Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D2386
2016-08-10 07:24:53 +00:00
QTest::newRow("ScreenEdge") << QStringLiteral("screenedge") << true << xc << true;
QTest::newRow("ScreenShot") << QStringLiteral("screenshot") << true << xc << true;
QTest::newRow("Sheet") << QStringLiteral("sheet") << false << xc << true;
QTest::newRow("Sheet-GL") << QStringLiteral("sheet") << true << oc << true;
QTest::newRow("Sheet-GL-no-anim") << QStringLiteral("sheet") << false << oc << false;
QTest::newRow("ShowFps") << QStringLiteral("showfps") << true << xc << true;
QTest::newRow("ShowPaint") << QStringLiteral("showpaint") << true << xc << true;
QTest::newRow("Slide") << QStringLiteral("slide") << true << xc << true;
QTest::newRow("SlideBack") << QStringLiteral("slideback") << true << xc << true;
QTest::newRow("SlidingPopups") << QStringLiteral("slidingpopups") << true << xc << true;
QTest::newRow("SnapHelper") << QStringLiteral("snaphelper") << true << xc << true;
QTest::newRow("StartupFeedback") << QStringLiteral("startupfeedback") << false << xc << true;
QTest::newRow("StartupFeedback-GL") << QStringLiteral("startupfeedback") << true << oc << true;
QTest::newRow("ThumbnailAside") << QStringLiteral("thumbnailaside") << true << xc << true;
[effects] Add new effect for touch point visualization Summary: The new effect is based on the mouse click effect and uses the same rendering code (this could be improved by merging them better). Unlike mouse click there is no keyboard shortcut needed to activate: as soon as the effect is loaded all touch points are visualized. The visualization creates an animated circle for each touch down position, motion and up position. The ids are tracked and each touch id gets the same color. The first ten different touch ids get a different color. As touch ids are stable the first finger will always have the same color. Reviewers: #kwin, #plasma_on_wayland, bshah Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2464
2016-08-16 18:16:41 +00:00
QTest::newRow("TouchPoints") << QStringLiteral("touchpoints") << true << xc << true;
Introduce an EffectsHandler::animationsSupported -> bool Summary: A new method to tell the effects system whether the compositor scene is able to drive animations. E.g. on software emulation (llvmpipe) it's better to not do any animations at all. This information can be used by effects to adjust their behavior, e.g. PresentWindows could skip transitions or effects can use it in their supported check to completely disable themselves. As a first step all scripted effects are considered to be unsupported if animations are not supported. They inherit AnimationEffect and are all about driving animations. The information whether animations are supported comes from the Scene. It's implemented in the following way: * XRender: animations are always supported * QPainter: animations are never supported * OpenGL: animations are supported, except for software emulation In addition - for easier testing - there is a new env variable KWIN_EFFECTS_FORCE_ANIMATIONS to overwrite the selection. Reviewers: #kwin, #plasma Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D2386
2016-08-10 07:24:53 +00:00
QTest::newRow("TrackMouse") << QStringLiteral("trackmouse") << true << xc << true;
QTest::newRow("WindowGeometry") << QStringLiteral("windowgeometry") << true << xc << true;
QTest::newRow("WobblyWindows") << QStringLiteral("wobblywindows") << false << xc << true;
QTest::newRow("WobblyWindows-GL") << QStringLiteral("wobblywindows") << true << oc << true;
QTest::newRow("WobblyWindows-GL-no-anim") << QStringLiteral("wobblywindows") << false << oc << false;
QTest::newRow("Zoom") << QStringLiteral("zoom") << true << xc << true;
QTest::newRow("Non Existing") << QStringLiteral("InvalidName") << false << xc << true;
QTest::newRow("Fade - Scripted") << QStringLiteral("fade") << false << xc << true;
QTest::newRow("Fade - Scripted + kwin4_effect") << QStringLiteral("kwin4_effect_fade") << false << xc << true;
[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
}
void TestBuiltInEffectLoader::testSupported()
{
QFETCH(QString, name);
QFETCH(bool, expected);
QFETCH(KWin::CompositingType, type);
Introduce an EffectsHandler::animationsSupported -> bool Summary: A new method to tell the effects system whether the compositor scene is able to drive animations. E.g. on software emulation (llvmpipe) it's better to not do any animations at all. This information can be used by effects to adjust their behavior, e.g. PresentWindows could skip transitions or effects can use it in their supported check to completely disable themselves. As a first step all scripted effects are considered to be unsupported if animations are not supported. They inherit AnimationEffect and are all about driving animations. The information whether animations are supported comes from the Scene. It's implemented in the following way: * XRender: animations are always supported * QPainter: animations are never supported * OpenGL: animations are supported, except for software emulation In addition - for easier testing - there is a new env variable KWIN_EFFECTS_FORCE_ANIMATIONS to overwrite the selection. Reviewers: #kwin, #plasma Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D2386
2016-08-10 07:24:53 +00:00
QFETCH(bool, animationsSupported);
[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
MockEffectsHandler mockHandler(type);
Introduce an EffectsHandler::animationsSupported -> bool Summary: A new method to tell the effects system whether the compositor scene is able to drive animations. E.g. on software emulation (llvmpipe) it's better to not do any animations at all. This information can be used by effects to adjust their behavior, e.g. PresentWindows could skip transitions or effects can use it in their supported check to completely disable themselves. As a first step all scripted effects are considered to be unsupported if animations are not supported. They inherit AnimationEffect and are all about driving animations. The information whether animations are supported comes from the Scene. It's implemented in the following way: * XRender: animations are always supported * QPainter: animations are never supported * OpenGL: animations are supported, except for software emulation In addition - for easier testing - there is a new env variable KWIN_EFFECTS_FORCE_ANIMATIONS to overwrite the selection. Reviewers: #kwin, #plasma Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D2386
2016-08-10 07:24:53 +00:00
mockHandler.setAnimationsSupported(animationsSupported);
QCOMPARE(mockHandler.animationsSupported(), animationsSupported);
[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
KWin::BuiltInEffectLoader loader;
QCOMPARE(loader.isEffectSupported(name), expected);
}
void TestBuiltInEffectLoader::testLoadEffect_data()
{
QTest::addColumn<QString>("name");
QTest::addColumn<bool>("expected");
QTest::addColumn<KWin::CompositingType>("type");
const KWin::CompositingType xc = KWin::XRenderCompositing;
const KWin::CompositingType oc = KWin::OpenGL2Compositing;
QTest::newRow("blur") << QStringLiteral("blur") << false << xc;
// fails for GL as it does proper tests on what's supported and doesn't just check whether it's GL
QTest::newRow("blur-GL") << QStringLiteral("blur") << false << oc;
[effects] Add a colorpicker effect Summary: The effect exports itself to DBus as object "/ColorPicker" and provides an own interface "org.kde.kwin.ColorPicker". It has one exported method to DBus "pick" which returns a QColor. When invoked an interactive position picking selection is started. If it ends the effect reads the color value at the picked position from the OpenGL color buffer. This implements T4568. Reviewers: #kwin, #plasma_on_wayland, broulik Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3480
2016-11-24 07:07:51 +00:00
QTest::newRow("Colorpicker") << QStringLiteral("colorpicker") << false << xc;
QTest::newRow("Colorpicker-GL") << QStringLiteral("colorpicker") << true << oc;
[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
QTest::newRow("Contrast") << QStringLiteral("contrast") << false << xc;
// fails for GL as it does proper tests on what's supported and doesn't just check whether it's GL
QTest::newRow("Contrast-GL") << QStringLiteral("contrast") << false << oc;
QTest::newRow("CoverSwitch") << QStringLiteral("coverswitch") << false << xc;
// TODO: needs GL mocking
// QTest::newRow("CoverSwitch-GL") << QStringLiteral("coverswitch") << true << oc;
QTest::newRow("Cube") << QStringLiteral("cube") << false << xc;
// TODO: needs GL mocking
// QTest::newRow("Cube-GL") << QStringLiteral("cube") << true << oc;
QTest::newRow("CubeSlide") << QStringLiteral("cubeslide") << false << xc;
QTest::newRow("CubeSlide-GL") << QStringLiteral("cubeslide") << true << oc;
QTest::newRow("DesktopGrid") << QStringLiteral("desktopgrid") << true << xc;
QTest::newRow("DimInactive") << QStringLiteral("diminactive") << true << xc;
QTest::newRow("DimScreen") << QStringLiteral("dimScreen") << true << xc;
QTest::newRow("FallApart") << QStringLiteral("fallapart") << false << xc;
QTest::newRow("FallApart-GL") << QStringLiteral("fallapart") << true << oc;
QTest::newRow("FlipSwitch") << QStringLiteral("flipswitch") << false << xc;
QTest::newRow("FlipSwitch-GL") << QStringLiteral("flipswitch") << true << oc;
QTest::newRow("Glide") << QStringLiteral("glide") << false << xc;
QTest::newRow("Glide-GL") << QStringLiteral("glide") << true << oc;
QTest::newRow("HighlightWindow") << QStringLiteral("highlightwindow") << true << xc;
QTest::newRow("Invert") << QStringLiteral("invert") << false << xc;
QTest::newRow("Invert-GL") << QStringLiteral("invert") << true << oc;
QTest::newRow("Kscreen") << QStringLiteral("kscreen") << true << xc;
QTest::newRow("LookingGlass") << QStringLiteral("lookingglass") << false << xc;
QTest::newRow("LookingGlass-GL") << QStringLiteral("lookingglass") << true << oc;
QTest::newRow("MagicLamp") << QStringLiteral("magiclamp") << false << xc;
QTest::newRow("MagicLamp-GL") << QStringLiteral("magiclamp") << true << oc;
QTest::newRow("Magnifier") << QStringLiteral("magnifier") << true << xc;
QTest::newRow("MinimizeAnimation") << QStringLiteral("minimizeanimation") << true << xc;
QTest::newRow("MouseClick") << QStringLiteral("mouseclick") << true << xc;
QTest::newRow("MouseMark") << QStringLiteral("mousemark") << true << xc;
QTest::newRow("PresentWindows") << QStringLiteral("presentwindows") << true << xc;
QTest::newRow("Resize") << QStringLiteral("resize") << true << xc;
[effects] Add Scale effect Summary: The new effect scales windows as they appear and disappear. As the the most of window animation effects, it is a monolithic effect, i.e., if you enable scale effect, it will animate *both* the appearing and disappearing. The main difference between the Scale effect and the Scale in effect is that the Scale in effect only animates windows as they appear. There is no corresponding "the Scale out" effect, which is odd. Other points that differentiate the Scale effect from the Scale in effect: * it is more subtle; * it doesn't animate the log out screen; * it doesn't conflict with the Fade effect, etc. ... and overall, the Scale effect supersedes the Scale in effect. {F5904947} //Window open animation.// {F5904948} //Window close animation.// {F5905283, layout=center, size=full} //KCM.// Test Plan: * Enabled this effect * Opened/closed System Settings Reviewers: #kwin, #plasma, #vdg, davidedmundson Reviewed By: #kwin, #plasma, #vdg, davidedmundson Subscribers: ngraham, davidedmundson, fvogt, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D13461
2018-06-10 11:02:46 +00:00
QTest::newRow("Scale") << QStringLiteral("scale") << true << xc;
[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
QTest::newRow("ScreenEdge") << QStringLiteral("screenedge") << true << xc;
QTest::newRow("ScreenShot") << QStringLiteral("screenshot") << true << xc;
QTest::newRow("Sheet") << QStringLiteral("sheet") << false << xc;
QTest::newRow("Sheet-GL") << QStringLiteral("sheet") << true << oc;
// TODO: Accesses EffectFrame and crashes
// QTest::newRow("ShowFps") << QStringLiteral("showfps") << true << xc;
QTest::newRow("ShowPaint") << QStringLiteral("showpaint") << true << xc;
QTest::newRow("Slide") << QStringLiteral("slide") << true << xc;
QTest::newRow("SlideBack") << QStringLiteral("slideback") << true << xc;
QTest::newRow("SlidingPopups") << QStringLiteral("slidingpopups") << true << xc;
QTest::newRow("SnapHelper") << QStringLiteral("snaphelper") << true << xc;
QTest::newRow("StartupFeedback") << QStringLiteral("startupfeedback") << false << xc;
[autotests] Don't try to load StartupFeedbackEffect on GL compositor The test terminated cleanly as it tried to load a shader which obviously fails.
2016-08-12 06:24:43 +00:00
// Tries to load shader and makes our test abort
// QTest::newRow("StartupFeedback-GL") << QStringLiteral("startupfeedback") << true << oc;
[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
QTest::newRow("ThumbnailAside") << QStringLiteral("thumbnailaside") << true << xc;
[effects] Add new effect for touch point visualization Summary: The new effect is based on the mouse click effect and uses the same rendering code (this could be improved by merging them better). Unlike mouse click there is no keyboard shortcut needed to activate: as soon as the effect is loaded all touch points are visualized. The visualization creates an animated circle for each touch down position, motion and up position. The ids are tracked and each touch id gets the same color. The first ten different touch ids get a different color. As touch ids are stable the first finger will always have the same color. Reviewers: #kwin, #plasma_on_wayland, bshah Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2464
2016-08-16 18:16:41 +00:00
QTest::newRow("Touchpoints") << QStringLiteral("touchpoints") << true << xc;
[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
QTest::newRow("TrackMouse") << QStringLiteral("trackmouse") << true << xc;
// TODO: Accesses EffectFrame and crashes
// QTest::newRow("WindowGeometry") << QStringLiteral("windowgeometry") << true << xc;
QTest::newRow("WobblyWindows") << QStringLiteral("wobblywindows") << false << xc;
QTest::newRow("WobblyWindows-GL") << QStringLiteral("wobblywindows") << true << oc;
Drop "kwin4_effect_" prefix for BuiltIn Effects This removes all the hacks to add kwin4_effect_ to the name of the Effect and adjusts the desktop files of the effect configuration's parent component. Note: the scripted effects still start with kwin4_effect_ prefix. REVIEW: 117367
2014-04-04 09:49:31 +00:00
QTest::newRow("Zoom") << QStringLiteral("zoom") << true << xc;
[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
QTest::newRow("Non Existing") << QStringLiteral("InvalidName") << false << xc;
QTest::newRow("Fade - Scripted") << QStringLiteral("fade") << false << xc;
QTest::newRow("Fade - Scripted + kwin4_effect") << QStringLiteral("kwin4_effect_fade") << false << xc;
}
void TestBuiltInEffectLoader::testLoadEffect()
{
QFETCH(QString, name);
QFETCH(bool, expected);
QFETCH(KWin::CompositingType, type);
[autotests] Make lifespan of EffectsHandler outlive Effect Summary: In loading tests. Effects are deleted in a deleteLater potentially outside the scope of our test. Our MockEffectsHandler (which contains the global static "effects") has the lifespan of the test. Fixes failing unit test. Test Plan: Ran test Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D15167
2018-08-30 11:48:23 +00:00
QScopedPointer<MockEffectsHandler, QScopedPointerDeleteLater> mockHandler(new MockEffectsHandler(type));
[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
KWin::BuiltInEffectLoader loader;
KSharedConfig::Ptr config = KSharedConfig::openConfig(QString(), KConfig::SimpleConfig);
loader.setConfig(config);
qRegisterMetaType<KWin::Effect*>();
QSignalSpy spy(&loader, SIGNAL(effectLoaded(KWin::Effect*,QString)));
// connect to signal to ensure that we delete the Effect again as the Effect doesn't have a parent
connect(&loader, &KWin::BuiltInEffectLoader::effectLoaded,
[&name](KWin::Effect *effect, const QString &effectName) {
QCOMPARE(effectName, name);
effect->deleteLater();
}
);
// try to load the Effect
QCOMPARE(loader.loadEffect(name), expected);
// loading again should fail
QVERIFY(!loader.loadEffect(name));
// signal spy should have got the signal if it was expected
QCOMPARE(spy.isEmpty(), !expected);
if (!spy.isEmpty()) {
QCOMPARE(spy.count(), 1);
// if we caught a signal it should have the effect name we passed in
QList<QVariant> arguments = spy.takeFirst();
QCOMPARE(arguments.count(), 2);
QCOMPARE(arguments.at(1).toString(), name);
}
spy.clear();
QVERIFY(spy.isEmpty());
// now if we wait for the events being processed, the effect will get deleted and it should load again
QTest::qWait(1);
QCOMPARE(loader.loadEffect(name), expected);
// signal spy should have got the signal if it was expected
QCOMPARE(spy.isEmpty(), !expected);
if (!spy.isEmpty()) {
QCOMPARE(spy.count(), 1);
// if we caught a signal it should have the effect name we passed in
QList<QVariant> arguments = spy.takeFirst();
QCOMPARE(arguments.count(), 2);
QCOMPARE(arguments.at(1).toString(), name);
}
}
void TestBuiltInEffectLoader::testLoadBuiltInEffect_data()
{
// TODO: this test cannot yet test the checkEnabledByDefault functionality as that requires
// mocking enough of GL to get the blur effect to think it's supported and enabled by default
QTest::addColumn<KWin::BuiltInEffect>("effect");
QTest::addColumn<QString>("name");
QTest::addColumn<bool>("expected");
QTest::addColumn<KWin::CompositingType>("type");
QTest::addColumn<KWin::LoadEffectFlags>("loadFlags");
const KWin::CompositingType xc = KWin::XRenderCompositing;
const KWin::CompositingType oc = KWin::OpenGL2Compositing;
const KWin::LoadEffectFlags checkDefault = KWin::LoadEffectFlag::Load | KWin::LoadEffectFlag::CheckDefaultFunction;
const KWin::LoadEffectFlags forceFlags = KWin::LoadEffectFlag::Load;
const KWin::LoadEffectFlags dontLoadFlags = KWin::LoadEffectFlags();
// enabled by default, but not supported
QTest::newRow("blur") << KWin::BuiltInEffect::Blur << QStringLiteral("blur") << false << oc << checkDefault;
// enabled by default
QTest::newRow("HighlightWindow") << KWin::BuiltInEffect::HighlightWindow << QStringLiteral("highlightwindow") << true << xc << checkDefault;
// supported but not enabled by default
QTest::newRow("LookingGlass-GL") << KWin::BuiltInEffect::LookingGlass << QStringLiteral("lookingglass") << true << oc << checkDefault;
// not enabled by default
QTest::newRow("MouseClick") << KWin::BuiltInEffect::MouseClick << QStringLiteral("mouseclick") << true << xc << checkDefault;
// Force an Effect which will load
QTest::newRow("MouseClick-Force") << KWin::BuiltInEffect::MouseClick << QStringLiteral("mouseclick") << true << xc << forceFlags;
// Force an Effect which is not supported
QTest::newRow("LookingGlass-Force") << KWin::BuiltInEffect::LookingGlass << QStringLiteral("lookingglass") << false << xc << forceFlags;
// Force the Effect as supported
QTest::newRow("LookingGlass-Force-GL") << KWin::BuiltInEffect::LookingGlass << QStringLiteral("lookingglass") << true << oc << forceFlags;
// Enforce no load of effect which is enabled by default
QTest::newRow("HighlightWindow-DontLoad") << KWin::BuiltInEffect::HighlightWindow << QStringLiteral("highlightwindow") << false << xc << dontLoadFlags;
// Enforce no load of effect which is not enabled by default, but enforced
QTest::newRow("MouseClick-DontLoad") << KWin::BuiltInEffect::MouseClick << QStringLiteral("mouseclick") << false << xc << dontLoadFlags;
}
void TestBuiltInEffectLoader::testLoadBuiltInEffect()
{
QFETCH(KWin::BuiltInEffect, effect);
QFETCH(QString, name);
QFETCH(bool, expected);
QFETCH(KWin::CompositingType, type);
QFETCH(KWin::LoadEffectFlags, loadFlags);
[autotests] Make lifespan of EffectsHandler outlive Effect Summary: In loading tests. Effects are deleted in a deleteLater potentially outside the scope of our test. Our MockEffectsHandler (which contains the global static "effects") has the lifespan of the test. Fixes failing unit test. Test Plan: Ran test Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D15167
2018-08-30 11:48:23 +00:00
QScopedPointer<MockEffectsHandler, QScopedPointerDeleteLater> mockHandler(new MockEffectsHandler(type));
[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
KWin::BuiltInEffectLoader loader;
KSharedConfig::Ptr config = KSharedConfig::openConfig(QString(), KConfig::SimpleConfig);
loader.setConfig(config);
qRegisterMetaType<KWin::Effect*>();
QSignalSpy spy(&loader, SIGNAL(effectLoaded(KWin::Effect*,QString)));
// connect to signal to ensure that we delete the Effect again as the Effect doesn't have a parent
connect(&loader, &KWin::BuiltInEffectLoader::effectLoaded,
[&name](KWin::Effect *effect, const QString &effectName) {
QCOMPARE(effectName, name);
effect->deleteLater();
}
);
// try to load the Effect
QCOMPARE(loader.loadEffect(effect, loadFlags), expected);
// loading again should fail
QVERIFY(!loader.loadEffect(effect, loadFlags));
// signal spy should have got the signal if it was expected
QCOMPARE(spy.isEmpty(), !expected);
if (!spy.isEmpty()) {
QCOMPARE(spy.count(), 1);
// if we caught a signal it should have the effect name we passed in
QList<QVariant> arguments = spy.takeFirst();
QCOMPARE(arguments.count(), 2);
QCOMPARE(arguments.at(1).toString(), name);
}
spy.clear();
QVERIFY(spy.isEmpty());
// now if we wait for the events being processed, the effect will get deleted and it should load again
QTest::qWait(1);
QCOMPARE(loader.loadEffect(effect, loadFlags), expected);
// signal spy should have got the signal if it was expected
QCOMPARE(spy.isEmpty(), !expected);
if (!spy.isEmpty()) {
QCOMPARE(spy.count(), 1);
// if we caught a signal it should have the effect name we passed in
QList<QVariant> arguments = spy.takeFirst();
QCOMPARE(arguments.count(), 2);
QCOMPARE(arguments.at(1).toString(), name);
}
}
void TestBuiltInEffectLoader::testLoadAllEffects()
{
[autotests] Make lifespan of EffectsHandler outlive Effect Summary: In loading tests. Effects are deleted in a deleteLater potentially outside the scope of our test. Our MockEffectsHandler (which contains the global static "effects") has the lifespan of the test. Fixes failing unit test. Test Plan: Ran test Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D15167
2018-08-30 11:48:23 +00:00
QScopedPointer<MockEffectsHandler, QScopedPointerDeleteLater>mockHandler(new MockEffectsHandler(KWin::XRenderCompositing));
[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
KWin::BuiltInEffectLoader loader;
KSharedConfig::Ptr config = KSharedConfig::openConfig(QString(), KConfig::SimpleConfig);
// prepare the configuration to hard enable/disable the effects we want to load
KConfigGroup plugins = config->group("Plugins");
Drop "kwin4_effect_" prefix for BuiltIn Effects This removes all the hacks to add kwin4_effect_ to the name of the Effect and adjusts the desktop files of the effect configuration's parent component. Note: the scripted effects still start with kwin4_effect_ prefix. REVIEW: 117367
2014-04-04 09:49:31 +00:00
plugins.writeEntry(QStringLiteral("desktopgridEnabled"), false);
plugins.writeEntry(QStringLiteral("highlightwindowEnabled"), false);
plugins.writeEntry(QStringLiteral("kscreenEnabled"), false);
plugins.writeEntry(QStringLiteral("minimizeanimationEnabled"), false);
plugins.writeEntry(QStringLiteral("presentwindowsEnabled"), false);
plugins.writeEntry(QStringLiteral("screenedgeEnabled"), false);
plugins.writeEntry(QStringLiteral("screenshotEnabled"), false);
plugins.writeEntry(QStringLiteral("slideEnabled"), false);
plugins.writeEntry(QStringLiteral("slidingpopupsEnabled"), false);
plugins.writeEntry(QStringLiteral("startupfeedbackEnabled"), false);
plugins.writeEntry(QStringLiteral("zoomEnabled"), false);
[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
// enable lookingglass as it's not supported
Drop "kwin4_effect_" prefix for BuiltIn Effects This removes all the hacks to add kwin4_effect_ to the name of the Effect and adjusts the desktop files of the effect configuration's parent component. Note: the scripted effects still start with kwin4_effect_ prefix. REVIEW: 117367
2014-04-04 09:49:31 +00:00
plugins.writeEntry(QStringLiteral("lookingglassEnabled"), true);
[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
plugins.sync();
loader.setConfig(config);
qRegisterMetaType<KWin::Effect*>();
QSignalSpy spy(&loader, SIGNAL(effectLoaded(KWin::Effect*,QString)));
// connect to signal to ensure that we delete the Effect again as the Effect doesn't have a parent
connect(&loader, &KWin::BuiltInEffectLoader::effectLoaded,
[](KWin::Effect *effect) {
effect->deleteLater();
}
);
// the config is prepared so that no Effect gets loaded!
loader.queryAndLoadAll();
// we need to wait some time because it's queued
QVERIFY(!spy.wait(10));
// now let's prepare a config which has one effect explicitly enabled
Drop "kwin4_effect_" prefix for BuiltIn Effects This removes all the hacks to add kwin4_effect_ to the name of the Effect and adjusts the desktop files of the effect configuration's parent component. Note: the scripted effects still start with kwin4_effect_ prefix. REVIEW: 117367
2014-04-04 09:49:31 +00:00
plugins.writeEntry(QStringLiteral("mouseclickEnabled"), true);
[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
plugins.sync();
loader.queryAndLoadAll();
// should load one effect in first go
QVERIFY(spy.wait(10));
// and afterwards it should not load another one
QVERIFY(!spy.wait(10));
QCOMPARE(spy.size(), 1);
// if we caught a signal it should have the effect name we passed in
QList<QVariant> arguments = spy.takeFirst();
QCOMPARE(arguments.count(), 2);
QCOMPARE(arguments.at(1).toString(), QStringLiteral("mouseclick"));
spy.clear();
// let's delete one of the default entries
Drop "kwin4_effect_" prefix for BuiltIn Effects This removes all the hacks to add kwin4_effect_ to the name of the Effect and adjusts the desktop files of the effect configuration's parent component. Note: the scripted effects still start with kwin4_effect_ prefix. REVIEW: 117367
2014-04-04 09:49:31 +00:00
plugins.deleteEntry(QStringLiteral("kscreenEnabled"));
[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
plugins.sync();
QVERIFY(spy.isEmpty());
loader.queryAndLoadAll();
// let's use qWait as we need to wait for two signals to be emitted
QTest::qWait(100);
QCOMPARE(spy.size(), 2);
QStringList loadedEffects;
for (auto &list : spy) {
QCOMPARE(list.size(), 2);
loadedEffects << list.at(1).toString();
}
qSort(loadedEffects);
QCOMPARE(loadedEffects.at(0), QStringLiteral("kscreen"));
QCOMPARE(loadedEffects.at(1), QStringLiteral("mouseclick"));
}
[autotests] Add Q_CONSTRUCTOR_FUNCTION to X11 specific tests to force xcb The X11 specific tests need to run on QT_QPA_PLATFORM xcb otherwise they will crash. To enforce this without having to replace QTEST_MAIN a Q_CONSTRUCTOR_FUNCTION is used to invoke a function which does nothing except setting the env variable.
2016-09-08 13:08:45 +00:00
Q_CONSTRUCTOR_FUNCTION(forceXcb)
[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
QTEST_MAIN(TestBuiltInEffectLoader)
#include "test_builtin_effectloader.moc"
Reference in a new issue Copy permalink