kwin/clients/aurorae/src/qml/DecorationButton.qml

125 lines
4.9 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
Item {
id: button
property int buttonType : DecorationOptions.DecorationButtonNone
property bool hovered: false
property bool pressed: false
property bool toggled: false
enabled: {
switch (button.buttonType) {
case 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
return decoration.client.closeable;
case DecorationOptions.DecorationButtonMaximizeRestore:
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
return decoration.client.maximizeable;
case DecorationOptions.DecorationButtonMinimize:
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
return decoration.client.minimizeable;
case DecorationOptions.DecorationButtonExplicitSpacer:
return false;
default:
return true;
}
}
MouseArea {
anchors.fill: parent
acceptedButtons: {
switch (button.buttonType) {
case DecorationOptions.DecorationButtonMenu:
return Qt.LeftButton | Qt.RightButton;
case DecorationOptions.DecorationButtonMaximizeRestore:
return Qt.LeftButton | Qt.RightButton | Qt.MiddleButton;
default:
return Qt.LeftButton;
}
}
hoverEnabled: true
onEntered: button.hovered = true
onExited: button.hovered = false
onPressed: button.pressed = true
onReleased: button.pressed = false
onClicked: {
switch (button.buttonType) {
case DecorationOptions.DecorationButtonMenu:
// menu
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
decoration.requestShowWindowMenu();
break;
case DecorationOptions.DecorationButtonApplicationMenu:
// app menu
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
// decoration.appMenuClicked();
break;
case DecorationOptions.DecorationButtonOnAllDesktops:
// all desktops
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
decoration.requestToggleOnAllDesktops();
break;
case DecorationOptions.DecorationButtonQuickHelp:
// help
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
decoration.requestContextHelp();
break;
case DecorationOptions.DecorationButtonMinimize:
// minimize
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
decoration.requestMinimize();
break;
case DecorationOptions.DecorationButtonMaximizeRestore:
// maximize
decoration.requestToggleMaximization(mouse.button);
break;
case DecorationOptions.DecorationButtonClose:
// close
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
decoration.requestClose();
break;
case DecorationOptions.DecorationButtonKeepAbove:
// keep above
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
decoration.requestToggleKeepAbove();
break;
case DecorationOptions.DecorationButtonKeepBelow:
// keep below
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
decoration.requestToggleKeepBelow();
break;
case DecorationOptions.DecorationButtonShade:
// shade
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
decoration.requestToggleShade();
break;
}
}
onDoubleClicked: {
if (button.buttonType == DecorationOptions.DecorationButtonMenu) {
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
decoration.requestClose();
}
}
Component.onCompleted: {
switch (button.buttonType) {
case DecorationOptions.DecorationButtonOnAllDesktops:
// all desktops
button.toggled = Qt.binding(function() { return decoration.client.onAllDesktops; });
break;
case DecorationOptions.DecorationButtonKeepAbove:
button.toggled = Qt.binding(function() { return decoration.client.keepAbove; });
break;
case DecorationOptions.DecorationButtonKeepBelow:
button.toggled = Qt.binding(function() { return decoration.client.keepBelow; });
break;
case DecorationOptions.DecorationButtonShade:
button.toggled = Qt.binding(function() { return decoration.client.shaded; });
break;
}
}
}
}