The AbstractBackend registers itself in the WaylandServer allowing
external users to easily get to the backend and not needing to test
manually which backend is used.
There's quite some overlap and duplicated code. This AbstractEglBackend
tries to merge the two backends a little bit again.
This also introduces an AbstractEglTexture which supports both X11 and
Wayland "pixmaps" so that EglOnXBackend can support Wayland buffers.
Adds optional dependency to X11_XCB and gets used in X11WindowedBackend
to create an XLib Display if dependency is present.
This allows to create an EGL backend for the X11WindowedBackend.
This new backend allows to start a kwin_wayland server nested on an
X-Server by using a normal X11 window as output. This allows testing
kwin_wayland without needing to start another Wayland server first.
The behavior is triggered by using new command line arguments:
--windowed
--x11-display=<:0>
With optional --width and --height arguments.
In this mode the WaylandBackend is not created at all.
So far the backend is not fully integrated yet and only the QPainter
backend supports this mode.
This reorders the startup sequence quite a bit:
1. Create QAbstractEventDispatcher and install it on QCoreApplication
2. Create Application
3. Start Xwayland, use thread to get when its ready
4. Create xcb connection
5. perform startup
For using the wayland QPA it needs a patch in QtWayland which will be
part of Qt 5.4.2, otherwise it blocks.
The WaylandServer is at the moment only used to support starting an
Xwayland. It does not support Wayland clients yet, so don't get
excited.
For Xwayland it's using the trick of creating the Display before the
QApplication is created with manual event dispatching.
Since XCB 1.10 the sync extension is working properly. At the time of
the 5.3 release 1.10 will have been out for ~15 months, enough time
for distros to catch up and should allow us to use it.
As our CI system only supports 1.9 at the moment we cannot hard depend
on the version, instead we use feature info. As soon as our CI system
supports it, we should update the required min version and kick out the
ifdef.
REVIEW: 122377
Straight forward port from XLib based XCursor library to the
xcb variant which is considerably new. The xcb variant only allows
to create xcb_cursor_t for the default theme and size. Which suits
the needs in Cursor quite well, but means it's not a replacement for
the usage in zoom effect.
REVIEW: 122290
Was only used as fallback for older NVIDIA drivers. At the same time
also drop the call to nvidia-settings which was also only used as
a fallback for refresh rate detection.
REVIEW: 122423
libinput 0.8 is incompatible causing the build to fail. As we are in
dependency freeze the only option is to disable the build.
BUG: 342893
FIXED-IN: 5.2.1
A new implementation of the Screens interface is added which uses XRandR
directly instead of relying on QDesktopWidget. The implementation is
provided in a new implementation file screens_xrandr.cpp.
XRandRScreens comes with a unit test. Unfortunately it's rather difficult
to provide a proper unit test against XRandR. Xvfb (which is obviously
used on the CI system) doesn't provide the XRandR extension. Also on a
"normal" developer system one would not want to just execute the test as
the results are not predictable (number of available outputs?) and the
test would mess up the setup resulting in nobody wanting to execute the
test.
As a solution to both problems the unit test starts Xephyr as a nested
X server. This allows to have at least some limited tests against XRandR.
Nevertheless there are a few things which I was not able to test:
* multiple outputs
* no output at all
The nested X Server approach makes the interaction rather complex. Qt
opens it's connection against the main X Server thus QX11Info provides
a wrong connection and also KWin::connection() which is heavily used by
xcbutils and thus all the RandR wrappers have the wrong connection. To
circumvent this problem the test is GUILESS. In case it would call into
any code using QX11Info, it would probably either runtime fail or crash.
REVIEW: 117614
The build option got introduced for Plasma Active back in a time
when we did not properly aim for convergence. In a Plasma 5 world
we want to have only one shell and one window manager which adjust
itself. This means we don't want a differently compiled kwin for
plasma active, but the same one. Thus the build option doesn't
make much sense any more. A KWin for touch interface needs to support
screenedges for the case that mouse is plugged in.
CCBUG: 340960
REVIEW: 121200
Following features are supported:
* finds all plugins
** finds all themes for a theme-engine plugin
* renders previews for the plugin/themes
* loads currently used plugin/theme
* saves selected plugin/theme
* triggers config reload in KWin
Following features are currently not supported:
* Search
* Plugin configuration
* GHNS
* Button configuration
KWIN_HAVE_EGL was set to EGL_FOUND which doesn't make sense as EGL is
marked as a runtime dependency. Instead a new build option KWIN_BUILD_EGL
is added defaulting to ON. If set to OFF neither the X11 nor the Wayland
EGL backend are built.
CCBUG: 340171
As we use epoxy we don't need them any more. KWin compiles, links and
runs just fine without ever trying to find OpenGL or OpenGLES.
BUG: 340170
FIXED-IN: 5.2.0
With libinput we have the problem that we need to have privileges to
open the device files. In order to not need wrappers or suid bits, we
use logind. This means that kwin_wayland has to be the session controler.
A LogindIntegration is added to connect to logind and wrap the dbus
calls. This is based on the logind integration done for ksld in
ksmserver. The LogindIntegration is started by Workspace and the
InputRedirection tries to become the session controller and starts the
libinput integration only after this succeeded.
Libinput is an optional dependency for getting low level input events.
As opening the input devices requires root privs this is rather
pointless in the current state. But there is a small added test app which
can be executed with root privs to demonstrate the functionality. To
properly get input events we need a wrapper like it's used in weston.
So far the following is setup:
* opening devices found by udev
* forwarding keyboard events to InputRedirection
* forwarding pointer button events to InputRedirection
* forwarding pointer axis events to InputRedirection
* signals emitted for pointer motion events
Pointer motion events need some further work as they are provided
as delta events. We need to track that and map them properly.
Also missing are touch events due to me not having a touch screen.
It should be fairly simple to setup the touch events, though.
Also hotplugging of devices is not yet implemented.
The wayland protocols need the .c files compiled in gnu90 mode.
All known compilers used for kwin support the -std= flag, so setting it
unconditionally should be fine
REVIEW: 120231
So far this new module contains:
* Display
* OutputInterface
Display manages the server socket and server event loop. In general it's
the entry point to any part of the server.
OutputInterface is the abstraction for the wl_output interface on server
side. An OutputInterface is created through the Display.
The auto tests for ConnectionThread and Output are adjusted to use the
internal server instead of starting Weston. Especially the Output test
could be extended to test much more as we have absolute control over
the server now.
Moved from wayland_backend.[h|cpp] to buffer.[h|cpp] and
shm_pool.[h|cpp]. Buffer is slightly adjusted to have the ShmPool
passed in as a ctor argument and the ctor is private and friended with
ShmPool, so that it can only be constructed from ShmPool.
A Surface class is split out which holds a wl_surface and supports
attaching a buffer, setting the damage and emitting a signal when the
frame callback got called.
It doesn't come with a unit test yet as it first needs the ShmPool
and Buffer properly split out to easily set it up.
New classes Shell and ShellSurface are created. Both are in shell.[h|cpp]
to indicate their close relationship with the Shell having to create the
ShellSurface.
WaylandBackend is adjusted to hold a Shell* and ShellSurface* instead of
the lower level structs. This also required adjustements to the creation
of the Backend as it now doesn't set a default size any more. Thus the
backendReady signal may not be emitted before the initial configure
event arrived. This also makes it easier to support either the fullscreen
shell or wl_shell at the same time.
Of course a unit test is added for the two new classes. This needs to
be extended once we have more control over the mock Wayland server.
At the same time adding an autotest for the Output, moving the listener
into the Output class and providing enums for Subpixel and Transform.
KWin now requires wl_ouput interface version 2 as that allows us to emit
the changed signal in a better way.
The unit test is not yet capable of testing everything, we need a mock
Wayland server which is more flexible.
The FullscreenShell is a Wayland protocol provided by Weston to have
exactly one surface per output. This is exactly what KWin needs. So
in case the Wayland server we connect to provides the FullscreenShell
we prefer it over the normal Shell and mapping our surface as fullscreen.
The protocol is not yet part of wayland-client library, so the header
and source file needs to be generated. This is done during the build
process using the external tool wayland-scanner. The protocol
description is copied from the Westion 1.5 sources.
REVIEW: 119839
The Wayland::Registry class wraps wl_registry handling. It keeps track
of the interfaces in the registry and emits signals whenever a known
interface gets announced or removed. So far it only tracks the interfaces
which are used and needed by KWin.
The Wayland event queue is moved into a dedicated thread and a
new class is created for just creating the connection and listening
for events. The WaylandBackend creates the thread and uses an event
queue for the main thread.
REVIEW: 119761
All of kwin except the main function goes into a new (private) library
called kwin. Two new kdeinit_executables are created:
* kwin_x11
* kwin_wayland
Both only use a dedicated main_x11.cpp and main_wayland.cpp with the
main function and a KWin::Application subclass and linking the new
kwin library.
The main idea behind this is to be able to perform more sane sanity
checks. E.g. on Wayland we don't need to first test whether we can
create an X11 connection. Instead we should abort if we cannot connect
to the Wayland display. Also the multi-head checks are not needed on
Wayland, etc. etc. As most of that code is in the main function to
simplify it's better to split.
This will also make it easier to diverge more easily in future. The
Wayland variant can introduce more suited command line arguments for
example. This already started by having the --replace option only
available in X11 variant. The Wayland backend is still a window manager,
but doesn't claim the manager selection.
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.
Remove the manually written GL dispatch code, and use libepoxy
to resolve functions.
The only exceptions are GLX_MESA_swap_control, which is not in
the XML API registry, and GL_ARB_robustness/GL_EXT_robustness.
For the latter we want to resolve the functions to the same names
on both GLES and desktop GL, and plug in our own implementations
when the extension is not supported.
This servers two purposes.
1. it makes KWin/5 co-installable with KWin/4 as now binary and
all libraries etc. are renamed or installed to a different
location.
2. In future we need a dedicated X11 and Wayland main function
anyway. Thus it makes most sense to rename to kwin_x11 directly
instead of first renaming to kwin5. The reason why we need to
have dedicated main functions is that kwin needs to check early
whether X11 is working or Wayland is working. Right now the first
thing kwin does is trying to connect to the XServer. This happens
before the QApplication is constructed and before command line
args are processed. On Wayland we won't want to test whether we
can connect to the XServer. As it's too early to check whether we
are starting kwin for X11 or Wayland the most convenient way is to
have dedicated binaries - thus a rename is needed. Just renaming
kwin for wayland is also not a good idea as in future the "main"
kwin will be for wayland not for X11. Another case for the dedicated
binaries is the Application class, which right now first tries to
claim the X11 Window Manager Selection. Again on Wayland even with
XWayland we won't need that. KWin will be the window manager for
XWayland if KWin is the Wayland compositor. There is no need to even
try to support anything else. Most likely it will even be KWin to
start the XWayland server, so we can be sure that there is no other
WM running and thus no need to claim the selection and abort if it
fails.
REVIEW: 118266
ICCCM dependency is a beast due to two different existing versions in
different packages. Thus it cannot be a hard dep without causing problems
for our downstreams.
This change ensures that ICCCM is really considered as an optional dep
and that the version we need is found, if not we mark it as non-found.
ICCCM is only used by one test application which can easily be disabled
and some enum values are used in events.cpp. If ICCCM is not found those
are replaced by defines generated in config-kwin.h.
BUG: 336035
Similar to the already existing DBusInterface wrapper for the
org.kde.KWin interface a new CompositorDBusInterface is introduced for
org.kde.kwin.Compositing.
That way the DBus interface is split from the implementation and DBus
specific methods are no longer required in the Compositor class.
The deprecated DBus methods
* toggleCompositing(bool)
* setCompositing(bool)
are removed.
REVIEW: 118463
When find_package(KF5 CONFIG REQUIRED) is called, any subsequent
find_package(KF5) calls will be marked as required too. So,
find optional frameworks separately to avoid configure failure
if they are missing.
Also add information about the status of the optional packages
to the feature summary.
REVIEW: 117728
New build option KWIN_BUILD_COVERAGE which adds
"-fprofile-arcs -ftest-coverage" to CMAKE_CXX_FLAGS and "-lgcov" to
CMAKE_EXE_LINKER_FLAGS.
REVIEW: 117369
* Ported last qt4_wrap thingy to qt5_wrap thingy
* Include KF5Init (needed for kdeinit_executable
* Optionally include KF5DocTools and bind the docs subdirectory to it
* Include GenerateExportHeaders
Effect loading gets split by the kind of effects KWin supports:
* Built-In Effects
* Scripted Effects
* Binary Plugin Effects
For this a new AbstractEffectLoader is added which will have several
sub-classes:
* BuiltInEffectLoader
* ScriptedEffectLoader
* PluginEffectLoader
* EffectLoader
The EffectLoader will be what the EffectsHandlerImpl is using and it just
delegates to the three other types of loaders. Thus the handler doesn't
need to care about the different kinds of effects. The loading is
supposed to be completely async and the EffectLoader emits a signal
whenever an Effect got loaded. The EffectsHandlerImpl is supposed to
connect to this signal and insert it into its own Effect management.
Unloading is not performed by the loader, but by the EffectsHandler.
There is one important change which needs to be implemented: the ordering
cannot be provided by the loader and thus needs to be added to the
Effects directly.
So far only the BuiltInEffectsLoader is implemented. It's not yet
integrated into the EffectsHandlerImpl, but a unit test is added which
tries to perform the various operations provided by the loader and the
BuiltInEffects. The test should cover all cases except the Check Default
functionality which is only used by Blur and Contrast effects. This
cannot be mocked yet as the GLPlatform doesn't allow mocking yet.
We don't need to protect the build system against adding extra
directories in the CMAKE_MODULE_PATH This also prepares kde-workspace
to be build with a simple CMakeLists.txt in the root directory.
XRenderUtils are split out of kwineffects and are an own library just
like kwinglutils is an own library.
The library gets always build and is linked in KWin core unconditionally
(as it's used in outline) and conditionally in kwineffects (PaintClipper)
and the built in effects depending on XRender build option.
Instead of using EffectsHandler::sendReloadMessage we generate the dbus
interface in each plugin and call the reconfigure slot directly. That way
it's more type safe and we don't need to link kwineffects from the
configs.
REVIEW: 116875
appmenu will not be part of the first Plasma Next version since it
needs a lot of work (make it async, port to GMenu etc).
So for the time being let's disable the feature by default.
REVIEWED-By: Martin Gräßlin <mgraesslin@kde.org>
Since it is a standard (fd.o) it makes sense to copy the interface
rather than creating a dependency with plasma-workspace which it
actually doesn't since KWin will work with any screensaver using the
freedesktop specification.
This commit basically makes KWin stop using suspend-resumeStartup
methods from KSMServer. The idea is to launch things on parallel and
this is doing exactly the contrary.
Reviewed-by: Martin Gräßlin <mgraesslin@kde.org>
All should be done except for KF5 and Qt.
I tried to go through all projects and see whether it depended on the
different modules. I would appreciate it very much if the different
maintainers could take a look and see if everything is correct.
CCMAIL: plasma-devel@kde.org
A new GlobalShortcutsManager is introduced which is responsible for
holding the registered shortcuts and triggering the matching action.
The InputRedirection checks with the GlobalShortcutManager whether a key
press event triggers a global shortcut and stops processing the event in
that case.
At the moment the GlobalShortcutsManager only supports the very basics
for KWin internal usage. External applications can not yet make usage of
the global shortcut system inside KWin.
Preparation step before splitting:
* adds project(KWIN)
* lists all KWin dependencies
KWin can be built standalone if cmake is run with:
-DKWIN_BUILD_OXYGEN=OFF
-DKWIN_BUILD_KAPPMENU=OFF
Oxygen because it needs liboxygen - for standalone clients/oxygen needs
to be moved out of KWin.
KAppmenu because it includes the DBus xml file.
REVIEW: 116872
Creates two subdirectories: plasma-workspace and plasma-desktop
plasma-workspace contains the modules that should be re-usable between
different form factors. plasma-desktop contains the modules that
are specific to the Desktop.
See http://community.kde.org/Plasma/Tokamak7/split_proposal
Reviewed by Àlex Fiestas
This is a temporary solution to have less dependencies on
KDEBASE_WORKSPACE_SOURCE_DIR. Once kde-workspace is going to be splitted
this won't work, we need a proper way to find the dbus interfaces
provided by ksmserver.
Note: for appmenu the same problem exists, but doesn't affect us once we
are splitted as we can turn off the usage through a build option. So for
a splitted kde-workspace the appmenu dependency can just be temporarily
be removed.
Major new functionality is xkbcommon support. InputRedirection holds an
instance to a small wrapper class which has the xkb context, keymap and
state. The keymap is initialied from the file descriptor we get from the
Wayland backend.
InputRedirection uses this to translate the keycodes into keysymbols and
to QString and to track the modifiers as provided by the
Qt::KeybordModifiers flags.
This provides us enough information for internal usage (e.g. pass through
effects if they have "grabbed" the keyboard).
If KWin doesn't filter out the key events, it passes them on to the
currently active Client respectively an unmanaged on top of the stack.
This needs still some improvement (not each unmanaged should get the
event). The Client/Unmnaged still uses xtest extension to send the key
events to the window. So keylogging is still possible.
So far this new class is not yet doing much. The WaylandBackend forwards
the received pointer events to this InputRedirection class. From there
signals are emitted to inform internal areas about the changes first.
The events are currently forwarded to X through the xtest extension. This
will be removed in future. Input will be forwarded directly to the
surface which wants it (no matter whether X11 or Wayland).
In order to get all our UI being written in QML, the Outline for
compositing is ported to QtQuick. It creates a QQmlContext and
QQmlComponent and loads the (currently hardcoded) qml file. The context
gets to properties exported: outline. The outline property allows the qml
to get the geometry it should use. The QQmlEngine is used from Scripting
thus all general scripting properties are exported (e.g. workspace).
The qml script is expected to create a QQuickWindow as it's root item
and style it.
The qml file is stored in a new qml subdirectory. The idea is that each
of the qml types we have gets an own directory there and for each
implementation there should be a further subdirectory.
Thus we have outline/plasma/ with outline being the type and plasma
being the implementation. But at the moment the script location is still
hardcoded.
REVIEW: 116123
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
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 building a decoration plugin. Now one can do:
find_package(KDecorations REQUIRED NO_MODULE)
to find the decorations library.
REVIEW: 116013
The test application can verify that KWin correctly interprets the
WM_NORMAL_HINTS as described in ICCCM section 4.1.2.3 for the
combination of min size, base size and size increment.
Introduces an optional dependency to xcb-icccm library. It's optional
as the last time we tried to use it build.kde.org didn't like it at
all. Thus it should be possible to disable building this test app if
the dependency is not found.
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
This compositor uses only the QPainter API to perform rendering. The
window's X Pixmap is mapped to a QImage using XShm. As rendering backend
a QImage is used.
The new compositing type "QPainterCompositing" is introduced. Effects
need to be adjusted to explicitly check the compositing type and no
longer assume the compositing type is XRender if it's not OpenGL.
This compositor can be selected with using "Q" as the value for
KWIN_COMPOSE env variable or setting the config value to "QPainter".
The GUI is not yet adjusted to select this compositor.
The QPainter scene provides currently the following features:
* 2D transformations (translation and scalation)
* opacity modifications
* rendering of decorations (new PaintRedirector sub class)
* rendering of shadows
* rendering of effect frames
* rendering to a Wayland surface
The following features are currently not provided:
* saturation changes
* brightness changes
* 3D transformations
* rendering to X Overlay window
* offscreen rendering (e.g. needed for screen shot effect)
* custom rendering in the effects to the current back buffer
The functionality to create the connection to a Wayland compositor and
creating a fullscreen surface is moved into wayland_backend.(h|cpp). The
wl_egl_window for the surface is moved into the EglWaylandBackend to have
the actual WaylandBackend free from Egl. This will allow in future to
implement other compositing backends for Wayland which do not use egl.
This means that egl is no longer a build requirement for the wayland
related functionality.
By not using a QQuickView it becomes possible to just use a
PlasmaCore.Dialog or a Quick.Window in the TabBox qml and thus it's
possible to simplify the qml code.
To support this a new SwitcherItem is introduced and exported to QML.
It's a simple QObject providing all the properties which used to be
exported to the root context. A declarative TabBox is expected to
use one of these items. The C++ side finds the Switcher and for that
supports the case that the SwitcherItem is the rootItem or a child
item.
A declarative TabBox has also to create a QQuickWindow, e.g. a
PlasmaCore.Dialog. The visibility of that window should be controlled
through the visible property on the SwitcherItem. The underlying C++
implementation assumes that a TabBox only uses one window (it needs to
get destroyed once it's hidden and included in highlight windows).
Thanks to this change it's no longer needed to reload the TabBox
whenever it gets shown or the alternative TabBox gets shown. Instead
the same QML script can get reused. Other created switchers are ignored
as the visible property won't be changed to true.
Instead we generate an export header for kdeinit_kwin and use it
to declare the KWIN_EXPORT. With this change our libs don't include
any KDE4Support headers any more. One step closer to no KDE4Support.
It's basically a run of the port-cmake.sh script in here, mostly the changes
are the following:
- Using KF5::* targets
- Using the proper macros, following recent developments in frameworks
The xcb sync protocol is incorrectly defined (see [1]) which results in
xcb_sync_create_alarm not creating a valid alarm. To work around this
issue we only create the alarm without setting the int64 values. For
those we use the XLib XSyncChangeAlarm call after we verified that the
alarm got created. This unfortunately reintroduces linking against
libxext. But at least resizing works again.
[1] http://lists.freedesktop.org/archives/xcb/2013-June/008375.html
The main purpose of the opengl testapp was to set the environment
variable LIBGL_ALWAYS_INDIRECT if direct rendering is not supported
before glx gets initialized.
With Qt5 we may no longer set this environment variable. QtQuick
requires direct rendering. On IvyBridge QtQuick is crashing if the
variable is set. Thus we are no longer allowed to set it and thus the
complete test becomes pointless.
The test app basically whitelisted most drivers anyway, the only
drivers which were problematic are the proprietary Catalyst drivers.
It that's still a problem we can also disable OpenGL compositing on
those drivers through the recommendation in the GLPlatform.
This also means that the KWIN_DIRECT_GL variable is no longer useful.
As KWin indirectly uses Qt's OpenGL through QtQuick we need to ensure
to not mix OpenGL and OpenGLES. So we have to built KWin only against
OpenGL if Qt is built against OpenGL and we have to built KWin only
against GLESv2 if Qt is built against GLESv2.
This means the kwin_gles binary is no more. There is only kwin which
either links GL or GLESv2.
Note to people compiling from source: it's only the default of the
cmake variable which got changed. You have to delete the variable
from the cache to get this change.
The DBusCall is exported as a QObject to the QML environment. It is
intended as a declarative replacement for the callDBus method which used
to be exported on global scope in the QtQuick 1 world.
Example usage:
DBusCall {
id: dbus
service: "org.kde.KWin"
path: "/KWin"
method: "setCurrentDesktop"
arguments: [1]
Component.onCompleted: dbus.call()
}
Getting all functionality from old solution into new one is not really
possible. Main problems are that QtScript provided more functionality
than the QJSEngine. For example it's no longer possible to just export
functions to the engine. We need to have a Qt wrapper object. At the
moment this wrapper object doesn't export all functions as the callbacks
are tricky. A solution might be to create specific QML types
encapsulating functionality which used to be exported on the functions.
Nevertheless a basic QML script loads and works and the ported readConfig
function works, too.
AbstractThumbnailItem inherits from QQuickPaintedItem using QPainter to
do the fallback painting of icons.
The scene is adjusted to get the information from QQuickItem instead of
QDeclarativeItem. Clipping got a little bit more complex as the clip
path does not exist any more. To get it right the ThumbnailItem needs to
specify the parent it wants to be clipped to with the clipTo property.
E.g.:
clipTo: listView
The scene uses this clipTo parent item to correctly calculate the clip
region. Also the ThumbnailItem needs to have clipping enabled.
Note: this commit currently breaks TabBox as the qml and view are not
yet adjusted. In scripting the export of the item is disabled, but any
qml script using a ThumbnailItem would obviously also fail.
1. it apparently is ineffective
2. if it was effective, it's current behavior would be not exactly helpful
(sets __GL_YIELD to NOTHING, causing busy waits on doublebuffer swapping)
3. it does for sure pollute the doublebuffer/usleep detection (setenv is set to override),
ie. the overehad detection code gets a different opinion on __GL_YIELD than libGL
REVIEW: 111858
CCBUG: 322060
To ease porting a few features are disabled, this includes:
* kcms
* decorations
* activities
Note: KWin doesn't work yet, the event filter is not yet ported!
This dependency is causing build problems on a number of systems,
and it doesn't make much sense to bring in a whole library for three
one-line convenience functions.
Rudimentary support for input events. Events from Wayland are forwarded
to X's root window using the XTest extension.
Currently supported:
* left/middle/right mouse button
* keyboard events
Not supported:
* additional mouse buttons
* mouse wheel
* touch events
Obviously this is a rather huge hack and is only intended till we have
XWayland support and proper input redirection inside KWin.
This backend is able to composite on a Wayland surface instead of an X11
overlay window. It can be considered as a prototype for a Wayland session
compositor.
For texture from X11 pixmap the backend uses XShm. This is far from
optimal, but the KHR_image_pixmap extension is not available in Mesa's
Wayland backend. It's a temporary solution till we have XWayland and
texture from Wayland buffer.
To use this backend one needs to specify the environment variable
KWIN_OPENGL_INTERFACE with "egl_wayland". In future KWin should probably
use this backend if the Wayland display env variable is defined.
To use this setup:
1. Have a normal X-Server running on e.g. VT7
2. Start Weston on VT1
3. Start a terminal on Weston
4. start KWin with:
DISPLAY=:0 KWIN_OPENGL_INTERFACE=egl_wayland kwin --replace &
This should map a Wayland surface to Weston showing the content of the X
setup. At the moment it's not yet possible to interact with the surface
as input events are not yet recieved in the backend.
There are still a lot of limitations as documented in the code.
Main motivation for this change is that it's unhandy to have the class
definition in workspace.h and client.h while the implementation is in
events.cpp although nothing in events.cpp uses it directly.
By getting it out of workspace.h we get the header a little bit smaller
which should improve compile time given that it's included almost
everywhere.
In events.cpp the enum usage is changed to NETWinInfo as that's the class
where they are defined.
RootInfo does no longer hold a workspace pointer. Where it's needed it
uses the singleton accessor of Workspace.
REVIEW: 110199
Overall all notifications except compositing suspended by DBus were
configured by default to not have any action. This means all the time we
emit a notification we keep DBus and KDED busy for nothing.
All the cases when a notification is triggered ire also exported to
KWin scripting, so if one really needs to handle something in case a
window is moved, it could be done through a KWin script with much more
context about the event.
REVIEW: 110113
BUG: 258097
FIXED-IN: 4.11
Following the approaches of other split out functionality Screens is a
singleton class created by Workspace.
The class takes over the responsibility for:
* screenChanged signal delayed by timer
* number of screens
* geometry of given screen
* active screen
* config option for active screen follows mouse
The class contains a small abstraction layer and has a concrete subclass
wrapping around QDesktopWidget, but the idea is to go more low level and
interact with XRandR directly to get more detailed information.
All over KWin the usage from QDesktopWidget is ported over to the new
Screens class.
REVIEW: 109839
All activities related code moves into new singleton class Activities.
This class gets only included into the build if the build option is
enabled which means there are less ifdefs all over the code and it also
handles better the moc doesn't like ifdef case.
The class holds the list of open and all activites, the current and the
previous activity and the KActivities::Controller. It also emits the
signals for any activities related changes.
Workspace still contains some activities related code. That is the
adjustment on change of current activity. Nevertheless the code looks
much cleaner now and does not contain the confusing naming conflict with
takeActivity() which existed before.
In all the places where Activities got used the code got adjusted and
quite often the ifdef got added with a fallback for the disabled case.
A new ClientModel is added which provides multiple different views on
KWin's Clients. The model is organized as a tree model supporting the
following levels:
* activities
* virtual desktops
* screens
* none
The levels can be ordered in whatever way one wants. That is the tree
structure can have an ordering of activities then virtual desktops or
the other way around.
In addition the model provides Exclusion flags to exclude clients of
certain types. E.g. it's possible to exclude all windows which are not on
the current desktop or all windows which are of type dock.
The model gets automatically updated whenever a Client is added/removed
or changes a state in a way that it should be excluded/included.
The ClientModel is not directly exported to QML. Instead there are
specific sub classes for certain common orderings. This solutions is
chosen to workaround some limitations of QML. The initial idea was to
use a property taking a list of the levels, but this doesn't work because
we are not notified when the QDeclarativeListProperty changes.
Currently the following models are provided to QML:
* ClientModel -> no restrictions
* ClientModelByScreen -> ordering by screen
* ClientModelByScreenAndDesktop -> screen, then desktop
These can be used to get all Clients:
ClientModel {
}
Or to get the classic Present Windows on current desktop:
ClientModelByScreen {
exclusions: ClientModel.OtherDesktopsExclusion | ClientModel.NotAcceptingFocusExclusion | ...
}
Or to get the classic Present Windows on all desktops:
ClientModelByScreen {
exclusions: ClientModel.NotAcceptingFocusExclusion | ...
}
Or our well known desktop grid:
ClientModelByScreenAndDesktop {
id: desktopGrid
exclusions: ClientModel.NotAcceptingFocusExclusion | ...
}
To support filtering as known by the Present Windows effect one can use
a ClientFilterModel, which is a QSortFilterProxyModel filtering on
window caption, role and class:
ClientFilterModel {
id: filterModel
clientModel: desktopGrid
filter: filterItem.text
}
In case it's a tree level obviously QML does not support this correctly.
So we need to use a VisualDataModel:
VisualDataModel {
id: clientModel
model: filterModel
Component.onCompleted: {
clientModel.rootIndex = modelIndex(0);
clientModel.rootIndex = modelIndex(0);
clientModel.delegate = thumbnailDelegate;
}
}
As we can see, the rootIndex has to be set to the level which contains
the Clients. Also it seems to be important to create the delegate after
the model index has been set. The idea is to have only one ClientModel
and multiple VisualDataModels if multiple views on the data is needed.
The model has been tested with a painful modeltest session. It looks good
so far modulo the listed limitations and that modeltest is not liking
closing Yakuake in the ClientModelByScreenAndDesktop setup, though it
works fine in real world testing.
REVIEW: 109604
