kwin/src/effects/highlightwindow/CMakeLists.txt

#######################################
# Effect

# Source files
set(highlightwindow_SOURCES
    highlightwindow.cpp
    main.cpp
)

kwin4_add_effect_module(kwin4_effect_highlightwindow ${highlightwindow_SOURCES})
target_link_libraries(kwin4_effect_highlightwindow PRIVATE
    kwineffects

    Qt::DBus
)
Cleaned up the effects/ directory by moving each individual effect into its own directory, cleaned up the effect config macros and renamed "MakeTransparent" to "Translucency" so that it matches its visible name. svn path=/trunk/KDE/kdebase/workspace/; revision=921749 2009-02-05 15:35:38 +00:00			`#######################################`
			`# Effect`

			`# Source files`
effects: Modularize builtin effects build Currently, cpp source files are included partially in effect sub-folders and src/effects/CMakeLists.txt, which is really confusing and hard to follow. With this change, effect targets will be defined in their own subfolders. This makes build files more straightforward. Effect sub-targets are eventually merged into a monolithic kwin4_effect_builtins target. Another reason for modularizing builtin effects is that no two effects can generate moc files with the same name atm even though they are in different sub-folders. This can be potentially useful in the future, e.g. making effects static plugins in order to decouple builtin effects from libkwin (every effect subfolder would need a main.cpp or plugin.cpp file, which will include the associated moc file). 2021-10-09 13:43:07 +00:00			`set(highlightwindow_SOURCES`
			`highlightwindow.cpp`
effects: Link builtin effects with executables The main motivation behind this change is to prepare kwin for importing kwayland-server code in libkwin. As is, builtin effects are linked with libkwin. Some builtin effects have wayland specific code. If we move wayland stuff in libkwin, there's going to be a circular dependency between kwin4_effect_builtins and libkwin targets. This change intends to break that dependency by linking builtin effects to kwin executable. The main issue with that is that EffectLoader would need to discover the effects indirectly. QStaticPlugin is used for that purpose. Besides breaking the cyclic dependency, it makes builtin effects use the same plugin infrastructure in libkwineffects that external effects use. Metadata in src/effects/effect_builtins.cpp was converted in a list of python dictionaries, which was fed to a python script that generated main.cpp and metadata.json files. 2021-10-12 11:06:31 +00:00			`main.cpp`
Cleanup style in CMakeLists.txt files We have lots of inconsistency at the moment in CMakeLists.txt files. Most of it is due to kwin being a very old project. This change hopefully fixes all of it. 2019-09-17 09:15:35 +00:00			`)`
effects: Modularize builtin effects build Currently, cpp source files are included partially in effect sub-folders and src/effects/CMakeLists.txt, which is really confusing and hard to follow. With this change, effect targets will be defined in their own subfolders. This makes build files more straightforward. Effect sub-targets are eventually merged into a monolithic kwin4_effect_builtins target. Another reason for modularizing builtin effects is that no two effects can generate moc files with the same name atm even though they are in different sub-folders. This can be potentially useful in the future, e.g. making effects static plugins in order to decouple builtin effects from libkwin (every effect subfolder would need a main.cpp or plugin.cpp file, which will include the associated moc file). 2021-10-09 13:43:07 +00:00
			`kwin4_add_effect_module(kwin4_effect_highlightwindow ${highlightwindow_SOURCES})`
cmake: Specify link libraries per effect target This allows to track per effect dependencies more precisely. The main problem with a library and a comment next to it saying who needs it is that the comment can get easily outdated. 2022-02-14 17:55:59 +00:00			`target_link_libraries(kwin4_effect_highlightwindow PRIVATE`
			`kwineffects`

			`Qt::DBus`
			`)`