For all the decoration updates called from Client into the decoration we
also have a signal being emitted. So turning the pure virtual public
functions into slots means we can just connect our existing signals and
get rid off the deep function calls.
The keepAbove/Below signals are changed to take a boolean argument as
needed by KDecoration and a few emitted signals are moved to a better
fitting location.
REVIEW: 110335
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
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
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.
Instead of calculating the screen number each time screen() is invoked,
the screen number gets stored in a private member variable and evaluated
whenever either the screen count changes or the Toplevel's geometry
changes. During move/resize the screen property doesn't get updated. The
update is delayed till the end of the move/resize operation.
REVIEW: 109715
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.
not that i really like using QWidgetAction, but it'll
prevent the popup from autoclosing.
Introduce activityUpdateBlocking to prevent users from
removing the popup under their fingertips
BUG: 283309
FIXED-IN: 4.10.2
REVIEW: 107762
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
Should shaded windows be iconic?
I don't know. Apparently nobody does. (google found me discussions but no conclusion)
OpenBox, Metacity and Compiz set shaded Windows iconic, Sawfish and IceWM don't.
Either way kwin presently sets shaded windows iconic when you map them (client.cpp, void Client::map(allowed_t)) so to remain consistent with ourselves and half of the other WMs i set it.
Otherwise it should not be set when unshading a window
(no justification but noteworthy: the bug reporter seems to intend to pause expensive painting when the window is iconic and in that regard it's oc better to have it for shaded windows)
BUG: 317025
FIXED-IN: 4.11
REVIEW: 109593
PaintRedirector is turned into an abstract class providing a factory
method which returns either an instance of
* OpenGLPaintRedirector
* NativeXRenderPaintRedirector
* RasterXRenderPaintRedirector
OpenGLPaintRedirector is basically doing exactly the same as the parent
class used to do before. Though the idea is to extend the functionality
to have the PaintRedirector write directly into OpenGL textures to limit
copying the complete decorations.
NativeXRenderPaintRedirector is similar to OpenGLPaintRedirector by
rendering into a QPixmap and providing the pictureHandle for the QPixmap
to SceneXRender.
RasterXRenderPaintRedirector is providing the functionality for the case
that the QPixmap/XPixmap relationship is not present. From the QPixmap
containing the pending decoration paint a QImage is created and then the
relevent parts are copied directly into the decoration pixmap.
REVIEW: 109074
Where possible it is changed to Cursor::pos(), where we cannot use the
Cursor class (e.g. Aurorae) we can at least try to limit the usage to
prevent roundtrips to the X server.
REVIEW: 109178
The Client::cursor property is changed from QCursor to Qt::CursorShape
and renamed to m_cursor (as all usages are adjusted).
This property is mostly used to define the cursor on e.g. the extended
deco border window. To make this easier a XDefineCursor replacement is
added to xcbutils.h both as a static method and as a member function to
Xcb::Window.
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
Using Xcb::Window to manage the xcb_window_t and simplify the code - no
longer need to check whether the input_window is valid before calling e.g.
map, as that's handled in Xcb::Window.
One XLib usage for setting cursor is still present. This will be ported
once all the QCursor::handle() get removed.
REVIEW: 108771
The extension handling is removed from kwinglobals and moved into the
xcbutils in KWin core in namespace KWin::Xcb. The motivation for this
change is that the Extensions are only used in KWin core and are marked
as internal. So there is no need to have them in the library.
What remains in Extensions are the non-native pixmaps. This will be
removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap.
The remaining code in kwinglobals also still initialize the XLib versions
of extensions emitting events. It seems like there are no XEvents emitted
if not done so even if the extension is correctly initialized with xcb.
This needs to be removed once the event handling is ported over to xcb.
REVIEW: 107832
Most windows use the hostname in WM_CLIENT_MACHINE, but there are windows
using the FQDN (for example libreoffice). So instead of "foo" it is
"foo.local.net" or similar. The logic so far has been unable to properly
determine whether windows with FQDN are on the local system.
In order to solve this problem the handling is split out into an own
class which stores the information of hostname and whether it is a local
machine. This is to not query multiple times. To determine whether the
Client is on the local system getaddrinfo is used for the own hostname
and the FQDN provided in WM_CLIENT_MACHINE. If one of the queried
names matches, we know that it is on the local machine. The old logic to
compare the hostname is still used and getaddrinfo is only a fallback in
case hostname does not match.
The problem with getaddrinfo is, that it accesses the network and by that
could block. To circumvent this problem the calls are moved into threads
by using QtConcurrent::run.
Obviously this brings disadvantages. When trying to resolve whether a
Client is on the local machine and a FQDN is used, the information is
initially wrong. The new ClientMachine class emits a signal when the
information that the system is local becomes available, but for some
things this is just too late:
* window rules are already gathered
* Session Management has already taken place
In both cases this is an acceptable loss. For window rules it just needs
a proper matching of the machine in case of localhost (remote hosts are
not affected). And the case of session management is very academic as it
is unlikely that a restoring session contains remote windows.
BUG: 308391
FIXED-IN: 4.11
REVIEW: 108235
Thomas Lübking