This is an alternative approach suggested by the
NETWM spec.
The advantage is, that windows are not minimized
at all what apparently lead to some confusion
about the nature of the mode (which was abused
to tidy up) and a secret config key to allow for
that unrelated behavior.
Instead the ShowDesktopIsMinimizeAll key is removed
and replaced by a dedicated script + shortcut.
Bonus: less code to remember "minimized" windows =)
This adds "Quick Tile Window to the Top" and "Quick Title Window to the Bottom" shortcuts. These are
useful for those using displays that are in portrait orientation.
CCBUG: 310005
REVIEW: 123153
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.
when restacking for shaded windows and uncomposited tabboxes
the group check should not be applied since we know better
eg. to restore a former order
CCBUG: 186206
REVIEW: 122469
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
Instead of passing the macro based Predicate to findClient it now
expects a function which can be passed to std::find_if.
Existing code like:
xcb_window_t window; // our test window
Client *c = findClient(WindowMatchPredicated(window));
becomes:
Client *c = findClient([window](const Client *c) {
return c->window() == window;
});
The advantage is that it is way more flexible and has the logic what
to check for directly with the code and not hidden in the macro
definition.
In addition there is a simplified overload for the very common case of
matching a window id against one of Client's windows. This overloaded
method takes a Predicate and the window id.
Above example becomes:
Client *c = findClient(Predicate::WindowMatch, w);
Existing code is migrated to use the simplified method taking
MatchPredicate and window id. The very few cases where a more complex
condition is tested the lambda function is used. As these are very
local tests only used in one function it's not worthwhile to add further
overloads to the findClient method in Workspace.
With this change all the Predicate macro definitions are removed from
utils.h as they are now completely unused.
REVIEW: 116916
Instead of passing the macro based Predicate to findUnmanaged it now
expects a function which can be passed to std::find_if.
Existing code like:
xcb_window_t window; // our test window
Unmanaged *u = findUnmanaged(WindowMatchPredicated(window));
becomes:
Unmanaged *u = findUnmanaged([window](const Unmanaged *u) {
return u->window() == window;
});
In addition an overload is added which takes the window id to cover
the common case to search for an Unmanaged by its ID. The above example
becomes:
Unmanaged *u = findUnmanaged(window);
The advantage is that it is way more flexible and has the logic what
to check for directly with the code and not hidden in the macro
definition.
As can be seen in [1] the patches to KWin were in CVS HEAD before the
protocol got standardized and it never got any adoption. It's neither in
the NETWM spec, nor implemented in Qt4 nor in Qt5. KWin did not even add
the protocol to the NET::Supported property.
Thus it doesn't make much sense to keep a protocol which nobody speaks.
Still the code around the protocol is kept and also the names are kept.
Only difference is that Client::takeActivity got removed and the code
moved to the only calling place in Workspace. Motivated by that change
the enum defined in utils.h is moved into Workspace, it's turned into
a proper QFlags class and used as a type in the method argument instead
of a generic long.
[1] https://mail.gnome.org/archives/wm-spec-list/2004-April/msg00013.html
REVIEW: 116922
InputRedirection keeps track of the Toplevel which is currently the one
which should get pointer events. This is determined by checking whether
there is an Unmanaged or a Client at the pointer position. At the moment
this is still slightly incorrect, e.g. pointer grabs are ignored,
unmanaged are not checked whether they are output only and input shapes
are not yet tracked.
The pointer events are delivered to the Toplevel as:
* enter
* leave
* move
* button press
* axis event
Nevertheless move events are still generated in InputRedirection through
xcb test for simplicity. They are still send to the root window, so all
windows get mouse move.
Button press and axis are generated only in the implementations of the
event handlers and delivered directly to the window, so other windows
won't see it.
The ActionCollection was only used for two features:
* setting the object name
* finding the action for retrieving it's shortcut
This can also be achieved by just setting the object name and searching
for the children of the Workspace singleton.
This looks mostly like dead code. The change got only emitted by the
KCMKeyboard on save. In ancient times this seems to have caused to
re-read the global shortcuts. Code got commented out during KDE4 times
and after several code refactors all that was left of it was discarding
the user actions menu.
There used to be an own action collection in KDE 3 times for the
block global shortcuts shortcut. But the code ws disabled and by
that I didn't see it during removing the global shortcuts blocking.
And it explains why the global shortcut blocking didn't work.
Method replaces the logic of the macros. The macros are still there
to not need to change all the code. Major difference is that the new
method uses the compile time checked connect syntax.
In case that the window operation results in destroying the window
decoration we need to have the menu closed before the deco gets
destroyed. Otherwise Qt crashes.
Using a QTimer to move the resize/move related code to the end of the
event queue. In case there is another motion event in the queue it will
cancel the timer.
Takes a std::function as argument which allows to pass a lambda function
which gets executed for each client/unmanged:
ws->forEachClient([](Client *client) {
client->releaseWindow();
});
Forwards all xcb events to Workspace::workspaceEvent() which got changed
to process xcb events instead of XEvents. So far all handling is
disabled. Will be re-enabled step by step in the following patches.
This shortcut did not make any sense to me, because you could block the
global shortcuts for KWin, but not re-enable them again. So once blocked,
it was blocked for ever till kwin --replace &.
This is in opposite to the commit message which introduced it
(see BUG 108961).
REVIEW: 110364
Instead of wrapping for exactly one case let's just use the proper
function calls and get rid of all those methods marked as "remove KDE4"
and "backwards compatibility".
REVIEW: 110292
Split out the default and installed colormap from Workspace and put them
into an own class Colormaps.
The method updateColormaps is replaced by a slot update in Colormaps and
activeClientChanged signal is connected to this slot.
At the same time the colormap related code is straight forward ported to
xcb.
REVIEW: 110248
It's not a typical singleton as the ctor is not taking a Workspace* and
needs addtional data to be passed to NETRootInfo.
All the initialization code is moved to RootInfo::create() and the tear-
down code is moved to RootInfo::destroyed(). This includes the support
window which used to be a member of Workspace. It's only needed by
RootInfo, so there is no need to have the ownership inside Workspace.
Instead of using a QWidget we just create a normal window through xcb.
It gets destroyed again in the tear-down code after the RootInfo got
destroyed.
REVIEW: 110238
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
Workspace is hardly interacting with Rules and all the Rules related code
is already in rules.cpp. This highly qualifies to move all the code out
of Workspace and improve the names.
REVIEW: 110207
It's only used from useractions.cpp which means that it's not the best
fit in utils. We can see the problems with it given that it was in an
ifdef and it included quite some headers into everything.
REVIEW: 110189
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
This allows to move the slot to reset the decoration when compositing
got toggled from Workspace to DecorationPlugin and the custom cleanup
is no longer needed.
REVIEW: 109909
There is only one instance hold by Workspace which means it should follow
the common approach with ::self and ::create.
The hasTabBox is completely removed as it's rather useless and the same
as the ifdef around the usages any way.
REVIEW: 109851
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.
REVIEW: 103948
BUG: 91703
BUG: 299245
FIXED-IN: 4.11
- The setting is ignored, the decoration always gets a "true" for it
- moving a maximized window requires breaking a "strong" snap (1/16 of screen height - unless you use quick maximization)
- all snapping is done towards the client, not the frame
- QuickTileMode is exported to the decoration (just as the maximizeMode) so that it can fix the bordersize alongside that.
The hack used to be used to hide windows before they get embedded into
another window. This has been wrong on multiple levels:
1. it does not belong into a window manager - the window should take care
of this by itself
2. Window title is not a proper way to identify windows
3. Using D-Bus to inform an X11 window manager about windows which should
not get managed is rather strange
4. The hack only works with KWin, but not with any other X Window Manager
5. Windows identified with this hack still appear in Alt+Tab, that is
they are managed after all. Only a flicker is suppressed
6. Such windows are shown in the taskbar which nicely illustrates how
wrong a D-Bus call to the window manager is
That the hack has been introduced for Java Applets in KHTML also shows
that this is wrong. Why does Gecko and WebKit not need such a hack? Why
is KHTML tied so closely to X11 and KWin? Having a hack for a technology
which is obsoleted (Java Applets) and shouldn't be used due to security
issues is another reason to no longer support this hack. This usage has
been removed from KHTML as of 67939b1 of kdelibs git repo.
REVIEW: 109450
Following the approach to move out of Workspace what doesn't belong into
Workspace Appmenu support goes into an own class.
This also has the advantage of better compilation with Qt 5 as moc seems
to dislike ifdefs in the slot definitions.
REVIEW: 109497
With Qt5 QCursor does no longer provide ::handle() which was used to
set a cursor on a native XWindow for which we do not have a QWidget.
Also KWin has had for quite some time an optimized version to get the
cursor position without doing XQueryPointer each time ::pos() is called.
These two features are merged into a new class Cursor providing more or
less the same API as QCursor.
In addition the new class provides a facility to perform mouse polling
replacing the implementations in Compositor and ScreenEdges.
For more information about the new class see the documentation for the
new class in cursor.h.
The code is rewritten in a way to replace the local event loop with event
filtering done in the normal way through events.cpp. Therefore instead of
creating a KillWindow whenever it's needed, there is one available in
Workspace which will be reused on next invocation.
The responsible events are passed from events.cpp to KillWindow for
processing.
In order to port the keycode to symbol to XCB, KWin now finds
xcb_keysyms and links it.
To get the right cursor KWin now links the XCursor library which is
unfortunatelly an XLib based library, but there seems to be no XCB
replacement.
The new class FocusChain manages two different kind of focus chains.
First of all there is a most recently used focus chain which is primarily
used for TabBox.
Then there is one focus chain per virtual desktop. These chains are used
to determine which Client needs to be activated when e.g. switching to a
virtual desktop.
The individual chains are implemented as a simple QList of Client* with
the most recently used Client as the last element. That way one can see
it as a LIFO like structure.
The desktop focus chains are internally represented as a hash with the id
of the virtual desktop as the key and a list as described as the value.
FocusChain is a singleton which provides some methods to manipulate the
chains and to get a specific Client for a task (e.g. TabBox).
While splitting out the code some unused code inside TabBox got removed
as well as some activities related code (windows cannot be moved while
switching activities).
REVIEW: 107494
but drop screenedges below the supportWindow instead
that's why it exists, that's deterministic, that's faster
includes adaption to new screenedge and xcb invocation (compared to 4.10)
BUG: 314625
FIXED-IN: 4.10.1
REVIEW: 108867
In fact it already used to be a Singleton as there is just one object
hold by the Singleton Workspace. So let's make it a proper Singleton
following our kind of standard approach of having a ::create factory
method called from Workspace ctor and a ::self to get to the singleton
instance.
This rewrite is mostly motivated by the need to handle multi screen
setups correctly. That is have edges per screen and not for the combined
geometry. Also porting from XLib to XCB has been a motivation for the
rewrite.
The design of the new ScreenEdge handling is described in the
documentation of ScreenEdges in screenedge.h.
In addition the following changes have been performed:
* move configuration from Options to ScreenEdge
* add screen edge information to Workspace::supportInformation (obviously
replaces what had been read from Options)
* have Workspace hold a pointer to ScreenEdges instead of an object
* forward declaration of ScreenEdges in workspaces.h, this explains the
seemingly unrelated changes of just another include in some files
BUG: 290887
FIXED-IN: 4.11
Main motivation for this change except the fact that it doesn't belong
into Workspace is that the screen edges got updated from within setting
the desktop layout which got removed with the introduction of the
VirtualDesktopManager.
The ScreenEdge now keeps some state to be able to correctly unreserve the
electric borders when changes in the configuration are performed. There
is still room for improvement as there are still some deep function calls
from within reconfiguring in Workspace.
REVIEW: 107493
Most recently used virtual desktop chain is only used in the context of
TabBox and therefore moved into this namespace. KWin uses one desktop
chain for each activity. This is mapped by having multiple DesktopChains.
In addition there is a DesktopChainManager which contains all those
chains which are identified by a QString.
The manager gets connected to the signals emitted by VirtualDesktopManager
for changes in virtual desktops and to signals related to Activities
emitted by Workspace. This means the manager is rather generic as it does
not depend on any other components.
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 two methods:
* place
* placeSmart
have only forwarded the call to the Placement object. Now that Placement
is a singleton there is no need to have them. Every user can call them
directly without going over Workspace.
It is more Placement related and does not really fit into geometry given
that it only calls methods on Placement. It probably only was inside
Workspace due to being part of the DBus interface. The DBus methods are
used by external components so it needs to stay.
The DBus Wrapper is now calling the methods on the singleton Placement
directly, so no need in Workspace anymore.
It is not used anywhere inside KWin at all and the DBus method is not
used anywhere inside KDE's repositories (according to lxr). Because of
that marked as deprecated and going to die with Qt 5.
REVIEW: 107406
A decoration can provide the AbilityAnnounceAlphaChannel in addition to
AbilityUsesAlphaChannel. If this ability is provided the decoration can
enable/disable the use of the alpha channel through setAlphaEnabled().
The base idea behind this mechanism is to be able to tell the compositor
that currently alpha is not needed. An example is the maximized state in
which the decoration is fully opaque so that there is no need to use the
translucency code path which would render all windows behind the deco.
In addition also the blur effect honors this setting so that behind a
known opaque decoration no blurring is performed.
Oxygen is adjusted to disable translucency in maximized state and Aurorae
is adjusted to allow themes to enable/disable translucency. For Plastik
translucency and with that also blurring is disabled.
REVIEW: 106810
Nobody is interested in whether the Abilities are supported.
There is one method in KWin core checking for the colors
supported by the currently loaded decoration:
Workspace::decorationSupportedColors
This method is not called from anywhere inside KWin, but is
part of the D-Bus interface, though nobody in KDE's repository
is calling it [1].
As it is part of public API the Abilities are only deprecated
and scheduled for removal with the next big break.
[1] http://lxr.kde.org/search?filestring=&string=decorationSupportedColors
REVIEW: 105785
A script can register a callback through registerUserActionsMenu to be
informed when the UserActionsMenu is about to be shown. This menu calls
the Scripting component to gather actions to add to a Scripts submenu.
The Scripting component now asks all scripts for the actions, which will
invoke the registered callbacks with the Client for which the menu is to
be shown as argument.
The callback is supposed to return a JSON structure describing how the
menu should look like. The returned object can either be a menu item or
a complete menu. If multiple menu items or menus are supposed to be added
by the script it should just register multiple callbacks.
The structure for an item looks like the following:
{
text: "My caption",
checkable: true,
checked: false,
triggered: function (action) {
print("The triggered action as parameter");
}
}
The structure for a complete menu looks quite similar:
{
text: "My menu caption",
items: [
{...}, {...} // items as described above
]
}
The C++ part of the script parses the returned object and generates
either QAction or QMenu from it. All objects become children of the
scripts QMenu provided by the UserActionsMenu.
Before the menu is shown again the existing menu is deleted to ensure
that no outdated values from no longer existing scripts are around. This
means the scripts are queried each time the menu is shown.
FEATURE: 303756
FIXED-IN: 4.10
REVIEW: 106285
Two new interfaces are introduced:
* org.kde.kwin.Compositing
* org.kde.kwin.Effects
The Compositing interface is generated from scriptable elements on the
KWin::Compositor class and the Compositor is exported as /Compositor.
It provides the general Compositing related D-Bus methods like whether
the compositor is active and toggling and so on.
The Effects interface is generated from scriptable elements on the
KWin::EffectsHandlerImpl class and the instance is exported as /Effects.
It provides all the effects related D-Bus methods like loading an effect
or the list of all effects.
This removes the need to have all these methods provided on the global
org.kde.KWin interface. For backwards compatibility they are kept, but
no longer provided by the Workspace class. Instead a new DBusInterface
is generated which wrapps the calls and delegates it to one of our three
related Singleton objects:
* Workspace
* Compositor
* EffectsHandlerImpl
The Compositor class actually behaves like a Singleton so it should be
one. Therefore four static methods are added:
* self() to access the Singleton
* createCompositor() to be used by Workspace to create the instance
* isCreated() to have a simple check whether the Singleton is already
created
* compositing() as a shortcut to test whether the compositor has been
created and is active
The isCreated() check is actually required as especially Clients might
be created and trying to access the Compositor before it is setup.
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
The DBus signal which causes KWin to reinitialize the Compositor
is moved into the Compositor as everything can be handled from
there as well. This comes together with moving the restartKWin
functionality into the Compositor as it is only relevant there.
Restart will only happen if the wrong Qt graphicssystem is used
for the chosen compositing backend.
The Scene has always been created and destroyed inside what is
now the split out compositor. Which means it is actually owned
by the Compositor. The static pointer has never been needed
inside KWin core. Access to the Scene is not required for the
Window Manager. The only real usage is in the EffectsHandlerImpl
and in utils.h to provide a convenient way to figure out whether
compositing is currently active (scene != NULL).
The EffectsHandlerImpl gets also created by the Compositor after
the Scene is created and gets deleted just before the Scene gets
deleted. This allows to inject the Scene into the EffectsHandlerImpl
to resolve the static access in this class.
The convenient way to access the compositing() in utils.h had
to go. To provide the same feature the Compositor provides a
hasScene() access which has the same behavior as the old method.
In order to keep the code changes small in Workspace and Toplevel
a new method compositing() is defined which properly resolves
the state. A disadvantage is that this can no longer be inlined
and consists of several method calls and pointer checks.
All Workspace functions which were implemented in the file composite.cpp
were moved to an own class Compositor. The header entries were moved as well.
All functions calls are updated.
