In the maximized state the enabled borders were still enabled causing
the actual borders to be still shown. In addition the padding is not
adjusted to be 0. This is done in the C++ part is it does not make any
sense to have shadows being thrown to another screen for a maximized
window.
REVIEW: 106576
BUG: 307365
FIXED-IN: 4.9.2
Replace dynamic_casts to check the type for for Toplevel by isFoo()
calls and use static_casts in such blocks.
Furthermore method shape() returns now a constant reference instead of a
copy of the QRegion.
REVIEW: 106364
Left over from the cleanup which basically resulted in the active window
being put to the inactive's window opacity.
Thanks for the early notification of that issue.
BUG: 306449
FIXED-IN: 4.9.2
The oo.o related hack can be removed for several reasons:
1. The dialog in question from bug 66065 is nowadays a utility
2. The window class name changed to libreoffice
3. It's not the task of the window manager to workaround bugs in Clients
CCBUG: 66065
BUG: 306383
FIXED-IN: 4.9.2
KDE has not supported the TopMenu in any 4.x release and most of the
TopMenu related code has already been dropped from KWin. It is extremely
unlikely that there is still a window around which would need this
specific check. And even if there were such a check it would be broken.
So let's just remove this hack which means less checks in one of the
hottest code pathes of KWin.
CCBUG: 306383
The effect should have had two animations:
* on move resize
* on active/inactive change
But the timeline was adjusted in the prePaintWindow call and the timeline
is effect global and not per window. Which means that for each window the
same time is added. So instead of adding time t each frame t*n with n
being the number of windows got added. So in most cases the animation
ended in the first or second frame which means its not visible.
Through git blame I was able to track down that this incorrect behavior
was introduced in 2008. An animation broken for more than four years
without anybody noticing is probably not required. Because of that it's
dropped from the effect. As this includes quite some code and performance
improvements it goes into the release branch.
A better solution could be implemented, but that should be for 4.10.
BUG: 306263
FIXED-IN: 4.9.2
REVIEW: 106335
There were quite some useless checks like e.g. first checking whether
a window is the desktop and taking a different code path for that case
and in the other code path checking again.
Also using the new introduced boolean values for the checks instead of
comparing floating point numbers all the time.
The effect gets a set of boolean values to check whether it is active for
one of the categories (e.g. move resize, decorations).
This allows to easily check whether the effect is active at all, that is
if all values are at 1.0 the effect will never affect a window.
In all other cases it can be combined with looking at the available
windows to e.g. enable the effect for move resize only when there is a
window which is either moved or resized. This check is performed whenever
an action happens which could cause a window to become inactive.
BUG: 306262
FIXED-IN: 4.9.2
If the start Client is not part of the focus chain the call to
nextClientFocusChain() cannot return the Client again. So the loop break
condition is never reached and as the focus chain is not empty the call
always returns a not null Client which means KWin is caught in an endless
loop.
This change checks that the starting Client is in the focus chain and if
not the first Client of the focus chain is used.
BUG: 306260
BUG: 306275
FIXED-IN: 4.9.2
using color.rgba() for an invalid color corresponds to solid black, which in turns conflicts with the cache
value for such color. We use "transparent black" instead.
CCBUG: 304868
if one clicks very fast, the timeout will coincident with the
second downtime (between press and release) what was used to be
interpreted as "still down"
BUG: 305738
REVIEW: 106227
FIXED-IN: 4.9.1
the geometry setting needs to happen out of recursion,
has to be smarter for unmaximizing and also no real
place in TabGroup - the client is no longer tabbed thus
it's not the groups task to manage it's geometry.
BUG: 226881
REVIEW: 106182
FIXED-IN: 4.9.1
So far the first Client to be shown in the list (that is the
currently active window) was inserted as the last client into
the list by prepending it to the list.
This meant that if another Client actually blocks the inclusion
of the currently selected Client (e.g. only one window per app)
the currently active Client never got included in this list.
This change ensures that the recently used model switching has
the starting Client as the first Client in the list and also
simplifies the code.
Stacking order switching mode is not adjusted as it seems rather
broken, like the comment already says.
BUG: 304950
FIXED-IN: 4.9.1
REVIEW: 106139
The recently used mode of TabBox uses the active window as the entrance
into the focus chain. If there is no active window it does not find any
Clients. To solve this issue the ClientModel now uses the first entry
of the focus chain in case there is no active window.
BUG: 305449
FIXED-IN: 4.9.1
REVIEW: 106088
The Shader might have left-overs from last usage which might
cause the effect to not work properly.
BUG: 304404
FIXED-IN: 4.9.1
Reviewed By: Thomas Lübking
The supportInformation is extended to also read the properties
on all effects. In addition each effect can be queried just for
itself through D-Bus, e.g.:
qdbus org.kde.kwin /KWin supportInformationForEffect kwin4_effect_blur
All effects are extended to provide their configured and read
settings through properties. In some cases also important
runtime information is exposed.
REVIEW: 105977
BUG: 305338
FIXED-IN: 4.9.1
If the ClientModel does not contain any Clients, which can
happen if there is no desktop window, accessing the data of a
ModelIndex returns an invalid QVariant. Because of that it
needs to be ensured that the QVariant is valid before trying to
cast it to a Client Pointer.
BUG: 304620
FIXED-IN: 4.9.1
REVIEW: 105935
The code assumed that screens border to each other. That is the height
of the one screen is the y position of the other screen.
BUG: 304520
FIXED-IN: 4.9.1
REVIEW: 105958
The result of maximizing a window might be the decoration
going away. Because of that we need to delay the handling of
maximize and title bar double click by one cycle as had been
done for other close operations in 0fea5325
BUG: 304870
FIXED-IN: 4.9.1
REVIEW: 105961
