kwin/clients/aurorae/themes/plastik/package/contents/ui/PlastikButton.qml

162 lines
6.5 KiB
QML
Raw Normal View History

/********************************************************************
Copyright (C) 2012 Martin Gräßlin <mgraesslin@kde.org>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
*********************************************************************/
import QtQuick 2.0
import org.kde.kwin.decoration 0.1
import org.kde.kwin.decorations.plastik 1.0
DecorationButton {
id: button
function colorize() {
var highlightColor = null;
if (button.pressed) {
if (button.buttonType == DecorationOptions.DecorationButtonClose) {
Initial port of Aurorae to KDecoration2 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.
2014-10-24 11:48:31 +00:00
highlightColor = colorHelper.foreground(decoration.client.active, ColorHelper.NegativeText);
} else {
highlightColor = options.titleBarColor;
}
highlightColor = colorHelper.shade(highlightColor, ColorHelper.ShadowShade);
highlightColor = colorHelper.multiplyAlpha(highlightColor, 0.3);
} else if (button.hovered) {
if (button.buttonType == DecorationOptions.DecorationButtonClose) {
Initial port of Aurorae to KDecoration2 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.
2014-10-24 11:48:31 +00:00
highlightColor = colorHelper.foreground(decoration.client.active, ColorHelper.NegativeText);
} else {
highlightColor = options.titleBarColor;
}
highlightColor = colorHelper.shade(highlightColor, ColorHelper.LightShade, Math.min(1.0, colorHelper.contrast + 0.4));
highlightColor = colorHelper.multiplyAlpha(highlightColor, 0.6);
}
if (highlightColor) {
button.surfaceTop = Qt.tint(button.baseSurfaceTop, highlightColor);
button.surfaceBottom = Qt.tint(button.baseSurfaceBottom, highlightColor);
highlightColor = colorHelper.multiplyAlpha(highlightColor, 0.4);
button.conturTop = Qt.tint(button.baseConturTop, highlightColor);
button.conturBottom = Qt.tint(button.baseConturBottom, highlightColor);
} else {
button.conturTop = button.baseConturTop;
button.conturBottom = button.baseConturBottom;
button.surfaceTop = button.baseSurfaceTop;
button.surfaceBottom = button.baseSurfaceBottom;
}
}
property real size
property color conturTop
property color conturBottom
property color surfaceTop
property color surfaceBottom
property color baseConturTop: colorHelper.shade(options.titleBarColor, ColorHelper.DarkShade, colorHelper.contrast - 0.4)
property color baseConturBottom: colorHelper.shade(options.titleBarColor, ColorHelper.MidShade)
property color baseSurfaceTop: colorHelper.shade(options.titleBarColor, ColorHelper.MidlightShade, colorHelper.contrast - 0.4)
property color baseSurfaceBottom: colorHelper.shade(options.titleBarColor, ColorHelper.LightShade, colorHelper.contrast - 0.4)
Behavior on conturTop {
ColorAnimation { duration: root.animateButtons ? root.animationDuration : 0 }
}
Behavior on conturBottom {
ColorAnimation { duration: root.animateButtons ? root.animationDuration : 0 }
}
Behavior on surfaceTop {
ColorAnimation { duration: root.animateButtons ? root.animationDuration : 0 }
}
Behavior on surfaceBottom {
ColorAnimation { duration: root.animateButtons ? root.animationDuration : 0 }
}
width: size
height: size
Rectangle {
radius: 2
smooth: true
anchors.fill: parent
gradient: Gradient {
GradientStop {
position: 0.0
color: button.conturTop
}
GradientStop {
position: 1.0
color: button.conturBottom
}
}
Rectangle {
radius: 2
smooth: true
anchors {
fill: parent
leftMargin: 1
rightMargin: 1
topMargin: 1
bottomMargin: 1
}
gradient: Gradient {
GradientStop {
position: 0.0
color: button.surfaceTop
}
GradientStop {
position: 1.0
color: button.surfaceBottom
}
}
}
}
Item {
property int imageWidth: button.width > 14 ? button.width - 2 * Math.floor(button.width/3.5) : button.width - 6
property int imageHeight: button.height > 14 ? button.height - 2 * Math.floor(button.height/3.5) : button.height - 6
Initial port of Aurorae to KDecoration2 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.
2014-10-24 11:48:31 +00:00
property string source: "image://plastik/" + button.buttonType + "/" + decoration.client.active + "/" + ((buttonType == "A") ? decoration.client.maximized : button.toggled)
anchors.fill: parent
Image {
id: shadowImage
x: button.x + button.width / 2 - width / 2 + 1
y: button.y + button.height / 2 - height / 2 + 1
source: parent.source + "/true"
width: parent.imageWidth
height: parent.imageHeight
sourceSize.width: width
sourceSize.height: height
visible: !button.pressed
}
Image {
id: image
x: button.x + button.width / 2 - width / 2
y: button.y + button.height / 2 - height / 2 + (button.pressed ? 1 : 0)
source: parent.source
width: parent.imageWidth
height: parent.imageHeight
sourceSize.width: width
sourceSize.height: height
}
}
Component.onCompleted: {
colorize();
if (buttonType == DecorationOptions.DecorationButtonQuickHelp) {
Initial port of Aurorae to KDecoration2 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.
2014-10-24 11:48:31 +00:00
visible = Qt.binding(function() { return decoration.client.providesContextHelp});
}
if (buttonType == DecorationOptions.DecorationButtonApplicationMenu) {
Initial port of Aurorae to KDecoration2 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.
2014-10-24 11:48:31 +00:00
// visible = decoration.appMenu;
visible = false;
}
}
onHoveredChanged: colorize()
onPressedChanged: colorize()
Connections {
Initial port of Aurorae to KDecoration2 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.
2014-10-24 11:48:31 +00:00
target: decoration.client
onActiveChanged: button.colorize()
}
Connections {
target: options
onColorsChanged: button.colorize();
}
}