This servers two purposes.
1. it makes KWin/5 co-installable with KWin/4 as now binary and
all libraries etc. are renamed or installed to a different
location.
2. In future we need a dedicated X11 and Wayland main function
anyway. Thus it makes most sense to rename to kwin_x11 directly
instead of first renaming to kwin5. The reason why we need to
have dedicated main functions is that kwin needs to check early
whether X11 is working or Wayland is working. Right now the first
thing kwin does is trying to connect to the XServer. This happens
before the QApplication is constructed and before command line
args are processed. On Wayland we won't want to test whether we
can connect to the XServer. As it's too early to check whether we
are starting kwin for X11 or Wayland the most convenient way is to
have dedicated binaries - thus a rename is needed. Just renaming
kwin for wayland is also not a good idea as in future the "main"
kwin will be for wayland not for X11. Another case for the dedicated
binaries is the Application class, which right now first tries to
claim the X11 Window Manager Selection. Again on Wayland even with
XWayland we won't need that. KWin will be the window manager for
XWayland if KWin is the Wayland compositor. There is no need to even
try to support anything else. Most likely it will even be KWin to
start the XWayland server, so we can be sure that there is no other
WM running and thus no need to claim the selection and abort if it
fails.
REVIEW: 118266
ICCCM dependency is a beast due to two different existing versions in
different packages. Thus it cannot be a hard dep without causing problems
for our downstreams.
This change ensures that ICCCM is really considered as an optional dep
and that the version we need is found, if not we mark it as non-found.
ICCCM is only used by one test application which can easily be disabled
and some enum values are used in events.cpp. If ICCCM is not found those
are replaced by defines generated in config-kwin.h.
BUG: 336035
Similar to the already existing DBusInterface wrapper for the
org.kde.KWin interface a new CompositorDBusInterface is introduced for
org.kde.kwin.Compositing.
That way the DBus interface is split from the implementation and DBus
specific methods are no longer required in the Compositor class.
The deprecated DBus methods
* toggleCompositing(bool)
* setCompositing(bool)
are removed.
REVIEW: 118463
When find_package(KF5 CONFIG REQUIRED) is called, any subsequent
find_package(KF5) calls will be marked as required too. So,
find optional frameworks separately to avoid configure failure
if they are missing.
Also add information about the status of the optional packages
to the feature summary.
REVIEW: 117728
New build option KWIN_BUILD_COVERAGE which adds
"-fprofile-arcs -ftest-coverage" to CMAKE_CXX_FLAGS and "-lgcov" to
CMAKE_EXE_LINKER_FLAGS.
REVIEW: 117369
* Ported last qt4_wrap thingy to qt5_wrap thingy
* Include KF5Init (needed for kdeinit_executable
* Optionally include KF5DocTools and bind the docs subdirectory to it
* Include GenerateExportHeaders
Effect loading gets split by the kind of effects KWin supports:
* Built-In Effects
* Scripted Effects
* Binary Plugin Effects
For this a new AbstractEffectLoader is added which will have several
sub-classes:
* BuiltInEffectLoader
* ScriptedEffectLoader
* PluginEffectLoader
* EffectLoader
The EffectLoader will be what the EffectsHandlerImpl is using and it just
delegates to the three other types of loaders. Thus the handler doesn't
need to care about the different kinds of effects. The loading is
supposed to be completely async and the EffectLoader emits a signal
whenever an Effect got loaded. The EffectsHandlerImpl is supposed to
connect to this signal and insert it into its own Effect management.
Unloading is not performed by the loader, but by the EffectsHandler.
There is one important change which needs to be implemented: the ordering
cannot be provided by the loader and thus needs to be added to the
Effects directly.
So far only the BuiltInEffectsLoader is implemented. It's not yet
integrated into the EffectsHandlerImpl, but a unit test is added which
tries to perform the various operations provided by the loader and the
BuiltInEffects. The test should cover all cases except the Check Default
functionality which is only used by Blur and Contrast effects. This
cannot be mocked yet as the GLPlatform doesn't allow mocking yet.
We don't need to protect the build system against adding extra
directories in the CMAKE_MODULE_PATH This also prepares kde-workspace
to be build with a simple CMakeLists.txt in the root directory.
XRenderUtils are split out of kwineffects and are an own library just
like kwinglutils is an own library.
The library gets always build and is linked in KWin core unconditionally
(as it's used in outline) and conditionally in kwineffects (PaintClipper)
and the built in effects depending on XRender build option.
Instead of using EffectsHandler::sendReloadMessage we generate the dbus
interface in each plugin and call the reconfigure slot directly. That way
it's more type safe and we don't need to link kwineffects from the
configs.
REVIEW: 116875
appmenu will not be part of the first Plasma Next version since it
needs a lot of work (make it async, port to GMenu etc).
So for the time being let's disable the feature by default.
REVIEWED-By: Martin Gräßlin <mgraesslin@kde.org>
Since it is a standard (fd.o) it makes sense to copy the interface
rather than creating a dependency with plasma-workspace which it
actually doesn't since KWin will work with any screensaver using the
freedesktop specification.
This commit basically makes KWin stop using suspend-resumeStartup
methods from KSMServer. The idea is to launch things on parallel and
this is doing exactly the contrary.
Reviewed-by: Martin Gräßlin <mgraesslin@kde.org>
All should be done except for KF5 and Qt.
I tried to go through all projects and see whether it depended on the
different modules. I would appreciate it very much if the different
maintainers could take a look and see if everything is correct.
CCMAIL: plasma-devel@kde.org
A new GlobalShortcutsManager is introduced which is responsible for
holding the registered shortcuts and triggering the matching action.
The InputRedirection checks with the GlobalShortcutManager whether a key
press event triggers a global shortcut and stops processing the event in
that case.
At the moment the GlobalShortcutsManager only supports the very basics
for KWin internal usage. External applications can not yet make usage of
the global shortcut system inside KWin.
Preparation step before splitting:
* adds project(KWIN)
* lists all KWin dependencies
KWin can be built standalone if cmake is run with:
-DKWIN_BUILD_OXYGEN=OFF
-DKWIN_BUILD_KAPPMENU=OFF
Oxygen because it needs liboxygen - for standalone clients/oxygen needs
to be moved out of KWin.
KAppmenu because it includes the DBus xml file.
REVIEW: 116872
Creates two subdirectories: plasma-workspace and plasma-desktop
plasma-workspace contains the modules that should be re-usable between
different form factors. plasma-desktop contains the modules that
are specific to the Desktop.
See http://community.kde.org/Plasma/Tokamak7/split_proposal
Reviewed by Àlex Fiestas
This is a temporary solution to have less dependencies on
KDEBASE_WORKSPACE_SOURCE_DIR. Once kde-workspace is going to be splitted
this won't work, we need a proper way to find the dbus interfaces
provided by ksmserver.
Note: for appmenu the same problem exists, but doesn't affect us once we
are splitted as we can turn off the usage through a build option. So for
a splitted kde-workspace the appmenu dependency can just be temporarily
be removed.
Jonathan Riddell