Just using KWindowInfo ctor. In one case in appmenu two usages of
KWindowInfo are merged into one KWindowInfo. And in KWindowList a
usage of adding the KWindowInfos into a list got removed.
Use base_width/base_height if provided by the application and fallback to
min_width/min_height only if not (according to ICCCM 4.1.2.3).
This fixes long standing bug with shrinking gnome-terminal window.
REVIEW: 115396
Problem description: if a window decoration is in the screenedge
(not really unlikely for maximized windows) we either did not get
mouse events to the decoration or the screenedge window. E.g. the
enter event didn't reach the approach window which means it doesn't
get unmapped and thus the motion events in that area are not passed
to the decoration below. The same happened for the screenedge window,
the enter event was just not delivered if there is a window decoration
in the edge.
To solve this problem we listen for motion events in the approach and
the edge window and pass them from the event filter to the screen edges.
If one of our windows contains that the position of the motion event
we trigger the edge just in the same way as we do with the enter event.
The reason for this change is that the default ctor of KWindowInfo
creates a broken object. Calling any method in it will result in a
crush. Thus it is scheduled for removal in kwindowsystem framework
causing this code to no longer compile.
The solution is to use a pointer and set it to null as long as the
window has not been detected yet.
This is the same change as done for kcm kwinrules. And here we se
why copying code is bad ;-)
app_noborder shall be the determined noborder (shape, type)
but relevant noborder shall be determined by rules and respect the
motif hint
BUG: 330573
FIXED-IN: 4.11.6
REVIEW: 115402
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.
They have been unmaintained for a long time and nobody stepped up to
port them to the changes in the decoration API. If at some time someone
wants to bring them back it's still in the git history.
This caused a crash with Qt 5.3 dev branch as the widgets are null
before setupUi is called. Might be a bug in Qt but still it makes
sense to first call setupUi and then do further changes to the Ui.
The reason for this change is that the default ctor of KWindowInfo
creates a broken object. Calling any method in it will result in a
crush. Thus it is scheduled for removal in kwindowsystem framework
causing this code to no longer compile.
The solution is to use a pointer and set it to null as long as the
window has not been detected yet. To ensure that this doesn't fail
badly an assert is added to the getter in DetectWidget.
avoiding the blocking swapinterval detection causes
issues in the timing strategy and prevents protection
against CPU overload on the nvidia blob
BUG: 329821
FIXED-IN: 4.11.6
REVIEW: 115306
By setting the X property _KDE_NET_WM_SKIP_CLOSE_ANIMATION to 1 a window
can request to be excluded from any close animation. This property is
read in Toplevel, so that it is available to both Client and Unmanaged.
If the window has this property set the Scene suppresses the paintWindow
loop of the Deleted. Thus no effect needs to be adjusted. But an effect
using drawWindow directly would still be able to render the Deleted as
there is no suppression.
Furthermore the property is passed to the EffectWindow so that an
Effect can make use of this functionality and not start the animation
in the first place.
REVIEW: 115288
CCBUG: 279615
Backported from 9497b4ddb681ac50dbe9c015e05a3f12fd496da8
