Summary:
Qt has its own thing where a type might also have corresponding list
alias, e.g. QObject and QObjectList, QWidget and QWidgetList. I don't
know why Qt does that, maybe for some historical reasons, but what
matters is that we copy this pattern here in KWin. While this pattern
might be useful with some long list types, for example
QList<QWeakPointer<TabBoxClient>> TabBoxClientList
in general, it causes more harm than good. For example, we've got two
new client types, do we need corresponding list typedefs for them? If
no, why do we have ClientList and so on?
Another problem with these typedefs is that you need to include utils.h
header in order to use them. A better way to handle such things is to
just forward declare a client class (if that's possible) and use it
directly with QList or QVector. This way translation units don't get
"bloated" with utils.h stuff for no apparent reason.
So, in order to make code more consistent and easier to follow, this
change drops some of our custom typedefs. Namely ConstClientList,
ClientList, DeletedList, UnmanagedList, ToplevelList, and GroupList.
Test Plan: Compiles.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24950
Summary:
Currently our Scene is quite naive about geometry. It assumes that the
window frame wraps the attached buffer/client. While this is true for X11
clients, such geometry model is not suitable for client-side decorated
clients, in our case for xdg-shell clients that set window geometry
other than the bounding rectangle of the main surface.
In general, the proposed solution doesn't make any concrete assumptions
about the order between frame and buffer geometry, however we may still
need to reconsider the design of Scene once it starts to generate quads
for sub-surfaces.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, romangg, kwin
Tags: #kwin
Maniphest Tasks: T10867
Differential Revision: https://phabricator.kde.org/D24462
Summary:
So far the window geometry from xdg-shell wasn't implemented as it should
be. A toplevel must have two geometries assigned to it - frame and buffer.
The frame geometry describes bounds of the client excluding server-side
and client-side drop-shadows. The buffer geometry specifies rectangle on
the screen occupied by the main surface.
State and geometry handling in XdgShellClient is still a bit broken. This
change doesn't intend to fix that, it must be done in another patch asap.
Test Plan: New tests pass.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, romangg, kwin
Tags: #kwin
Maniphest Tasks: T10867
Differential Revision: https://phabricator.kde.org/D24455
Summary:
So far wayland was used by internal clients to submit raster buffers
and position themselves on the screen. While we didn't have issues with
submitting raster buffers, there were some problems with positioning
task switchers. Mostly, because we had effectively two paths that may
alter geometry.
A better approach to deal with internal clients is to let our QPA use
kwin core api directly. This way we can eliminate unnecessary roundtrips
as well make geometry handling much easier and comprehensible.
The last missing piece is shadows. Both Plasma::Dialog and Breeze widget
style use platform-specific APIs to set and unset shadows. We need to
add shadows API to KWindowSystem. Even though some internal clients lack
drop-shadows at the moment, I don't consider it to be a blocker. We can
add shadows back later on.
CCBUG: 386304
Reviewers: #kwin, davidedmundson, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, kwin
Tags: #kwin
Maniphest Tasks: T9600
Differential Revision: https://phabricator.kde.org/D22810
Summary:
This has been commented out since 2014, I doubt it will come back.
This is a big amount of code, maintenance will be easier without it.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: romangg, graesslin, kwin
Tags: #kwin, #documentation
Differential Revision: https://phabricator.kde.org/D23069
Summary:
So far we were following a bit unique and rare doxygen comment style:
/**
* Contents of the comment.
**/
Doxygen comments with this style look balanced and neat, but many people
that contribute to KWin don't follow this style. Instead, they prefer
more traditional doxygen comment style, i.e.
/**
* Contents of the comment.
*/
Reviewing such changes has been a bit frustrating for me (so selfish!)
and for other contributors.
This change switches doxygen comment style in KWin to a more traditional
style. The main reason for doing this is to make code review process easier
for new contributors as well us.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22812
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
Summary:
Window open/close animation effects should not animate the outline
because the end result is a bit awkward.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19886
Summary:
EffectWindow no longer looks up properties from Toplevel derived
classes, thus we can get rid of Deleted's properties. It's safe to do
because Deleted is not exposed to scripting API and those properties
were used only by effects.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19722
Summary:
EffectWindow proxies its properties from the client/deleted's
properties.
QObject::property(char*) is a slow string search. It's a loop
of string comparisons not a hash lookup!
QML's use of properties is different, there's a property cache.
It's fetched multiple times for every window in every paint of some
effects (such as blur). Hotspot shows this as a significant amount of
the render pass (X11) with nothing in kwin animating.
This patch replaces the macro that does
parent()->property("propertyName")
with a macro calling the relevant function directly without metaobjects.
This also improves type safety for future changes.
Test Plan:
Existing unit tests
Ran it for a bit
Reviewers: #kwin, graesslin
Subscribers: graesslin, zzag, broulik, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16602
Summary:
With the plasma shell protocol, a ShellClient gets its role/window type
after it's created, so the cached value of the popupWindow property in
EffectWindow can be wrong.
In addition to that, the value of the popupWindow property still can be
wrong because plasma shell surfaces don't have xdg-popup role, so we need
to check NetWM-based window type in ShellClient::isPopupWindow.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16835
Summary:
Doesn't have any meaningful impact. It's the same performance when T is a pointer,
but it'll bring it consistent with VirtualDesktopManager::desktops
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16736
Summary:
implement virtual desktop support for Wayland.
use the new virtual desktop protocol from D12820
The VirtualDesktopManager class needed some big change in order
to accomodate it, which is where most changes are.
Other than that, it's mostly connections to wire up
VirtualDesktopsManager and VirtualDesktopsManagement(the wayland protocol impl)
Depends on D12820
Other notable detail, is the client visibility updated to reflect the presence
of the client in the plasmavirtualdesktop.
(and the unSetDesktop concept)
Test Plan: used a bit a plasma session together with D12820, D13748 and D13746
Reviewers: #plasma, #kwin, graesslin, davidedmundson
Reviewed By: #plasma, #kwin, davidedmundson
Subscribers: hein, zzag, davidedmundson, kwin
Tags: #kwin
Maniphest Tasks: T4457
Differential Revision: https://phabricator.kde.org/D13887
Summary:
### keepAbove
Some effects(e.g. Dim Inactive) can take keep above state of a window
into account when they are making decision whether to operate on it.
Because Deleted doesn't expose keepAbove property, it will be always
`true`, which is wrong.
### keepBelow
This property was added as a counterpart to keepAbove.
### caption
That's mostly for debugging purposes, e.g.
```lang=cpp
void CoolEffect::windowClosed(EffectWindow *w)
{
qDebug() << w->caption() << "has been closed";
qDebug() << "keep above:" << w->keepAbove();
}
```
Test Plan: Manually.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13649
Summary:
Rational: unredirect fullscreen windows is a weird beast. It's intended
to make fullscreen windows "faster" by not compositing that screen. But
that doesn't really work as KWin jumps out of that condition pretty
quickly. E.g. whenever a tooltip window is shown. KWin itself has a
better functionality by supporting to block compositing completely.
The complete code was full of hacks around it to try to ensure that
things don't break.
Overall unredirect fullscreen has always been the odd one. We had it
because a compositor needs to have it, but it never got truly integrated.
E.g. effects don't interact with it properly so that some things randomly
work, others don't. Will it trigger the screenedge, probably yes, but
will it show the highlight: properly no.
By removing the functionality we finally acknowledge that this mode is
not maintained and has not been maintained for years and that we do not
intend to support it better in future. Over the years we tried to make
it more and more hidden: it's disabled for Intel GPUs, because it used
to crash KWin. It's marked as an "expert" option, etc.
It's clearly something we tried to hide from the user that it exists.
For Wayland the whole unredirect infrastructure doesn't make sense
either. There is no such thing as "unredirecting". We might make use
of passing buffers directly to the underlying stack, but that will be
done automatically when we know it can be done, not by some magic is
this a window of specific size.
Test Plan:
Compiles, cannot really test as I am an Intel user who never
had that working.
Reviewers: #kwin, #plasma, #vdg
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2180
This describes an additional offset for the client content. On X11
our client content position matches with the window - the window
decoration is part of the overall content coordinate system.
On Wayland the content is an own texture starting at 0/0. Thus a
mapping to texture coordinates will be required when server side
decorations are provided. The new information is used in the scene's
to adjust the rendering and generating of quads.
AbstractClient::mainClients is virtual and overriden in Client,
allMainClients has only a common implementation in AbstractClient.
In activation.cpp we still need one case where a temporary ClientList
needs to be constructed. Once transients are fully migrated that should
be removable again.
Toplevel::windowRole accesses WinInfo unconditionally causing crashes
if we have a Toplevel subclass which doesn't use WinInfo. So let's
make it virtual and copy to Deleted.
This was suggested to be done in a comment. The existing code might
have returned incorrect results for Client. So let's get the primary
window type and use that one.
Toplevel::opacity() accesses the WinInfo, but for a Wayland client
we won't have the opacity through the WinInfo, so let's have it as
a virtual method that a subclass can override. Also it needs to be
copied to Deleted to not have a Deleted of a Wayland client crash
because it accesses the not existing WinInfo.
The Renderer gets reparented to the Deleted. While passing it to
the Deleted the Scene's implementation can ensure that the buffers
are up to date. After passing to Deleted it's no longer allowed to
call the render method.
NOTE: this is not working completely yet, lots of code is still ifdefed
other parts are still broken.
The main difference for the new decoration API is that it is neither
QWidget nor QWindow based. It's just a QObject which processes input
events and has a paint method to render the decoration. This means all
the workarounds for the QWidget interception are removed. Also the paint
redirector is removed. Instead each compositor has now its own renderer
which can be optimized for the specific case. E.g. the OpenGL compositor
renders to a scratch image which gets copied into the combined texture,
the XRender compositor copies into the XPixmaps.
Input events are also changed. The events are composed into QMouseEvents
and passed through the decoration, which might accept them. If they are
not accpted we assume that it's a press on the decoration area allowing
us to resize/move the window. Input events are not completely working
yet, e.g. wheel events are not yet processed and double click on deco
is not yet working.
Overall KDecoration2 is way more stateful and KWin core needs more
adjustments for it. E.g. borders are allowed to be disabled at any time.
The frameId only makes sense for a Client, in case of Unmanaged the
same window id is used as for the window() handle. Client creates the
frame and destroys it.
Given that it makes sense to let Client manage the frame properly.
The ::frameId() is therefore virtual and as base implementation it
returns the client id. Client reimplements it and returns the proper
frame id.
Method is also implemented in Deleted as it used to be passed to
deleted.
fixing bug by deferring the deletion and removal of the
deleted to the next event cycle had the side effect that
this now happens in the event cycle of the compositor
restart, which was deferred to avoid precisely that...
so the test is now moved to the removal of the deleted
which got an additional flag wasClient to avoid calling
this action for each and every tooltip (and might be usable
elsewise)
BUG: 321537
FIXED-IN: 4.11
REVIEW: 111204
The only task of the PaintRedirector is to redirect the painting of the
window decorations into Pixmaps. So it should actually do this by also
handling the four pixmaps for the decoration. This simplifies the code
as all the logic concerning redirecting the painting is now grouped
together.
Furthermore the PaintRedirector is now a child of the decoration widget,
which means it gets automatically destroyed whenever the decoration is
destroyed - the Client does not have to care about it.
Also the PaintRedirector gets only created if the Compositor is active as
it is not needed in the non-compositing case.
REVIEW: 106620
The code was basically copy'n'pasted to handle both Client and Deleted
requiring to cast the Toplevel to both Client and Deleted to test whether
it is one of those.
This is now changed from runtime to compile time polymorphism. A
templated method is used to start the rendering process for the decos.
This on the one hand simplifies the code and on the other does not
require any dynamic casts any more as we use the available check on
Toplevel whether it is a Client or Deleted.
The method windowType needs actually two implementations:
* one for Clients
* one for Unmanaged
as for Clients also the window rules are checked and hacks are applied
which is both not needed for Unmanaged windows.
To have the Client specific behavior in windowType the function used to
perform two dynamic_casts which made this method one of the most
expensive during compositing, e.g. for ~1000 frames
* called ~43000 times
* ~85000 dynamic casts
* incl. cost of method: 0.24
* self cost of method: 0.05
* incl. cost of the casts: 0.12
After the change to remove the dynamic casts we have for ~1500 frames
in Client::windowType:
* called ~31000 times
* incl. cost of 0.06
* self cost of 0.02
Calls on Unmanaged and Deleted are so low that we do not need to consider
them.
BUG: 306384
FIXED-IN: 4.10
REVIEW: 106349
Ensures that we can access the minimized property in Effects
which want to not animate a closed, minimized window.
Make use of it in the Fade Effect Script to not fade out a
minimized window which would mean showing the actual not
visible window.
BUG: 303891
FIXED-IN: 4.9.0
REVIEW: 105647
This allows to copy the layer to the deleted window in order to
keep the deleted window in the same layer.
Additionally a new layer is added for unmanaged windows.
Property invokes virtual methods returning false by default. Deleted
reimplements the isDeleted and returns true. Client returns true for
isClient. Method is not called isManaged as this is already used
inside Client.
In some unfortunate situations it is possible that a window is deleted
before it is marked ready_for_painting=true. The last point is
especially troublesome for effects that reference the deleted window.
Many thanks to Elias Probst for all the testing.
CCBUG: 290025
CCBUG: 288948
REVIEW: 103733
ok'd by fredrikh.
this code is buggy right now, but I promise to squash the bugs by the 19th :)
svn path=/trunk/KDE/kdebase/workspace/; revision=1125614
As this is a bigger commit I will wait with backporting to 4.3 for something about two or three weeks and will only backport if nobody yells.
BUG: 201780
svn path=/trunk/KDE/kdebase/workspace/; revision=1004096
