Most of those effects didn't need special screen locking handling on
X11 as they prevented screen locking. On Wayland though, we don't
want the lock screen shown on a cube.
REVIEW: 126122
Eg. if a window is closed while "timeline.currentValue() == 0",
slotWindowClosed() will shortcut exit and not be removed from the
managers, thus dangle around forever.
Maybe there're other ways for a window to be deleted w/o
the closed slot being entered.
CCBUG: 339970
REVIEW: 126034
While the main plasma desktop containment does one
desktop per screen, that does not necessarily hold
for other containments, let alone other desktop shells
To indicate that the window is "active" ie. can
be dragged or activated (like in present windows)
There was either a bug or a forum post complaining
about the inability to activate windows from DG
They're only traversed and QHash is unordered - so
the worst container. Also we have complete control
over the maintained class, so we can just keep the
mapped EffectWindow there
before, hiding the buttons relied on the effect
seeing a paint event for the (with a low timeline
value) what's too wonky at least for instant animations
(certain failure) or when effect exits immediatey
(due to screen edge invocation issues or whatever)
BUG: 351869
FIXED-IN: 5.4.2
REVIEW: 124970
Theory:
----------
because PresentWindowsEffect::screenCountChanged() is shortcut
for "if (!isActive())", but the desktopgrid doesn't call
PresentWindowsEffect::setActive (or at least
PresentWindowsEffect::screenCountChanged), so the effect can
"miss" the increasing screen count change (it sees the signal,
but ignores it) and when desktopgrid calls it, it assumes the
m_gridSizes array is big enough (but it isn't)
Steps:
----------
1. effects are loaded, 1 screen present
2. 2nd screen gets added, but inactive effects ignore that
3. desktop grid gets activated, updates according to screen count,
calls presentwindows for screen #2
4. presentwindows data is only prepared for one screen from step 1
=> BOOM
BUG: 351724
CCBUG: 326032
FIXED-IN: 5.4.2
REVIEW: 124960
the (old) button effect windows used to be unreferenced
with the re-invocation of the effect. because we stopped
deleting/recreating the window, this approach failed and
the effect window was never deleted.
Unreferencing the window at proper occasion (see new hide
location) coked up - guess what - the exact same "texture is
junk" issue as for the QtQuick close button in present windows...
So we resort to the exact same stupid "hide by moving" solution
as we have there.
BUG: 348577
FIXED-IN: 5.4
REVIEW: 124136
Same issue as with present windows closers: qml is slow
Interestingly "hide" means "hide" here and there're also
no visual artifacts.
BUG: 347339
REVIEW: 123668
This is now crucial, because while before
(the minimized) windows were conditionally
shown, but are now always behind the desktop.
Also, it makes the tabbox more consistent.
BUG: 344083
REVIEW: 122679
DesktopGrid uses PresentWindows Effect as a proxy effect. Instead of
hard coding the name of the Effect let's use the name resolving provided
by BuiltInEffects.
Most is just switched to the ::read(). That should be enough for all the
Effects which have a KSharedConfig::Ptr underneath. If not we just need
to find a good place to put the reload.
Implemented in KWin core to forward to new global shortcut system. This
method should be extended/changed once we go to Qt5/KF5 to make the usage
easier (no more KAction).
Each global shortcut in the effects makes use of this new method.
As all effects have always been compiled into the same .so file it's
questionable whether resolving the effects through a library is useful
at all. By linking against the built-in effects we gain the following
advantages:
* don't have to load/unload the KLibrary
* don't have to resolve the create, supported and enabled functions
* no version check required
* no dependency resolving (effects don't use it)
* remove the KWIN_EFFECT macros from the effects
All the effects are now registered in an effects_builtins file which
maps the name to a factory method and supported or enabled by default
methods.
During loading the effects we first check whether there is a built-in
effect by the given name and make a shortcut to create it through that.
If that's not possible the normal plugin loading is used.
Completely unscientific testing [1] showed an improvement of almost 10
msec during loading all the effects I use.
[1] QElapsedTimer around the loading code, start kwin five times, take
average.
REVIEW: 115073
Most effects had a "collection" for one action. We don't need the
action collection, all it was used for is setting the object name.
With the removal of KActionCollection the effects do not need to link
XmlGui any more, though the dependency is still pulled in through
plasma.
* "" needs to be wrapped in QStringLiteral
* QString::fromUtf8 needed for const char* and QByteArray
* QByteArray::constData() needed to get to the const char*
With the removal of BoxSwitch all effects which want mouse events use the
fullscreen input window. The available functionality is too complex both
in EffectsHandler and in the Effects.
With this change only fullscreen input windows are supported and all
effects share the input window. This means there is at maximum one input
window. This simplifies the code in the Effects as they don't have to
keep track of the window they created any more. In EffectsHandler it
means that only one window needs to be created, destroyed and raised.
Also it means that we can properly react on screen size changes which had
been ignored in the past. Also quite some roundtrips to X are no longer
needed as we do not need to query the window geometry when creating the
input window.
REVIEW: 110156
Many headers included KLocale to use i18n and co. But those methods are
defined in KLocalizedString and not in KLocale.
With KF5 klocale.h does no longer include KLocalizedString causing lots
of compile errors.
The main difference is that the activation of an edge is no longer
broadcasted to all effects and scripts, but instead a passed in slot of
the Effect/Script is invoked.
For this the EffectsHandler API is changed to take the Effect as an
argument to (un)reserveElectricBorder. As callback slot the existing
borderActivated is used.
In addition the ScreenEdge monitors the object for beeing destroyed and
unregisters the the edge automatically. This removes the need from the
Effect to call unregister in the dtor.
BUG: 309695
FIXED-IN: 4.11
In effects it's obvious that compositing is enabled, so specifying the
translucent element is no problem.
In tabbox a context property "compositing" is injected which decides
whether "translucent" or "opaque" elements should be used. Here the
translucent elements are only used if the Blur effect is available - for
this a new Effect::Feature Blur is introduced and in addition it is
tested whether the theme provides the translucent element.
Also the masking is adjusted to ensure that only the shadow is not
blurred.
Reason for this change is that Plasma theme seems not always to pick up
whether compositing is used when used from inside KWin. It does not cover
the Desktop Change OSD which uses PlasmaCore.Dialog and there we cannot
(yet) inject that we use compositing.
Overall I'm quite unhappy with this patch and I do hope we can fix it in
the proper place in the lifetime of 4.10 and revert this patch.
CCBUG: 311995
REVIEW: 108438
The ownership for virtual desktops is moved from Workspace into a new
VirtualDesktopManager. The manager is responsible for providing the count
of virtual desktops and keeping track of the currently used virtual
desktop.
All methods related to moving between desktops are also moved from
Workspace to the new manager, though all methods related to Clients on
Virtual Desktops remain in Workspace for the time being. This is to have
the new manager as independent from KWin core as possible.
An rather important change for the handling of virtual desktops is that
the count and the id of a desktop is now an unsinged integer instead of
an integer. The reason for that is that we cannot have a negative count
of desktops as well as it is not possible to be on a desktop with a
negative identifier.
In that regard it is important to remember that a Client can be on a
desktop with a negative identifier. The special value for a Client being
on all desktops is handled by using -1 as a desktop. For the time being
this is not adjusted but instead of comparing the virtual desktop ids one
should prefer to use the convenient methods like isOnDesktop and
isOnAllDesktops. This would allow in future to internally change the
representation for on all desktops.
