The porting to Qt5 broke the timestamp handling in many areas. A deeper
look into Qt's xcb plugin shows that the appTime handling is not
sufficient for KWin's need. E.g. the time is only updated in response to
a property notify event if it's for a Qt created window, which is hardly
ever the case in KWin. Another example is that key press/release events
never updated the appTime.
As the functionality in Qt is rather trivial we can do the timestamp
handling ourselves. We filter all events anyway and it is slightly faster
as we don't have to go through the QPA interface any more.
REVIEW: 122636
The Xcb::Property can wrap the xcb_get_property call and provides
convenient access methods to read the value of the reply with checks
applied. For this it provides a templated ::value method for reading a
single value or reading an array. There's also a ::toBool and
::toByteArray which performs the conversion directly with default values
for the type and format checks.
Xcb::TransientFor is changed to be derived from Property instead of
Wrapper directly, so that the reading of the property value can be
shared.
Xcb::StringProperty is a convenient wrapper derived from Property to
handle the reading of a string property providing a cast to QByteArray
operator. This replaces the ::getStringProperty from utils. Though the
separator functionality from ::getStringProperty is not provided as that
is only used in one function and handled there.
All the custom usages of xcb_get_property or getStringProperty are
replaced to use this new wrapper. That simplifies the code and ensures
that all properties are read in the same way.
REVIEW: 117574
Only delegated to Cursor::pos() anyway, so let's just use that directly.
Fixes the annoyances of having to mock it in the unit tests which include
utils.cpp.
REVIEW: 116900
During startup we only create the request, the reply will be fetched
once the atom is needed.
To make proper use of this async behavior the creation of Atoms is
moved directly to the claim of the manager selection, so they can be
fetched while we wait for the previous manager selection to give up
on it.
Requires 9c45260942c0ee32267e651d981bfa33a6acb64d from qtx11extras.
Note: this does not fully replace the functionality which we used to
have. The event queue is not yet searched for the first even with a
timestamp.
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
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
Many headers included KLocale to use i18n and co. But those methods are
defined in KLocalizedString and not in KLocale.
With KF5 klocale.h does no longer include KLocalizedString causing lots
of compile errors.
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.
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
where the titlebar is still clickable even if it is outside the normal
work area. When struts are added or removed only move the windows that
cover the same area, leave all others untouched. If a strut is removed
on a xinerama screen that is not on the edge of the full desktop area
prevent the windows from being moved offscreen. Prevent struts/panels
from interfering with the movement of windows on other xinerama screens.
BUG: 74559
BUG: 90833
BUG: 160068
svn path=/trunk/KDE/kdebase/workspace/; revision=927466
@Lubos: Please have a look at commit 863096 too. I accidently commited a
part of this part there. Please have a look at the todo "Add the window
title" and possibly implement it. That would look much nicer in the global
shortcuts kcm.
Btw. There are two shortcuts dialogs in kwin. I haven't change the other
one (kwinrules) because it look it works better with KKeySequenceWidget
doing the message box.
CCMAIL:l.lunak@kde.org
svn path=/trunk/KDE/kdebase/workspace/; revision=863292
Also slightly redo the #define's for effects, now it's:
- #ifdef KWIN_HAVE_COMPOSITING to check whether there's any compositing support at all
- #ifdef KWIN_HAVE_OPENGL_COMPOSITING to check for OpenGL-based compositing
- #ifdef KWIN_HAVE_XRENDER_COMPOSITING the same for XRender
CCMAIL: kwin@kde.org
svn path=/trunk/KDE/kdebase/workspace/; revision=749628
being v2+ (right now it says just GPL, which according to GPL itself
means any GPL). Decoration clients will come later.
CCMAIL: kwin@kde.org
svn path=/trunk/KDE/kdebase/workspace/; revision=742302
Now, since I don't see any shortcuts-related hacks, why exactly am I supposed
to contact you?
CCMAIL: ahartmetz@gmail.com
BUG: 151642
svn path=/trunk/KDE/kdebase/workspace/; revision=731744
