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

787 lines
25 KiB
C++
Raw Normal View History

Prettify license headers
2020-08-02 22:22:19 +00:00
/*
KWin - the KDE window manager
This file is part of the KDE project.
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
Prettify license headers
2020-08-02 22:22:19 +00:00
SPDX-FileCopyrightText: 2014 Martin Gräßlin <mgraesslin@kde.org>
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
Prettify license headers
2020-08-02 22:22:19 +00:00
SPDX-License-Identifier: GPL-2.0-or-later
*/
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 "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 "fallapart/fallapart.h"
#include "highlightwindow/highlightwindow.h"
#include "magiclamp/magiclamp.h"
#include "resize/resize.h"
#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"
[effects] Move the Desktop Cube Animation effect to its own directory Summary: Just little tidying. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D15725
2018-09-24 06:36:11 +00:00
#include "cubeslide/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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
#define EFFECT_FALLBACK nullptr, 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
#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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
nullptr,
QString()
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("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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
&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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_blur_config")
[effects] Add a colorpicker effect Summary: The effect exports itself to DBus as object "/ColorPicker" and provides an own interface "org.kde.kwin.ColorPicker". It has one exported method to DBus "pick" which returns a QColor. When invoked an interactive position picking selection is started. If it ends the effect reads the color value at the picked position from the OpenGL color buffer. This implements T4568. Reviewers: #kwin, #plasma_on_wayland, broulik Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3480
2016-11-24 07:07:51 +00:00
}, {
QStringLiteral("colorpicker"),
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
nullptr,
[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
#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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QString()
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
&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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QString()
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(),
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
QUrl(QStringLiteral("https://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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_coverswitch_config")
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(),
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
QUrl(QStringLiteral("https://files.kde.org/plasma/kwin/effect-videos/desktop_cube.ogv")),
[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,
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_cube_config")
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"),
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
QUrl(QStringLiteral("https://files.kde.org/plasma/kwin/effect-videos/desktop_cube_animation.ogv")),
[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,
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_cubeslide_config")
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(),
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
QUrl(QStringLiteral("https://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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_desktopgrid_config")
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(),
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
QUrl(QStringLiteral("https://files.kde.org/plasma/kwin/effect-videos/dim_inactive.mp4")),
[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,
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_diminactive_config")
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"),
Remove the "Candy" category and fold its contents into "Appearance" Summary: The "Candy" category suffers from some problems: - It does not need to exist; everything in it is purely appearance-related and could live in the existing "Appearance" category - The name is inappropriate; "Eye Candy" would be better, but changing it to this has proven controversial in the past Let's just remove the category and move everything in it into the "Appearance" category. Test Plan: Apply and compile Open Desktop Effects KCM See that the "Candy" category is no more and the "Appearance" category has more stuff in it Reviewers: #kwin, #vdg, zzag, abetts Reviewed By: #kwin, #vdg, zzag, abetts Subscribers: abetts, zzag, kwin, kde-doc-english, GB_2 Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D27658
2020-02-25 16:53:27 +00:00
QStringLiteral("Appearance"),
[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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QString()
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(),
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
QUrl(QStringLiteral("https://files.kde.org/plasma/kwin/effect-videos/flip_switch.mp4")),
[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,
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_flipswitch_config")
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"),
[effects] Move Fade, Glide, and Scale effect into exclusive group Summary: Fade, glide, and scale effect are mutually exclusive effects so they have to be put into an exclusive group in the desktop effects kcm. Test Plan: {F6418669} Reviewers: #kwin, #plasma, #vdg, ngraham, graesslin Reviewed By: #kwin, #plasma, #vdg, ngraham, graesslin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16858
2018-11-12 19:25:05 +00:00
QStringLiteral("Window Open/Close Animation"),
QStringLiteral("toplevel-open-close-animation"),
[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
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_glide_config")
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QString()
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(),
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
QUrl(QStringLiteral("https://files.kde.org/plasma/kwin/effect-videos/invert.mp4")),
[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,
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_invert_config")
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QString()
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"),
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
QUrl(QStringLiteral("https://files.kde.org/plasma/kwin/effect-videos/looking_glass.ogv")),
[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,
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_lookingglass_config")
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"),
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
QUrl(QStringLiteral("https://files.kde.org/plasma/kwin/effect-videos/magic_lamp.ogv")),
[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,
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_magiclamp_config")
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"),
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
QUrl(QStringLiteral("https://files.kde.org/plasma/kwin/effect-videos/magnifier.ogv")),
[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,
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_magnifier_config")
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(),
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
QUrl(QStringLiteral("https://files.kde.org/plasma/kwin/effect-videos/mouse_click.mp4")),
[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,
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_mouseclick_config")
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_mousemark_config")
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(),
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
QUrl(QStringLiteral("https://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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_presentwindows_config")
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_resize_config")
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QString()
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"),
[effects/screenshot] Remove outdated reference to KSnapshot Summary: Since KSnapshot is no longer used, I modified the text in `effect_builtins.cpp` to reflect that, changing it to a generic "screenshot tools". BUG: 408407 FIXED-IN: 5.17.0 Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: filipf, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D21700
2019-06-10 14:40:45 +00:00
i18ndc("kwin_effects", "Comment describing the KWin Effect", "Helper effect for screenshot tools"),
[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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QString()
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"),
Remove the "Candy" category and fold its contents into "Appearance" Summary: The "Candy" category suffers from some problems: - It does not need to exist; everything in it is purely appearance-related and could live in the existing "Appearance" category - The name is inappropriate; "Eye Candy" would be better, but changing it to this has proven controversial in the past Let's just remove the category and move everything in it into the "Appearance" category. Test Plan: Apply and compile Open Desktop Effects KCM See that the "Candy" category is no more and the "Appearance" category has more stuff in it Reviewers: #kwin, #vdg, zzag, abetts Reviewed By: #kwin, #vdg, zzag, abetts Subscribers: abetts, zzag, kwin, kde-doc-english, GB_2 Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D27658
2020-02-25 16:53:27 +00:00
QStringLiteral("Appearance"),
[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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QString()
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_showfps_config")
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_showpaint_config")
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"),
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
QUrl(QStringLiteral("https://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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_slide_config")
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QString()
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(),
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
QUrl(QStringLiteral("https://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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QString()
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(),
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
QUrl(QStringLiteral("https://files.kde.org/plasma/kwin/effect-videos/snap_helper.mp4")),
[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,
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QString()
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"),
Remove the "Candy" category and fold its contents into "Appearance" Summary: The "Candy" category suffers from some problems: - It does not need to exist; everything in it is purely appearance-related and could live in the existing "Appearance" category - The name is inappropriate; "Eye Candy" would be better, but changing it to this has proven controversial in the past Let's just remove the category and move everything in it into the "Appearance" category. Test Plan: Apply and compile Open Desktop Effects KCM See that the "Candy" category is no more and the "Appearance" category has more stuff in it Reviewers: #kwin, #vdg, zzag, abetts Reviewed By: #kwin, #vdg, zzag, abetts Subscribers: abetts, zzag, kwin, kde-doc-english, GB_2 Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D27658
2020-02-25 16:53:27 +00:00
QStringLiteral("Appearance"),
[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(),
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QString()
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
[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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_thumbnailaside_config")
[effects] Add new effect for touch point visualization Summary: The new effect is based on the mouse click effect and uses the same rendering code (this could be improved by merging them better). Unlike mouse click there is no keyboard shortcut needed to activate: as soon as the effect is loaded all touch points are visualized. The visualization creates an animated circle for each touch down position, motion and up position. The ids are tracked and each touch id gets the same color. The first ten different touch ids get a different color. As touch ids are stable the first finger will always have the same color. Reviewers: #kwin, #plasma_on_wayland, bshah Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2464
2016-08-16 18:16:41 +00:00
}, {
QStringLiteral("touchpoints"),
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
nullptr,
[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
#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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QString()
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(),
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
QUrl(QStringLiteral("https://files.kde.org/plasma/kwin/effect-videos/track_mouse.mp4")),
[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,
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_trackmouse_config")
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_windowgeometry_config")
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"),
Remove the "Candy" category and fold its contents into "Appearance" Summary: The "Candy" category suffers from some problems: - It does not need to exist; everything in it is purely appearance-related and could live in the existing "Appearance" category - The name is inappropriate; "Eye Candy" would be better, but changing it to this has proven controversial in the past Let's just remove the category and move everything in it into the "Appearance" category. Test Plan: Apply and compile Open Desktop Effects KCM See that the "Candy" category is no more and the "Appearance" category has more stuff in it Reviewers: #kwin, #vdg, zzag, abetts Reviewed By: #kwin, #vdg, zzag, abetts Subscribers: abetts, zzag, kwin, kde-doc-english, GB_2 Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D27658
2020-02-25 16:53:27 +00:00
QStringLiteral("Appearance"),
[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(),
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
QUrl(QStringLiteral("https://files.kde.org/plasma/kwin/effect-videos/wobbly_windows.ogv")),
[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,
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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_wobblywindows_config")
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"),
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
QUrl(QStringLiteral("https://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,
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +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
Add config module information to builtin effects Add a new field to EffectData that stores an effect's config module. We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata. IMO it's much more straight forward to let the effect specify its config module directly instead.
2020-09-30 11:44:07 +00:00
QStringLiteral("kwin_zoom_config")
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