Instead of having each declarative script create it's own qml engine
there is one hold by the Scripting singleton. The engine's root context
gets populated in Scripting and each script just gets a new child
context. Thus also the WorkspaceWrapper instance is shared between the
declarative scripts.
KWin already has a de facto OpenGL 2 dependency through QML. Combined
with the fact that the OpenGL 1 backend is basically unmaintained and
also unused, it's better to remove it for the new major release.
This change includes:
* Removal of cmake option KWIN_BUILD_OPENGL_1_COMPOSITING
* Removal of KWIN_HAVE_OPENGL_1 compile option and all code
ifdef'ed with it (partially removal of if-else constructs)
* Removal of CompositingType::OpenGL1Compositing (flags are kept
as a core flag should get introduced)
* Driver recommendation for OpenGL1Compositing changed to XRender
(should be evaluated whether the drivers can provide GL2)
* Removal of configuration option "GLLegacy"
* Removal of fooMatrix function in kwinglutils
* Removal of ARBBlurShader
* Removal of legacy code path in GLVertexBuffer
* Removal of GLShaderManager::disable
* if-blocks with ShaderManager::instance()->isValid() removed
REVIEW: 116042
KWin requires the xcb plugin otherwise KWin crashes when the first
xcb/xlib code is called. First KWin tries to set the QT_QPA_PLATFORM
to "xcb", but that doesn't protect against the command line switch.
Thus KWin also verifies that after constructing the QGuiApplication
the platform name is set to xcb, if not it exits gracefully with a
useful error message instead a crash.
To make that work the KWinSelectionOwner has to be changed to a
pointer and be delayed constructed, otherwise the crash already happens
in the KSelectionOwner.
Furthermore a small sanity check on the plugin is performed by checking
whether KWin can get the XDisplay from the QPA. If not it means that the
QPA plugin was compiled with -no-xcb-xlib which KWin doesn't support, it
still uses XLib at various places. If KWin doesn't get the Display, it
exits gracefully with a clear error message.
CCBUG: 331880
REVIEW: 116669
Rational behind this change is that displayWidth and displayHeight are
X specific API calls in kwinglobals. For the future it's easier to only
rely on functionality which goes through the EffectsHandler API which
allows easier adjustments in KWin core.
displayWidth() and displayHeight() are only used to get the size or the
complete rect of all screens. This is also provided by:
effects->virtualScreenGeometry() or
effects->virtualScreenSize()
REVIEW: 116021
Screens provides a size which is constructed from the size of
the bounding geometry of all screens and provides an overload taking
an int to return the size of a specified screen. For geometry() a new
ovload is added without an argument, which is just a convenient wrapper
for QRect(QPoint(0, 0), size()).
Both new methods are exported to effects and scripting as new
properties there called virtualScreenSize and virtualScreenGeometry.
The (virtual) size gets cached in screens and is updated whenever the
count or geometry changes.
Construction of Screens is slightly changed by moving the init code
from ctor into a virtual method init(). Reason is that we ended in
a loop with accessing the singleton pointer before it was set.
REVIEW: 116114
In KCommonDecoration the OnAllDesktops button gets hidden or shown
depending on the number of desktops. For that KDecoration is extended
by a new property which delegates to the bridge to return whether
onAllDesktops is available. In KWin Core this is implemented using
the number of desktops.
FEATURE: 321611
FIXED-IN: 5.0.0
REVIEW: 116076
Scripting has proved it's point of being useful so it's time to turn it
into a mandatory part of KWin.
Also I start to use features provided by Scripting in more and more
parts of KWin core (e.g. sharing QQmlEngine) which makes it in the
long to complicated to have a build option and ifdefs for it.
REVIEW: 116587
It's no longer needed as there won't be a KWin version specific to
Plasma Active. We want to have runtime adjustments of all parts in
the next version of Plasma.
REVIEW: 116563
This simplifies the plugin loading. Decorations just have to use
K_PLUGIN_FACTORY to specify how the KDecorationFactory needs to be
created. The KWIN_DECORATION macro is adjusted to generate the
boiler plate code, but it now needs to specify the name for the
pluginfactory and the KDecorationFactory.
This also transits the decoration abi version check to use
K_EXPORT_PLUGIN_VERSION which also simplifies the loading.
As a result the complete canLoad handling in DecorationPlugins is
removed.
REVIEW: 115930
strace -e open kate |& grep -v NOENT | grep oxygenrc | wc -l
went from 8 to 4
(and when looking for kdeglobals, from 13 to 11)
There's still a lot of work to be done in that area...
(within KConfigSkeleton, and probably kdeplatformtheme)
REVIEW: 115964
This simplifies building a decoration plugin. Now one can do:
find_package(KDecorations REQUIRED NO_MODULE)
to find the decorations library.
REVIEW: 116013
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
This seems like a more proper fix for the flickering issue in the
sliding popups effect. The problem is that slidingpopups grabs the
window in windowClosed, the fade effect checks it there, which makes
it racy.
In my tests, I've not seen this problem with the WindowAddedGrab, but
as far as I understand, the problem may well be present there as well.
(And my proposed trick doesn't work.) I've not seen this happening in my
debugging, however. The problem there is also less visible since the
transparency curves go into the same direction, and are more "in line
with each other".
So, fix: Move the setData(WindowClosedGrabRole, ...) call from
windowClosed into windowAdded, which makes sure it's set whenever the
window goes away.
REVIEW:115903
BUG:329991
This fixes the sliding popups losing their contrast effect when
animating, less flicker.
In this patch, we temporarily force the contrast effect on, but only if
it hasn't been explicitely disabled. As soon as the animation stops, the
force flag is disabled again. For disappearing windows, we just set the
flag in the same way, but skip over the bookkeeping, since the window is
going to be deleted, anyway.
REVIEW:115902
Without setting the property, Plasma's panel and dialogs lose the
backgroundcontrast effect during slides, which makes them flicker.
As the panel is shown on screen all the time, this is quite a visible
bug. To fix this, when the slide effect is started, we check for window
types and properties of each window, and force the blur flag on if it's
unset.
If the background contrast flag is set to false, we leave the window
alone assuming that there's a reason to force it off. Windows that
are newly added during the slide get the same treatment, so something
popping up while sliding (such as the desktop switch OSD) also gets
the background effect applied.When the effect stops or is interupted, we
unset what we've set, and clean up our internal bookkeeping.
Thanks Martin and Thomas for the thorough review!
REVIEW:115857
