Accepting the mouse events breaks moving the window by dragging
the title bar. The reason is that it eats the mouse event and
by that never reaches KWin core to perform the movement.
Other mouse buttons need to be accepted for handling the window
operations. Also we need to listen in general to left mouse
button for the double click operation.
BUG: 304249
FIXED-IN: 4.9.1
REVIEW: 105784
Unfortunately QtQuick 1 does not provide a way to receive Wheel
events. But the window decoration needs to pass wheel events on
the titlebar to KWin core.
In order to process also Wheel Events in Aurorae an event
filter is installed on the widget and in case the mouse positon
is on the title bar the titlebarMouseWheelOperation is invoked.
BUG: 304248
FIXED-IN: 4.9.1
REVIEW: 105801
This is an issue we already had in the past with Aurorae. When
closing a window the graphics scene crashes because the deco
gets destroyed before the code in the graphics scene finished
the execution.
With the port to QML this seemed to be fixed unless as it turns
out it throws an XIO error on closing:
fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
This can be triggered using glxgears. Closing glxgears would
reliable crash Aurorae. To circumvent this issue we have to
delay the close by one event cycle using QMetaObject's
invokeMethod with a Qt::QueuedConnection.
This has also to be done in the useractions menu as the menu
is still open when the window closes causing the same problem
inside Aurorae.
BUG: 303450
FIXED-IN: 4.9.0
Reviewed-By: Thomas Lüking
According to Nuno it's much better to define the animations in
a Behavior element as that is together with the element which
gets animated.
Also he recommends to not use states but just property binding
for the properties which are animated in the Behavior.
And I must admit that this produces cleaner code, though the
conditions are now scattered all over the source code and not
nicely put together in one state section. Let's just hope I got
the logic right.
Well seems like it is useful to go to a QML training, at least
it made me aware of my State definitions are not good and then
talking to Nuno and giving a try to his recommendations.
REVIEW: 105426
Option is called "CloseFromMenuButton"
It is false by default.
To turn it on, add
CloseFromMenuButton=true
in [Windeco] section of $HOME/.kde4/share/config/oxygenrc.
Note that it results in poor usability of the menu button, if enabled.
CCBUG: 301237
Static getters for each default value added which are used in
ctor to initialize the class members and in the load for
readEntry's default value.
REVIEW: 104994
The unescaped tags are interpreted as HTML by Aurorae decorations
and the KWin killer. Escaping the tags ensures that the text is not
rendered incorrectly.
BUG: 293657
FIXED-IN: 4.9.0
REVIEW: 104989
The general idea is: single click opens menu, double click closes
the window. The problem is that the when the menu is opened after
the single click, the menu will eat the second click. So double
click will not work.
This commit brings back the workaround from Aurorae2. The clicked
event is not used at all, but we start a timer on the press event
with the doubleClickInterval. If no double click appears during the
interval we open the menu, if there is a double click we close the
window.
The downside of this approach is that there is a slight delay between
clicking the menu button and the menu appearing. For that the right
click behavior is unchanged. That is right clicking opens the menu
instantly and double click to close it, is broken.
Buttons are exported as a global "options" in the factory.
Additionally the theme's buttons are also exported. The thme decided
based on the custom button positions property which one to use.
In the kcm the button options are also exported.
Each decoration gets a graphicsview and scene instead and a declarative
item is created for each decoration.
There's probably still room for improvments. E.g. never render the
scene onto the widget but directly into the textures?
Martin Gräßlin