Summary:
Currently, effects like Maximize, Slide Back have problems with setting
WindowForceBlurRole. They store previous state of WindowForceBlurRole.
This is wrong. Instead they should either ignore previous state of
WindowForceBlur or refcount forced role.
There's no need for refcounting right now. For example, if several effects
force blur or background contrast, they are most likely in a conflict.
Please notice that the Desktop Grid effect uses the Present Windows
effect only to calculate transformations.
Some other problems with the code that sets WindowForceBlurRole:
* Maximize effect stores previous state of WindowForceBlurRole only
for one window. It ignores the fact that there could be several
active maximize animations;
* Desktop Grid/Present Windows/Slide back don't clean after themselves.
So, after using those effects for good amount of times, memory usage
will bump.
Test Plan:
* Enabled blur for Konsole
* Maximized Konsole
* Activated Present Windows
* Activated Desktop Grid
* Raised another window(to trigger Slide Back)
Reviewers: #kwin, fredrik
Reviewed By: fredrik
Subscribers: fredrik, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13479
Summary:
All effects which use a (pointer) screen edge now also support the touch
screen edges. These are:
* Cube (cylinder, sphere)
* DesktopGrid
* PresentWindows (current, all, class)
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D5269
Summary:
This reverts commit 14d1fdf63f.
The zoom effect is definitely the wrong way, it's broken (can be
triggered without moving the mouse, expands windows outside of their
allotted area (looks like broken sizing/placement), isn't animated so
feels very choppy, isn't using well-known highlight semantics), the
result is that it feels unnatural and jarring. To be honest, when I
looked at it, I was looking for a bug in the code, e.g. margins not
being taken into account. It didn't come up in me that this could be
wanted behavior, until I read the code.
As to the original commit message: The highlight is useless for this
case, as any window can be dragged or activated, highlighted or not.
What *could* work is to somehow intensify the colors, but that again
would have to be animated, and play well with the ongoing desktop-zoom
animation, the mouse pointer location changes relative to the window, so
it's really complex to get right. I thought of this for a while, I don't
think the complexity that has to be implemented is worth the benefit,
because, what does highlighted really mean here? "window is under the
mouse" isn't a useful metric, as we don't know if the user is changing
desktops or rearranging windows, and "window under mouse" changes
depending on the zoom level, "window can be dragged or activated" also
isn't a useful metric, as I can do that with any window, anyway.
Test Plan: Tested with patch applied, desktopgrid windows don't jump around anymore.
Reviewers: graesslin
Reviewed By: graesslin
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1209
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
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
This method replaces the X-KDE-ORDERING property in the Effect's desktop
files. This change is a preparation step for integrating the new Effect
Loader which doesn't read the ordering information. Thus it needs to be
provided by the Effect itself so that the EffectsHandler can properly
insert it into the chain.
Also for the built-in Effects on the long run it doesn't make much sense
to install the desktop files. And binary plugin effects will migrate to
json metadata which also doesn't have the KService::Ptr. Thus overall it
simplifies to read this information directly from the Effect.
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
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.
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
Each effect is able to declare itself as currently being active,
that is transforming windows or painting or screen or doing anything
during the current rendered frame.
This change eliminates the hottest path inside KWin identified by
callgrind.
REVIEW: 102449
The KWin::TimeLine class was only a small wrapper around QTimeLine
without adding anything to QTimeLine what is not present in QTimeLine.
The initial idea was to make it possible to provide more curve shapes.
This is now obsoleted by Qt shipping more useful curves with QTimeLine.
So let's clean up a little bit and use QTimeLine directly instead of
the small wrapper.
All effects are adjusted to use QTimeLine directly.
Client and Unmanaged use a signal to notify that they are about to be closed.
The EffectsHandlerImpl is connected to those signals and emits the appropriate
windowClosed signal to which the effects are connected.
All previously existing windowAdded methods are renamed to slotWindowAdded.
EffectsHandlerImpl is connected to Workspace's clientAdded signal, which is
emitted a little bit earlier than the previous direct method call. This might
change behavior.
Another signal is added to Workspace to signal that an unmanaged is added.
Since the EffectFrames have been moved into KWin core nothing in the
Effects lib actually used Plasma. The only remaining method is moved
to core as it's not used in the Effects. The Effects itself still
link against Plasma, so nothing changes for them.
The Plasma includes in the kwineffects header seemed to pull in
quite some additional headers, so the includes in some effects have
to be adjusted (most often KConfigGroup). This should speed up the
compilation of the library and the effects.
* on drag start rearrange windows in old desktop
* while moving having window attached to mouse cursor
* on drop rearrange windows in new desktop
svn path=/trunk/KDE/kdebase/workspace/; revision=1049583
effects that display text or boxes to use the class. Minor speed
increase in XRender mode for those effects and a massive increase in
OpenGL mode (Double framerate in present windows in my case).
svn path=/trunk/KDE/kdebase/workspace/; revision=929951
its own directory, cleaned up the effect config macros and renamed
"MakeTransparent" to "Translucency" so that it matches its visible name.
svn path=/trunk/KDE/kdebase/workspace/; revision=921749
