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

808 lines
26 KiB
C++
Raw Normal View History

Turn built-in effects into a library kwin links against As all effects have always been compiled into the same .so file it's questionable whether resolving the effects through a library is useful at all. By linking against the built-in effects we gain the following advantages: * don't have to load/unload the KLibrary * don't have to resolve the create, supported and enabled functions * no version check required * no dependency resolving (effects don't use it) * remove the KWIN_EFFECT macros from the effects All the effects are now registered in an effects_builtins file which maps the name to a factory method and supported or enabled by default methods. During loading the effects we first check whether there is a built-in effect by the given name and make a shortcut to create it through that. If that's not possible the normal plugin loading is used. Completely unscientific testing [1] showed an improvement of almost 10 msec during loading all the effects I use. [1] QElapsedTimer around the loading code, start kwin five times, take average. REVIEW: 115073
2014-01-17 12:46:04 +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 "effect_builtins.h"
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Turn built-in effects into a library kwin links against As all effects have always been compiled into the same .so file it's questionable whether resolving the effects through a library is useful at all. By linking against the built-in effects we gain the following advantages: * don't have to load/unload the KLibrary * don't have to resolve the create, supported and enabled functions * no version check required * no dependency resolving (effects don't use it) * remove the KWIN_EFFECT macros from the effects All the effects are now registered in an effects_builtins file which maps the name to a factory method and supported or enabled by default methods. During loading the effects we first check whether there is a built-in effect by the given name and make a shortcut to create it through that. If that's not possible the normal plugin loading is used. Completely unscientific testing [1] showed an improvement of almost 10 msec during loading all the effects I use. [1] QElapsedTimer around the loading code, start kwin five times, take average. REVIEW: 115073
2014-01-17 12:46:04 +00:00
// common effects
#include "backgroundcontrast/contrast.h"
#include "blur/blur.h"
[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
#include "colorpicker/colorpicker.h"
Turn built-in effects into a library kwin links against As all effects have always been compiled into the same .so file it's questionable whether resolving the effects through a library is useful at all. By linking against the built-in effects we gain the following advantages: * don't have to load/unload the KLibrary * don't have to resolve the create, supported and enabled functions * no version check required * no dependency resolving (effects don't use it) * remove the KWIN_EFFECT macros from the effects All the effects are now registered in an effects_builtins file which maps the name to a factory method and supported or enabled by default methods. During loading the effects we first check whether there is a built-in effect by the given name and make a shortcut to create it through that. If that's not possible the normal plugin loading is used. Completely unscientific testing [1] showed an improvement of almost 10 msec during loading all the effects I use. [1] QElapsedTimer around the loading code, start kwin five times, take average. REVIEW: 115073
2014-01-17 12:46:04 +00:00
#include "kscreen/kscreen.h"
#include "presentwindows/presentwindows.h"
#include "screenedge/screenedgeeffect.h"
#include "screenshot/screenshot.h"
#include "slidingpopups/slidingpopups.h"
// Common effects only relevant to desktop
#include "desktopgrid/desktopgrid.h"
#include "diminactive/diminactive.h"
#include "dimscreen/dimscreen.h"
#include "fallapart/fallapart.h"
#include "highlightwindow/highlightwindow.h"
#include "magiclamp/magiclamp.h"
#include "minimizeanimation/minimizeanimation.h"
#include "resize/resize.h"
[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
#include "scale/scale.h"
Turn built-in effects into a library kwin links against As all effects have always been compiled into the same .so file it's questionable whether resolving the effects through a library is useful at all. By linking against the built-in effects we gain the following advantages: * don't have to load/unload the KLibrary * don't have to resolve the create, supported and enabled functions * no version check required * no dependency resolving (effects don't use it) * remove the KWIN_EFFECT macros from the effects All the effects are now registered in an effects_builtins file which maps the name to a factory method and supported or enabled by default methods. During loading the effects we first check whether there is a built-in effect by the given name and make a shortcut to create it through that. If that's not possible the normal plugin loading is used. Completely unscientific testing [1] showed an improvement of almost 10 msec during loading all the effects I use. [1] QElapsedTimer around the loading code, start kwin five times, take average. REVIEW: 115073
2014-01-17 12:46:04 +00:00
#include "showfps/showfps.h"
#include "showpaint/showpaint.h"
#include "slide/slide.h"
#include "slideback/slideback.h"
#include "thumbnailaside/thumbnailaside.h"
[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
#include "touchpoints/touchpoints.h"
Turn built-in effects into a library kwin links against As all effects have always been compiled into the same .so file it's questionable whether resolving the effects through a library is useful at all. By linking against the built-in effects we gain the following advantages: * don't have to load/unload the KLibrary * don't have to resolve the create, supported and enabled functions * no version check required * no dependency resolving (effects don't use it) * remove the KWIN_EFFECT macros from the effects All the effects are now registered in an effects_builtins file which maps the name to a factory method and supported or enabled by default methods. During loading the effects we first check whether there is a built-in effect by the given name and make a shortcut to create it through that. If that's not possible the normal plugin loading is used. Completely unscientific testing [1] showed an improvement of almost 10 msec during loading all the effects I use. [1] QElapsedTimer around the loading code, start kwin five times, take average. REVIEW: 115073
2014-01-17 12:46:04 +00:00
#include "windowgeometry/windowgeometry.h"
#include "zoom/zoom.h"
// OpenGL-specific effects for desktop
#include "coverswitch/coverswitch.h"
#include "cube/cube.h"
[kwin] Re-add desktop cube animation effects to our built in effects Got lost in the transition to built-in effects.
2014-03-11 08:53:19 +00:00
#include "cube/cubeslide.h"
Turn built-in effects into a library kwin links against As all effects have always been compiled into the same .so file it's questionable whether resolving the effects through a library is useful at all. By linking against the built-in effects we gain the following advantages: * don't have to load/unload the KLibrary * don't have to resolve the create, supported and enabled functions * no version check required * no dependency resolving (effects don't use it) * remove the KWIN_EFFECT macros from the effects All the effects are now registered in an effects_builtins file which maps the name to a factory method and supported or enabled by default methods. During loading the effects we first check whether there is a built-in effect by the given name and make a shortcut to create it through that. If that's not possible the normal plugin loading is used. Completely unscientific testing [1] showed an improvement of almost 10 msec during loading all the effects I use. [1] QElapsedTimer around the loading code, start kwin five times, take average. REVIEW: 115073
2014-01-17 12:46:04 +00:00
#include "flipswitch/flipswitch.h"
#include "glide/glide.h"
#include "invert/invert.h"
#include "lookingglass/lookingglass.h"
#include "magnifier/magnifier.h"
#include "mouseclick/mouseclick.h"
#include "mousemark/mousemark.h"
#include "sheet/sheet.h"
#include "snaphelper/snaphelper.h"
#include "startupfeedback/startupfeedback.h"
#include "trackmouse/trackmouse.h"
#include "wobblywindows/wobblywindows.h"
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
#include <KLocalizedString>
#include <kwineffects.h>
#ifndef EFFECT_BUILTINS
#define EFFECT_FALLBACK nullptr, nullptr, nullptr
#else
#define EFFECT_FALLBACK
#endif
Turn built-in effects into a library kwin links against As all effects have always been compiled into the same .so file it's questionable whether resolving the effects through a library is useful at all. By linking against the built-in effects we gain the following advantages: * don't have to load/unload the KLibrary * don't have to resolve the create, supported and enabled functions * no version check required * no dependency resolving (effects don't use it) * remove the KWIN_EFFECT macros from the effects All the effects are now registered in an effects_builtins file which maps the name to a factory method and supported or enabled by default methods. During loading the effects we first check whether there is a built-in effect by the given name and make a shortcut to create it through that. If that's not possible the normal plugin loading is used. Completely unscientific testing [1] showed an improvement of almost 10 msec during loading all the effects I use. [1] QElapsedTimer around the loading code, start kwin five times, take average. REVIEW: 115073
2014-01-17 12:46:04 +00:00
namespace KWin
{
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
namespace BuiltInEffects
{
Turn built-in effects into a library kwin links against As all effects have always been compiled into the same .so file it's questionable whether resolving the effects through a library is useful at all. By linking against the built-in effects we gain the following advantages: * don't have to load/unload the KLibrary * don't have to resolve the create, supported and enabled functions * no version check required * no dependency resolving (effects don't use it) * remove the KWIN_EFFECT macros from the effects All the effects are now registered in an effects_builtins file which maps the name to a factory method and supported or enabled by default methods. During loading the effects we first check whether there is a built-in effect by the given name and make a shortcut to create it through that. If that's not possible the normal plugin loading is used. Completely unscientific testing [1] showed an improvement of almost 10 msec during loading all the effects I use. [1] QElapsedTimer around the loading code, start kwin five times, take average. REVIEW: 115073
2014-01-17 12:46:04 +00:00
template <class T>
inline Effect *createHelper()
{
return new T();
}
Avoid global static for effects Otherwise we call i18n without a QCoreApplication Differential Revision: https://phabricator.kde.org/D15163
2018-08-30 11:01:43 +00:00
static const QVector<EffectData> &effectData()
{
static const QVector<EffectData> s_effectData = {
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
{
QString(),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QString(),
QString(),
QString(),
QString(),
QUrl(),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
nullptr,
nullptr,
nullptr
}, {
QStringLiteral("blur"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Blur"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Blurs the background behind semi-transparent windows"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Appearance"),
QString(),
QUrl(),
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
true,
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<BlurEffect>,
&BlurEffect::supported,
&BlurEffect::enabledByDefault
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
[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
EFFECT_FALLBACK
}, {
QStringLiteral("colorpicker"),
i18ndc("kwin_effects", "Name of a KWin Effect", "Color Picker"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Supports picking a color"),
QStringLiteral("Accessibility"),
QString(),
QUrl(),
true,
true,
#ifdef EFFECT_BUILTINS
&createHelper<ColorPickerEffect>,
&ColorPickerEffect::supported,
nullptr
#endif
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("contrast"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Background contrast"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Improve contrast and readability behind semi-transparent windows"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Appearance"),
QString(),
QUrl(),
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
true,
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<ContrastEffect>,
&ContrastEffect::supported,
&ContrastEffect::enabledByDefault
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("coverswitch"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Cover Switch"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Display a Cover Flow effect for the alt+tab window switcher"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Window Management"),
QString(),
QUrl(QStringLiteral("http://files.kde.org/plasma/kwin/effect-videos/cover_switch.mp4")),
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
true,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<CoverSwitchEffect>,
&CoverSwitchEffect::supported,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("cube"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Desktop Cube"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Display each virtual desktop on a side of a cube"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Window Management"),
QString(),
QUrl(QStringLiteral("http://files.kde.org/plasma/kwin/effect-videos/desktop_cube.ogv")),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<CubeEffect>,
&CubeEffect::supported,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("cubeslide"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Desktop Cube Animation"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Animate desktop switching with a cube"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Virtual Desktop Switching Animation"),
QStringLiteral("desktop-animations"),
QUrl(QStringLiteral("http://files.kde.org/plasma/kwin/effect-videos/desktop_cube_animation.ogv")),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<CubeSlideEffect>,
&CubeSlideEffect::supported,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("desktopgrid"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Desktop Grid"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Zoom out so all desktops are displayed side-by-side in a grid"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Window Management"),
QString(),
QUrl(QStringLiteral("http://files.kde.org/plasma/kwin/effect-videos/desktop_grid.mp4")),
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
true,
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<DesktopGridEffect>,
nullptr,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("diminactive"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Dim Inactive"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Darken inactive windows"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Focus"),
QString(),
QUrl(QStringLiteral("http://files.kde.org/plasma/kwin/effect-videos/dim_inactive.mp4")),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<DimInactiveEffect>,
nullptr,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("dimscreen"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Dim Screen for Administrator Mode"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Darkens the entire screen when requesting root privileges"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Focus"),
QString(),
QUrl(QStringLiteral("http://files.kde.org/plasma/kwin/effect-videos/dim_administration.mp4")),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<DimScreenEffect>,
nullptr,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("fallapart"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Fall Apart"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Closed windows fall into pieces"),
[effects] Move Fall Apart and Sheet to the Candy category Summary: The Fall Apart effect and the Sheet effect look like "candies" so let's move them to corresponding category. Test Plan: {F6167489, layout=center, size=full} Reviewers: #kwin, #plasma, #vdg, ngraham, davidedmundson Reviewed By: #kwin, #plasma, #vdg, ngraham, davidedmundson Subscribers: ngraham, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D14517
2018-07-31 16:19:12 +00:00
QStringLiteral("Candy"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QString(),
QUrl(),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<FallApartEffect>,
&FallApartEffect::supported,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("flipswitch"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Flip Switch"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Flip through windows that are in a stack for the alt+tab window switcher"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Window Management"),
QString(),
QUrl(QStringLiteral("http://files.kde.org/plasma/kwin/effect-videos/flip_switch.mp4")),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<FlipSwitchEffect>,
&FlipSwitchEffect::supported,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("glide"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Glide"),
[effects] Edit description of the Glide effect Reviewers: #kwin, broulik Reviewed By: broulik Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D14460
2018-07-29 15:12:04 +00:00
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Glide windows as they appear or disappear"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Appearance"),
QString(),
QUrl(),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<GlideEffect>,
&GlideEffect::supported,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("highlightwindow"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Highlight Window"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Highlight the appropriate window when hovering over taskbar entries"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Appearance"),
QString(),
QUrl(),
true,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
true,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<HighlightWindowEffect>,
nullptr,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("invert"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Invert"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Inverts the color of the desktop and windows"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Accessibility"),
QString(),
QUrl(QStringLiteral("http://files.kde.org/plasma/kwin/effect-videos/invert.mp4")),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<InvertEffect>,
&InvertEffect::supported,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("kscreen"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Kscreen"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Helper Effect for KScreen"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Appearance"),
QString(),
QUrl(),
true,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
true,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<KscreenEffect>,
nullptr,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("lookingglass"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Looking Glass"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "A screen magnifier that looks like a fisheye lens"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Accessibility"),
QStringLiteral("magnifiers"),
QUrl(QStringLiteral("http://files.kde.org/plasma/kwin/effect-videos/looking_glass.ogv")),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<LookingGlassEffect>,
&LookingGlassEffect::supported,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("magiclamp"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Magic Lamp"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Simulate a magic lamp when minimizing windows"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Appearance"),
QStringLiteral("minimize"),
QUrl(QStringLiteral("http://files.kde.org/plasma/kwin/effect-videos/magic_lamp.ogv")),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<MagicLampEffect>,
&MagicLampEffect::supported,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("magnifier"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Magnifier"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Magnify the section of the screen that is near the mouse cursor"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Accessibility"),
QStringLiteral("magnifiers"),
QUrl(QStringLiteral("http://files.kde.org/plasma/kwin/effect-videos/magnifier.ogv")),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<MagnifierEffect>,
&MagnifierEffect::supported,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("minimizeanimation"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Minimize Animation"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Animate the minimizing of windows"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Appearance"),
QStringLiteral("minimize"),
QUrl(QStringLiteral("http://files.kde.org/plasma/kwin/effect-videos/minimize.ogv")),
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
true,
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<MinimizeAnimationEffect>,
Honor animationsSupported in minimize, slide and sliding popups effects Differential Revision: https://phabricator.kde.org/D8938
2017-11-23 09:34:06 +00:00
&MinimizeAnimationEffect::supported,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("mouseclick"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Mouse Click Animation"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Creates an animation whenever a mouse button is clicked. This is useful for screenrecordings/presentations"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Accessibility"),
QString(),
QUrl(QStringLiteral("http://files.kde.org/plasma/kwin/effect-videos/mouse_click.mp4")),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<MouseClickEffect>,
nullptr,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("mousemark"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Mouse Mark"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Allows you to draw lines on the desktop"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Appearance"),
QString(),
QUrl(),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<MouseMarkEffect>,
nullptr,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("presentwindows"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Present Windows"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Zoom out until all opened windows can be displayed side-by-side"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Window Management"),
QString(),
QUrl(QStringLiteral("http://files.kde.org/plasma/kwin/effect-videos/present_windows.mp4")),
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
true,
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<PresentWindowsEffect>,
nullptr,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("resize"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Resize Window"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Resizes windows with a fast texture scale instead of updating contents"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Window Management"),
QString(),
QUrl(),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<ResizeEffect>,
nullptr,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
[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
EFFECT_FALLBACK
}, {
QStringLiteral("scale"),
i18ndc("kwin_effects", "Name of a KWin Effect", "Scale"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Make windows smoothly scale in and out when they are shown or hidden"),
QStringLiteral("Appearance"),
QString(),
QUrl(),
false,
false,
#ifdef EFFECT_BUILTINS
&createHelper<ScaleEffect>,
&ScaleEffect::supported,
nullptr
#endif
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("screenedge"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Screen Edge"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Highlights a screen edge when approaching"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Appearance"),
QString(),
QUrl(),
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
true,
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<ScreenEdgeEffect>,
nullptr,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("screenshot"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Screenshot"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Helper effect for KSnapshot"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Appearance"),
QString(),
QUrl(),
true,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
true,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<ScreenShotEffect>,
&ScreenShotEffect::supported,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("sheet"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Sheet"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Make modal dialogs smoothly fly in and out when they are shown or hidden"),
[effects] Move Fall Apart and Sheet to the Candy category Summary: The Fall Apart effect and the Sheet effect look like "candies" so let's move them to corresponding category. Test Plan: {F6167489, layout=center, size=full} Reviewers: #kwin, #plasma, #vdg, ngraham, davidedmundson Reviewed By: #kwin, #plasma, #vdg, ngraham, davidedmundson Subscribers: ngraham, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D14517
2018-07-31 16:19:12 +00:00
QStringLiteral("Candy"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QString(),
QUrl(),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<SheetEffect>,
&SheetEffect::supported,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("showfps"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Show FPS"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Display KWin's performance in the corner of the screen"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Tools"),
QString(),
QUrl(),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<ShowFpsEffect>,
nullptr,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("showpaint"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Show Paint"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Highlight areas of the desktop that have been recently updated"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Tools"),
QString(),
QUrl(),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<ShowPaintEffect>,
nullptr,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("slide"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Slide"),
[effects] replace old slide effect with a new one Summary: The new slide effect tries to separate each virtual desktop as much as possible. This separation makes the new slide effect more intuitive than the old one. Test Plan: * switch between virtual desktops * or, move a window to another virtual desktop Reviewers: #vdg, #kwin, #plasma, graesslin, ngraham Reviewed By: #kwin, #plasma, graesslin Subscribers: mart, graesslin, abetts, ngraham, plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D9638
2018-02-14 21:36:47 +00:00
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Slide desktops when switching virtual desktops"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Virtual Desktop Switching Animation"),
QStringLiteral("desktop-animations"),
QUrl(QStringLiteral("http://files.kde.org/plasma/kwin/effect-videos/slide.ogv")),
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
true,
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<SlideEffect>,
Honor animationsSupported in minimize, slide and sliding popups effects Differential Revision: https://phabricator.kde.org/D8938
2017-11-23 09:34:06 +00:00
&SlideEffect::supported,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("slideback"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Slide Back"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Slide back windows when another window is raised"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Focus"),
QString(),
QUrl(),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<SlideBackEffect>,
nullptr,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("slidingpopups"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Sliding popups"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Sliding animation for Plasma popups"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Appearance"),
QString(),
QUrl(QStringLiteral("http://files.kde.org/plasma/kwin/effect-videos/sliding_popups.mp4")),
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
true,
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<SlidingPopupsEffect>,
Honor animationsSupported in minimize, slide and sliding popups effects Differential Revision: https://phabricator.kde.org/D8938
2017-11-23 09:34:06 +00:00
&SlidingPopupsEffect::supported,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("snaphelper"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Snap Helper"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Help you locate the center of the screen when moving a window"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Accessibility"),
QString(),
QUrl(QStringLiteral("http://files.kde.org/plasma/kwin/effect-videos/snap_helper.mp4")),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<SnapHelperEffect>,
nullptr,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("startupfeedback"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Startup Feedback"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Helper effect for startup feedback"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Candy"),
QString(),
QUrl(),
true,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
true,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<StartupFeedbackEffect>,
&StartupFeedbackEffect::supported,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("thumbnailaside"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Thumbnail Aside"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Display window thumbnails on the edge of the screen"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Appearance"),
QString(),
QUrl(),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<ThumbnailAsideEffect>,
nullptr,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
[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
EFFECT_FALLBACK
}, {
QStringLiteral("touchpoints"),
i18ndc("kwin_effects", "Name of a KWin Effect", "Touch Points"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Visualize touch points"),
QStringLiteral("Appearance"),
QString(),
QUrl(),
false,
false,
#ifdef EFFECT_BUILTINS
&createHelper<TouchPointsEffect>,
nullptr,
nullptr
#endif
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("trackmouse"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Track Mouse"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Display a mouse cursor locating effect when activated"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Accessibility"),
QString(),
QUrl(QStringLiteral("http://files.kde.org/plasma/kwin/effect-videos/track_mouse.mp4")),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<TrackMouseEffect>,
nullptr,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("windowgeometry"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Window Geometry"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Display window geometries on move/resize"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Appearance"),
QString(),
QUrl(),
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
true,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<WindowGeometry>,
nullptr,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("wobblywindows"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Wobbly Windows"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Deform windows while they are moving"),
[effects] Move the Wobby Windows effect to the Candy category Summary: The Wobby Windows effect is more a "candy" rather than a standard effect, so it makes more sense to move it to the Candy category. Test Plan: Opened the Desktop Effects KCM, the Wobby Windows effect is in the Candy category: {F6160383, layout=center, size=full} Reviewers: #kwin, #plasma, #vdg, ngraham, broulik Reviewed By: #plasma, #vdg, ngraham, broulik Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D14455
2018-07-29 12:34:09 +00:00
QStringLiteral("Candy"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QString(),
QUrl(QStringLiteral("http://files.kde.org/plasma/kwin/effect-videos/wobbly_windows.ogv")),
false,
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<WobblyWindowsEffect>,
&WobblyWindowsEffect::supported,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}, {
QStringLiteral("zoom"),
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
i18ndc("kwin_effects", "Name of a KWin Effect", "Zoom"),
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Magnify the entire desktop"),
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
QStringLiteral("Accessibility"),
QStringLiteral("magnifiers"),
QUrl(QStringLiteral("http://files.kde.org/plasma/kwin/effect-videos/zoom.ogv")),
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
true,
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
false,
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#ifdef EFFECT_BUILTINS
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
&createHelper<ZoomEffect>,
nullptr,
nullptr
[effects] Support building the effect_builtins without need to link the lib This change allows to include the effect_builtins.cpp into the build of e.g. a kcm without having to link against all effects. The use case for this is when one needs to resolve just the name of an effect without wanting to hard code the name.
2015-01-28 08:46:31 +00:00
#endif
EFFECT_FALLBACK
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
}
Avoid global static for effects Otherwise we call i18n without a QCoreApplication Differential Revision: https://phabricator.kde.org/D15163
2018-08-30 11:01:43 +00:00
};
return s_effectData;
}
Turn built-in effects into a library kwin links against As all effects have always been compiled into the same .so file it's questionable whether resolving the effects through a library is useful at all. By linking against the built-in effects we gain the following advantages: * don't have to load/unload the KLibrary * don't have to resolve the create, supported and enabled functions * no version check required * no dependency resolving (effects don't use it) * remove the KWIN_EFFECT macros from the effects All the effects are now registered in an effects_builtins file which maps the name to a factory method and supported or enabled by default methods. During loading the effects we first check whether there is a built-in effect by the given name and make a shortcut to create it through that. If that's not possible the normal plugin loading is used. Completely unscientific testing [1] showed an improvement of almost 10 msec during loading all the effects I use. [1] QElapsedTimer around the loading code, start kwin five times, take average. REVIEW: 115073
2014-01-17 12:46:04 +00:00
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
static inline int index(BuiltInEffect effect)
Turn built-in effects into a library kwin links against As all effects have always been compiled into the same .so file it's questionable whether resolving the effects through a library is useful at all. By linking against the built-in effects we gain the following advantages: * don't have to load/unload the KLibrary * don't have to resolve the create, supported and enabled functions * no version check required * no dependency resolving (effects don't use it) * remove the KWIN_EFFECT macros from the effects All the effects are now registered in an effects_builtins file which maps the name to a factory method and supported or enabled by default methods. During loading the effects we first check whether there is a built-in effect by the given name and make a shortcut to create it through that. If that's not possible the normal plugin loading is used. Completely unscientific testing [1] showed an improvement of almost 10 msec during loading all the effects I use. [1] QElapsedTimer around the loading code, start kwin five times, take average. REVIEW: 115073
2014-01-17 12:46:04 +00:00
{
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
return static_cast<int>(effect);
[kwin] Define an enum for all the built in effects For each effect there is an enum value. The internal mapping of effect to create, supported and checkDefault is switched to the enum value, though the methods for the name based variants are still available.
2014-03-21 10:40:16 +00:00
}
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
Effect *create(BuiltInEffect effect)
[kwin] Define an enum for all the built in effects For each effect there is an enum value. The internal mapping of effect to create, supported and checkDefault is switched to the enum value, though the methods for the name based variants are still available.
2014-03-21 10:40:16 +00:00
{
[effects] Use more effectData() in BuiltInEffects Summary: While BuiltInEffects has effectData() function, many functions repeat s_effectData.at(index(effect)), which is what effectData() is doing. By using effectData(), we'll get rid of those repetitions and maybe make easier transition to other underlying data structure that stores metadata for builtin effects. Test Plan: Compiles, all enabled builtin effects are loaded and working. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D13587
2018-06-18 12:25:58 +00:00
const EffectData &data = effectData(effect);
if (data.createFunction == nullptr) {
Turn built-in effects into a library kwin links against As all effects have always been compiled into the same .so file it's questionable whether resolving the effects through a library is useful at all. By linking against the built-in effects we gain the following advantages: * don't have to load/unload the KLibrary * don't have to resolve the create, supported and enabled functions * no version check required * no dependency resolving (effects don't use it) * remove the KWIN_EFFECT macros from the effects All the effects are now registered in an effects_builtins file which maps the name to a factory method and supported or enabled by default methods. During loading the effects we first check whether there is a built-in effect by the given name and make a shortcut to create it through that. If that's not possible the normal plugin loading is used. Completely unscientific testing [1] showed an improvement of almost 10 msec during loading all the effects I use. [1] QElapsedTimer around the loading code, start kwin five times, take average. REVIEW: 115073
2014-01-17 12:46:04 +00:00
return nullptr;
}
[effects] Use more effectData() in BuiltInEffects Summary: While BuiltInEffects has effectData() function, many functions repeat s_effectData.at(index(effect)), which is what effectData() is doing. By using effectData(), we'll get rid of those repetitions and maybe make easier transition to other underlying data structure that stores metadata for builtin effects. Test Plan: Compiles, all enabled builtin effects are loaded and working. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D13587
2018-06-18 12:25:58 +00:00
return data.createFunction();
Turn built-in effects into a library kwin links against As all effects have always been compiled into the same .so file it's questionable whether resolving the effects through a library is useful at all. By linking against the built-in effects we gain the following advantages: * don't have to load/unload the KLibrary * don't have to resolve the create, supported and enabled functions * no version check required * no dependency resolving (effects don't use it) * remove the KWIN_EFFECT macros from the effects All the effects are now registered in an effects_builtins file which maps the name to a factory method and supported or enabled by default methods. During loading the effects we first check whether there is a built-in effect by the given name and make a shortcut to create it through that. If that's not possible the normal plugin loading is used. Completely unscientific testing [1] showed an improvement of almost 10 msec during loading all the effects I use. [1] QElapsedTimer around the loading code, start kwin five times, take average. REVIEW: 115073
2014-01-17 12:46:04 +00:00
}
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
bool available(const QString &name)
Turn built-in effects into a library kwin links against As all effects have always been compiled into the same .so file it's questionable whether resolving the effects through a library is useful at all. By linking against the built-in effects we gain the following advantages: * don't have to load/unload the KLibrary * don't have to resolve the create, supported and enabled functions * no version check required * no dependency resolving (effects don't use it) * remove the KWIN_EFFECT macros from the effects All the effects are now registered in an effects_builtins file which maps the name to a factory method and supported or enabled by default methods. During loading the effects we first check whether there is a built-in effect by the given name and make a shortcut to create it through that. If that's not possible the normal plugin loading is used. Completely unscientific testing [1] showed an improvement of almost 10 msec during loading all the effects I use. [1] QElapsedTimer around the loading code, start kwin five times, take average. REVIEW: 115073
2014-01-17 12:46:04 +00:00
{
Avoid global static for effects Otherwise we call i18n without a QCoreApplication Differential Revision: https://phabricator.kde.org/D15163
2018-08-30 11:01:43 +00:00
auto it = std::find_if(effectData().begin(), effectData().end(),
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
[name](const EffectData &data) {
return data.name == name;
}
);
Avoid global static for effects Otherwise we call i18n without a QCoreApplication Differential Revision: https://phabricator.kde.org/D15163
2018-08-30 11:01:43 +00:00
return it != effectData().end();
Turn built-in effects into a library kwin links against As all effects have always been compiled into the same .so file it's questionable whether resolving the effects through a library is useful at all. By linking against the built-in effects we gain the following advantages: * don't have to load/unload the KLibrary * don't have to resolve the create, supported and enabled functions * no version check required * no dependency resolving (effects don't use it) * remove the KWIN_EFFECT macros from the effects All the effects are now registered in an effects_builtins file which maps the name to a factory method and supported or enabled by default methods. During loading the effects we first check whether there is a built-in effect by the given name and make a shortcut to create it through that. If that's not possible the normal plugin loading is used. Completely unscientific testing [1] showed an improvement of almost 10 msec during loading all the effects I use. [1] QElapsedTimer around the loading code, start kwin five times, take average. REVIEW: 115073
2014-01-17 12:46:04 +00:00
}
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
bool supported(BuiltInEffect effect)
[kwin] Define an enum for all the built in effects For each effect there is an enum value. The internal mapping of effect to create, supported and checkDefault is switched to the enum value, though the methods for the name based variants are still available.
2014-03-21 10:40:16 +00:00
{
if (effect == BuiltInEffect::Invalid) {
return false;
}
[effects] Use more effectData() in BuiltInEffects Summary: While BuiltInEffects has effectData() function, many functions repeat s_effectData.at(index(effect)), which is what effectData() is doing. By using effectData(), we'll get rid of those repetitions and maybe make easier transition to other underlying data structure that stores metadata for builtin effects. Test Plan: Compiles, all enabled builtin effects are loaded and working. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D13587
2018-06-18 12:25:58 +00:00
const EffectData &data = effectData(effect);
if (data.supportedFunction == nullptr) {
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
return true;
Turn built-in effects into a library kwin links against As all effects have always been compiled into the same .so file it's questionable whether resolving the effects through a library is useful at all. By linking against the built-in effects we gain the following advantages: * don't have to load/unload the KLibrary * don't have to resolve the create, supported and enabled functions * no version check required * no dependency resolving (effects don't use it) * remove the KWIN_EFFECT macros from the effects All the effects are now registered in an effects_builtins file which maps the name to a factory method and supported or enabled by default methods. During loading the effects we first check whether there is a built-in effect by the given name and make a shortcut to create it through that. If that's not possible the normal plugin loading is used. Completely unscientific testing [1] showed an improvement of almost 10 msec during loading all the effects I use. [1] QElapsedTimer around the loading code, start kwin five times, take average. REVIEW: 115073
2014-01-17 12:46:04 +00:00
}
[effects] Use more effectData() in BuiltInEffects Summary: While BuiltInEffects has effectData() function, many functions repeat s_effectData.at(index(effect)), which is what effectData() is doing. By using effectData(), we'll get rid of those repetitions and maybe make easier transition to other underlying data structure that stores metadata for builtin effects. Test Plan: Compiles, all enabled builtin effects are loaded and working. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D13587
2018-06-18 12:25:58 +00:00
return data.supportedFunction();
Turn built-in effects into a library kwin links against As all effects have always been compiled into the same .so file it's questionable whether resolving the effects through a library is useful at all. By linking against the built-in effects we gain the following advantages: * don't have to load/unload the KLibrary * don't have to resolve the create, supported and enabled functions * no version check required * no dependency resolving (effects don't use it) * remove the KWIN_EFFECT macros from the effects All the effects are now registered in an effects_builtins file which maps the name to a factory method and supported or enabled by default methods. During loading the effects we first check whether there is a built-in effect by the given name and make a shortcut to create it through that. If that's not possible the normal plugin loading is used. Completely unscientific testing [1] showed an improvement of almost 10 msec during loading all the effects I use. [1] QElapsedTimer around the loading code, start kwin five times, take average. REVIEW: 115073
2014-01-17 12:46:04 +00:00
}
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
bool checkEnabledByDefault(BuiltInEffect effect)
[kwin] Add enabledByDefault boolean value to the BuiltInEffects For each effect the value from the desktop file is added. This will allow to query all effects which need to be loaded without looking for the service files.
2014-03-21 11:09:13 +00:00
{
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
if (effect == BuiltInEffect::Invalid) {
return false;
[kwin] Add enabledByDefault boolean value to the BuiltInEffects For each effect the value from the desktop file is added. This will allow to query all effects which need to be loaded without looking for the service files.
2014-03-21 11:09:13 +00:00
}
[effects] Use more effectData() in BuiltInEffects Summary: While BuiltInEffects has effectData() function, many functions repeat s_effectData.at(index(effect)), which is what effectData() is doing. By using effectData(), we'll get rid of those repetitions and maybe make easier transition to other underlying data structure that stores metadata for builtin effects. Test Plan: Compiles, all enabled builtin effects are loaded and working. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D13587
2018-06-18 12:25:58 +00:00
const EffectData &data = effectData(effect);
if (data.enabledFunction == nullptr) {
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
return true;
[kwin] Define an enum for all the built in effects For each effect there is an enum value. The internal mapping of effect to create, supported and checkDefault is switched to the enum value, though the methods for the name based variants are still available.
2014-03-21 10:40:16 +00:00
}
[effects] Use more effectData() in BuiltInEffects Summary: While BuiltInEffects has effectData() function, many functions repeat s_effectData.at(index(effect)), which is what effectData() is doing. By using effectData(), we'll get rid of those repetitions and maybe make easier transition to other underlying data structure that stores metadata for builtin effects. Test Plan: Compiles, all enabled builtin effects are loaded and working. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D13587
2018-06-18 12:25:58 +00:00
return data.enabledFunction();
[kwin] Define an enum for all the built in effects For each effect there is an enum value. The internal mapping of effect to create, supported and checkDefault is switched to the enum value, though the methods for the name based variants are still available.
2014-03-21 10:40:16 +00:00
}
[kwin] Add enabledByDefault boolean value to the BuiltInEffects For each effect the value from the desktop file is added. This will allow to query all effects which need to be loaded without looking for the service files.
2014-03-21 11:09:13 +00:00
bool enabledByDefault(BuiltInEffect effect)
{
[effects] Use more effectData() in BuiltInEffects Summary: While BuiltInEffects has effectData() function, many functions repeat s_effectData.at(index(effect)), which is what effectData() is doing. By using effectData(), we'll get rid of those repetitions and maybe make easier transition to other underlying data structure that stores metadata for builtin effects. Test Plan: Compiles, all enabled builtin effects are loaded and working. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D13587
2018-06-18 12:25:58 +00:00
return effectData(effect).enabled;
[kwin] Add enabledByDefault boolean value to the BuiltInEffects For each effect the value from the desktop file is added. This will allow to query all effects which need to be loaded without looking for the service files.
2014-03-21 11:09:13 +00:00
}
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
QStringList availableEffectNames()
[kwin] Define an enum for all the built in effects For each effect there is an enum value. The internal mapping of effect to create, supported and checkDefault is switched to the enum value, though the methods for the name based variants are still available.
2014-03-21 10:40:16 +00:00
{
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
QStringList result;
Avoid global static for effects Otherwise we call i18n without a QCoreApplication Differential Revision: https://phabricator.kde.org/D15163
2018-08-30 11:01:43 +00:00
for (const EffectData &data : effectData()) {
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
if (data.name.isEmpty()) {
continue;
}
result << data.name;
}
return result;
[kwin] Define an enum for all the built in effects For each effect there is an enum value. The internal mapping of effect to create, supported and checkDefault is switched to the enum value, though the methods for the name based variants are still available.
2014-03-21 10:40:16 +00:00
}
QList< BuiltInEffect > availableEffects()
{
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
QList<BuiltInEffect> result;
for (int i = index(BuiltInEffect::Invalid) + 1; i <= index(BuiltInEffect::Zoom); ++i) {
result << BuiltInEffect(i);
}
return result;
[kwin] Define an enum for all the built in effects For each effect there is an enum value. The internal mapping of effect to create, supported and checkDefault is switched to the enum value, though the methods for the name based variants are still available.
2014-03-21 10:40:16 +00:00
}
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
BuiltInEffect builtInForName(const QString &name)
[kwin] Define an enum for all the built in effects For each effect there is an enum value. The internal mapping of effect to create, supported and checkDefault is switched to the enum value, though the methods for the name based variants are still available.
2014-03-21 10:40:16 +00:00
{
Avoid global static for effects Otherwise we call i18n without a QCoreApplication Differential Revision: https://phabricator.kde.org/D15163
2018-08-30 11:01:43 +00:00
auto it = std::find_if(effectData().begin(), effectData().end(),
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
[name](const EffectData &data) {
return data.name == name;
}
);
Avoid global static for effects Otherwise we call i18n without a QCoreApplication Differential Revision: https://phabricator.kde.org/D15163
2018-08-30 11:01:43 +00:00
if (it == effectData().end()) {
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
return BuiltInEffect::Invalid;
}
Avoid global static for effects Otherwise we call i18n without a QCoreApplication Differential Revision: https://phabricator.kde.org/D15163
2018-08-30 11:01:43 +00:00
return BuiltInEffect(std::distance(effectData().begin(), it));
[kwin] Define an enum for all the built in effects For each effect there is an enum value. The internal mapping of effect to create, supported and checkDefault is switched to the enum value, though the methods for the name based variants are still available.
2014-03-21 10:40:16 +00:00
}
Improve specifying the data about the built-in effects Instead of having several hashes with data about the built-in effect, we use a struct EffectData which contains the name, the enabled by default state and function pointers to create, supported and check enabled by default. There is one static vector with all the data specified which is ordered by the BuiltInEffect enum. Thus an enum value can be used as an index to the data. In addition it's no longer resolved around QByteArray, but uses QString. REVIEW: 117354
2014-04-03 08:43:23 +00:00
QString nameForEffect(BuiltInEffect effect)
[kwin] Define an enum for all the built in effects For each effect there is an enum value. The internal mapping of effect to create, supported and checkDefault is switched to the enum value, though the methods for the name based variants are still available.
2014-03-21 10:40:16 +00:00
{
[effects] Use more effectData() in BuiltInEffects Summary: While BuiltInEffects has effectData() function, many functions repeat s_effectData.at(index(effect)), which is what effectData() is doing. By using effectData(), we'll get rid of those repetitions and maybe make easier transition to other underlying data structure that stores metadata for builtin effects. Test Plan: Compiles, all enabled builtin effects are loaded and working. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D13587
2018-06-18 12:25:58 +00:00
return effectData(effect).name;
[kwin] Define an enum for all the built in effects For each effect there is an enum value. The internal mapping of effect to create, supported and checkDefault is switched to the enum value, though the methods for the name based variants are still available.
2014-03-21 10:40:16 +00:00
}
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
const EffectData &effectData(BuiltInEffect effect)
{
Avoid global static for effects Otherwise we call i18n without a QCoreApplication Differential Revision: https://phabricator.kde.org/D15163
2018-08-30 11:01:43 +00:00
return effectData().at(index(effect));
[kcmkwin/compositing] Use BuiltinEffects to find all built-in effects The EffectData in BuiltinEffects is extended by all the data needed for the desktop effects KCM: * display name * comment * category * video-url * exclusive group * internal This information is taken directly from the desktop files. The Built-in effects are now also resolved through the BuiltInEffects namespace and the KServiceTypeTrader query is adjusted to only find the scripted effects. Unfortunately this introduces another round of adding "kwin4_effect_" to load and save the effects correctly. This will be removed once all KCMs are adjusted to use the new BuiltInEffects.
2014-04-03 14:20:26 +00:00
}
Turn built-in effects into a library kwin links against As all effects have always been compiled into the same .so file it's questionable whether resolving the effects through a library is useful at all. By linking against the built-in effects we gain the following advantages: * don't have to load/unload the KLibrary * don't have to resolve the create, supported and enabled functions * no version check required * no dependency resolving (effects don't use it) * remove the KWIN_EFFECT macros from the effects All the effects are now registered in an effects_builtins file which maps the name to a factory method and supported or enabled by default methods. During loading the effects we first check whether there is a built-in effect by the given name and make a shortcut to create it through that. If that's not possible the normal plugin loading is used. Completely unscientific testing [1] showed an improvement of almost 10 msec during loading all the effects I use. [1] QElapsedTimer around the loading code, start kwin five times, take average. REVIEW: 115073
2014-01-17 12:46:04 +00:00
} // BuiltInEffects
} // namespace
Reference in a new issue Copy permalink