So far we manually updated the toggled state depending on the button
type and the corresponding client property. This had an error sneaked
in for onAllDesktops: it was bound to desktop change instead of on all
desktop change causing the button to not reflect the state correctly.
To prevent such errors it's now setup to a property binding to the
client's state directly.
BUG: 354702
FIXED-IN: 5.4.3
REVIEW: 125917
DecorationShadow is supported through using the padding values. The
window becomes larger by the padding and gets positioned accordingly.
This requires to translate all mouse events.
The DecorationShadow is just using the complete image, which is kind of
a memory waste, but at least the SVG based Aurorae doesn't provide us
better information (might be added, but would probably need changes in
the theme).
For switching back to non-compositing we recreate the QuickWindow. It's
not fortunate, but as long as we do not yet have the render control it's
needed.
The port to KDecoration2 means quite some changes in the way how Aurorae
works. First of all: the theme to load is passed to the Deocoration ctor
and not searched for by Aurorae itself.
The rendering mechanismn didn't change significantly yet. It's still
rendering to an FBO and passing the image on. This needs some further
work as KDecoration2 does not support the padding any more. So all
themes using shadow are currently broken.
Another big change is the way how the rendering scene is constructed
and used. KDecoration2 doesn't want the the Decoration to be a native
window. But for being able to render a QtQuick scene at all we need a
QQuickWindow. Thus it creates a window parented to the decoration id,
but not accepting any input event. Input is nowadays controlled from
the outside: events are passed into the Decoration, so we don't want
the QtQuick window intercepting events.
In case of non-composited the normal FBO mechanism doesn't work and
Aurorae just renders to the QQuickWindow directly. This could use
some optimization in the decoration renderer in KWin core to not even
try to perform the normal rendering. On the other hand it's probably
too much a hassle for the use case.
The rendering architecture might hopefully be improved with Qt 5.4
and the new QQuickRenderControl class.
The QQuickWindow also exposes a problem for preview in the
kdecoration-viewer and the future KCM: we don't want a different
window, but best would be to get to the QML scene directly. A small
hack is added to have the previewers set a "visualParent" which Aurorae
uses to parent the QML scene to without the need to create a
QQuickWindow.
Seems like porting to new infrastructure was incomplete. The
MaximizeRestore button consists of two buttons on top of each other with
an own mouse area in each and both always visible. This means the restore
button was stealing the mouse events of the maximize button breaking
maximization.
The solution is to have an additional MouseArea which controls the whole
button making the two button types just visualization.
Looks like this completely broke in Qt. The groups are all placed at
0/0 if there is an animation defined and the complete layout is broken.
The animation is not that useful in fact so no big loss.
To increase consistency with other decorations and because it changes
the behavior of the menu button in an unexpected way we default to
double click menu button doesn't close the window.
BUG: 331462
FIXED-IN: 5.0
REVIEW: 116716
Defines the DecorationButton type in DecorationOptions (needs to be
re-defined due to QML limitations) and exports the buttons as a
QList<int> property (again QML limitations).
All QML files are switched from string to the new enum type.
Needed for getting proper previews in the QtQuick 2 based kcm.
Obviously this breaks Aurorae as Aurorae is not yet migrated to
QtQuick 2. But there is no more broken than broken anyway.
The Borders element provides the four properties:
* left
* right
* top
* bottom
And is used directly in Decoration for all the different kind of settings
following this pattern:
* normal borders
* maximized borders
* padding
* extended borders
These properties replace the existing used borderLeft & co. This makes
the code in the C++ side easier as the various border elements can now be
read with a shared implementation.
The Borders provide some convenient methods to set the sizes of the
borders. E.g. it's possible to just set the side borders to a specific
value. This should simplify the implementation of the no-side-borders
feature in new decoration.
The aurorae qml and plastik are adjusted to use the new way. Existing
3rd party decorations would break, but there's a good reason why there's
no documentation for QML based decorations ;-)
REVIEW: 108436
Aurorae Themes can make use of the extended borders feature to allow
resizing outside the window decoration area. So far only Plastik makes
use of it in the Tiny border case.
This should be extended in future by adding generic NoSideBorders and
NoBorders sizes as used by Oxygen.
FEATURE: 308992
FIXED-IN: 4.11
REVIEW: 107936
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
A component has the advantage that the width property can depend from
other properties. This does not work with the previous on the fly
construction as the width does not update when the referenced property
changes.
In the maximized state the enabled borders were still enabled causing
the actual borders to be still shown. In addition the padding is not
adjusted to be 0. This is done in the C++ part is it does not make any
sense to have shadows being thrown to another screen for a maximized
window.
REVIEW: 106576
BUG: 307365
FIXED-IN: 4.9.2
For each theme the setting can be enabled individually with the
default being enabled by default. It is completely handled
inside the MenuButton QML component so each QML theme benefits
from the option automatically, too.
BUG: 301327
FIXED-IN: 4.10
REVIEW: 106160
The generic QML components from Aurorae are split out into an
own declarative plugin. In addition two new helper classes are
added to this plugin:
* A ColorHelper to map a few function of KColorSheme and making
it possible to actually work with colors in QML. The need
emerged from trying to port Plastik to QML which makes strong
use of color shading.
* A DecorationOptions class which is a wrapper around KWin's
KDecorationOptions but in a more useable way for QML. The
various options are provided as properties and the value of
the properties changes automatically depending on whether the
decoration is active or inactive.
Aurorae itself is not yet adjusted to these changes, but it
should also be adjusted as some of the options are currently
exported in the factory and the factory is injected into the
Aurorae QML decoration.
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
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
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.
Switches to the explicit maximized decoration element and animates
the button groups and caption.
Legacy support for just the centered element is still missing. Unsure
if it should be added or if it makes sense to break compatibility here.
