Commit graph

9 commits

Author SHA1 Message Date
Vlad Zahorodnii
68c675d00d Make source code more relocatable
Occasionally, I see complaints about the file organization of kwin,
which is fair enough.

This change makes the source code more relocatable by removing relative
paths from includes.

CMAKE_CURRENT_SOURCE_DIR was added to the interface include directories
of kwin library. This means that as long as you link against kwin target,
the real location of the source code of the library doesn't matter.

With autotests, things are not as convenient as with kwin target. Some
tests use cpp files from kwin core. If we move all source code in a src/
directory, they will need to be adjusted, but mostly only in build
scripts.
2021-02-10 15:31:42 +00:00
Vlad Zahorodnii
4ce853e8e4 Prettify license headers 2020-08-07 19:57:56 +00:00
Vlad Zahorodnii
1fb9f6f13a Switch to SPDX license markers
The main advantage of SPDX license identifiers over the traditional
license headers is that it's more difficult to overlook inappropriate
licenses for kwin, for example GPL 3. We also don't have to copy a
lot of boilerplate text.

In order to create this change, I ran licensedigger -r -c from the
toplevel source directory.
2020-08-07 19:57:56 +00:00
Vlad Zagorodniy
8af2fa73dc Run clang-tidy with modernize-use-override check
Summary:
Currently code base of kwin can be viewed as two pieces. One is very
ancient, and the other one is more modern, which uses new C++ features.

The main problem with the ancient code is that it was written before
C++11 era. So, no override or final keywords, lambdas, etc.

Quite recently, KDE compiler settings were changed to show a warning if
a virtual method has missing override keyword. As you might have already
guessed, this fired back at us because of that ancient code. We had
about 500 new compiler warnings.

A "solution" was proposed to that problem - disable -Wno-suggest-override
and the other similar warning for clang. It's hard to call a solution
because those warnings are disabled not only for the old code, but also
for new. This is not what we want!

The main argument for not actually fixing the problem was that git
history will be screwed as well because of human factor. While good git
history is a very important thing, we should not go crazy about it and
block every change that somehow alters git history. git blame allows to
specify starting revision for a reason.

The other argument (human factor) can be easily solved by using tools
such as clang-tidy. clang-tidy is a clang-based linter for C++. It can
be used for various things, e.g. fixing coding style(e.g. add missing
braces to if statements, readability-braces-around-statements check),
or in our case add missing override keywords.

Test Plan: Compiles.

Reviewers: #kwin, davidedmundson

Reviewed By: #kwin, davidedmundson

Subscribers: davidedmundson, apol, romangg, kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D22371
2019-07-22 20:03:22 +03:00
Martin Gräßlin
346619aa36 Remove KWin::display from kwinglobals
Summary:
And finally nothing inside libkwineffects, libkwinglutils,
libkwinxrenderutils and kwineffect and kwin core uses KWin::display.
We are finally XLib free!

This change drops KWin::display and removes the include to QX11Info from
kwinglobals.h. And the libraries no longer need to link X11Extras.  Due
to that removal a few seeming unrelated changes are required to add the
include where needed and linkage to X11Extras.

The biggest change is to x11 platform plugin which still needs the
display and caches it in the Platform and passes it to various places in
a way that the code doesn't need to be adjusted.

Reviewers: #kwin, #plasma_on_wayland

Subscribers: plasma-devel, kwin

Tags: #plasma_on_wayland, #kwin

Differential Revision: https://phabricator.kde.org/D3337
2016-11-16 18:00:00 +01:00
Martin Gräßlin
01667cacea Panel auto hide support for Wayland panels
Summary:
This change implements auto-hide support for Wayland panels. To properly
test the screenedgeshowtest is reworked to support both X11 and Wayland
windows.

Reviewers: #kwin, #plasma_on_wayland, bshah

Subscribers: plasma-devel, kwin

Tags: #plasma_on_wayland, #kwin

Differential Revision: https://phabricator.kde.org/D3080
2016-10-18 08:18:23 +02:00
David Edmundson
04ab8554aa Add hint similar to autohide to raise/lower a window
Add action type to screen edge show to allow raise/lower as well as
autohide

Add an action type to screen edge show to allow raise/lower as well as
autohide. This uses the same atom, using a mask to separate type and
location.

The logic for handling geometry changes is moved from the screenedge to
the client so that we can handle both types without screenedge needing
to know what the raise is for.

REVIEW: 124272
2015-10-12 10:37:16 +01:00
David Edmundson
37c7e4c256 Fix screenedgeshow manual test 2015-07-01 14:06:30 +01:00
Martin Gräßlin
ed4a0d0319 Screenedge show support for Clients
This provides a new protocol intended to be used by auto-hiding panels
to make use of the centralized screen edges. To use it a Client can
set an X11 property of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin.
As value it takes:
* 0: top edge
* 1: right edge
* 2: bottom edge
* 3: left edge

KWin will hide the Client (hide because unmap or minimize would break
it) and create an Edge. If that Edge gets triggered the Client is shown
again and the property gets deleted. If the Client doesn't border the
specified screen edge the Client gets shown immediately so that we
never end in a situation that we cannot unhide the auto-hidden panel
again. The exact process is described in the documentation of
ScreenEdges. The Client can request to be shown again by deleting the
property.

If KWin gets restarted the state is read from the property and it is
tried to create the edge as described.

As this is a KWin specific extension we need to discuss what it means
for Clients using this feature with other WMs: it does nothing. As
the Client gets hidden by KWin and not by the Client, it just doesn't
get hidden if the WM doesn't provide the feature. In case of an
auto-hiding panel this seems like a good solution given that we don't
want to hide it if we cannot unhide it. Of course there's the option
for the Client to provide that feature itself and if that's wanted we
would need to announce the feature in the _NET_SUPPORTED atom. At the
moment that doesn't sound like being needed as Plasma doesn't want to
provide an own implementation.

The implementation comes with a small test application showing how
the feature is intended to be used.

REVIEW: 115910
2014-02-26 12:54:00 +01:00