* Aurorae needs to pass QVariantList args to parent Decoration
* DecorationBridge implementation needs to be a KWIN_SINGLETON
* DecorationBridge needs to be passed with args to created Decoration
The idea behind the ThemeFinder is to expose a way for a configuration
module to find all themes. The API is not yet finalized, thus it's just
a QObject with a Q_PROPERTY themes of type QVariantMap with key being
the user visible name and value being the internal theme name.
The ThemeFinder will have to be moved to KDecoration library.
The json metadata provides a "themeListKeyword" which is used as the
keyword to the KPluginFactory.
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.
The Text.horizontalAlignment property expects AlignHCenter instead of
AlignCenter. By not using AlignHCenter the centering broke when a window
got maximized.
It's possible that the rendering thread is still writing to the
buffer and if we destroy the buffer before it's finished KWin is going
to crash. So let's mutex lock the dtor to ensure that the rendering
thread finishes before we tear down the client.
BUG: 336950
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.
The position passed to core didn't take care of padding and that position
passed to decorationPos caused completely broken resize/moving behavior.
E.g. resize was started where it should have been moving, or jumping of
position when starting moving.
REVIEW: 118803
The KWin::Borders element is provided by an extension plugin. The reason
for that is to be able to use it from e.g. the kcm or Plasmate without
needing to compile the code in.
But this results in Aurorae itself not being able to access the element.
The solution is to first load our decoration plugin and afterwards
register the borders element again with the version compiled in from
Aurorae.
With that we can now read all borders and paddings without using
properties. Also we could connect to change signals and have the borders
and padding handling completely stateful. Might be an idea for extending
the decoration library...
Qml based Aurorae themes can provided a ui file which gets loaded at
runtime. Obviously such a ui file is not translated. This introduces
quite a hack to load the translated strings.
First of all a new property is added to the service file for
specifying the translation domain to be used for the config UI. If
such a translation domain is set we extract all string properties of
the loaded UI and pass them through ki18nd.
This seems to fix the crash which could happen when closing a window. At
least the kwindowsystem unit tests no longer crash KWin (it was very
reliable before).
BUG: 332091
* A KDecoration needs to include json metadata
* A KDecoration needs to be installed to kwin/kdecorations
* Aurorae and Oxygen adjusted
* kcmdeco locates all decorations through the KPluginTrader
* libkdecoration uses KPluginTrader to find the plugin
* config plugins also need to include json metadata with
X-KDE-PluginInfo-Name being the same as the decoration
* config plugins need to get installed to kwin/kdecorations/config
* kcmdeco locates the config plugin for a deco through the name
and KPluginTrader
REVIEW: 116765
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
This simplifies the plugin loading. Decorations just have to use
K_PLUGIN_FACTORY to specify how the KDecorationFactory needs to be
created. The KWIN_DECORATION macro is adjusted to generate the
boiler plate code, but it now needs to specify the name for the
pluginfactory and the KDecorationFactory.
This also transits the decoration abi version check to use
K_EXPORT_PLUGIN_VERSION which also simplifies the loading.
As a result the complete canLoad handling in DecorationPlugins is
removed.
REVIEW: 115930
They're not needed anymore, and break my build directory from time to time.
If this commit breaks your compilation, clean your build directory (or at
least the plasma and kwin subdirectories).
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.
Fixes incorrect button color. DecorationOptions and PlastikButton are
both connected to decoration.active and the button gets invoked first,
thus the titleBarColor is still for the previous state. This was fun!
This is a temporary solution! A proper solution needs changes in
libkdecoration and paint redirector.
The hack redirects the rendering into an FBO. After each rendering we
get a QImage from the FBO and store that in a buffer. As we unfortunately
do not know what changed, we schedule a complete update on the deco's
widget. Once we get the paint event we just render the buffer on the
widget. And thus we have copied the content to a place where it
integrates with the paint redirector.
As already written, this is a horrible hack and I'm not proud about it.
There are just too many copies involved.
So how to improve?
* deco should be able to just provide a QImage to the PaintRedirector
without the paint to the QWidget.
* only do the FBO -> QImage step if it is needed by the compositor, that
is compress the events
* for OpenGL compositing it would be totally awesome if we could just
make the contexts sharing so that we can just reuse the texture from
the FBO directly.
Major transition to render using QtQuick 2. This means the actual
rendering needs a QQuickWindow which we embed into a QWidget container.
Not an optimal solution, deco API should offer to operate on QWindow.
For non-composited the decoration gets rendered but for composited
rendering the paint redirector is broken. There are no paint events on
the main QWidget to intercept and thus the redirection doesn't work.
* KDE/4.11:
Remove assertion in KDecorationUnstable's constructor.
SVN_SILENT made messages (.desktop file)
Cursor Theme KCM: Show correct resize cursor in preview for themes without a file called "size_fdiag"
Fixed missing signal/slot connection:
Fix zoom effect cursor position on initial zoom in.
SVN_SILENT made messages (.desktop file)
Don't show borders for a maximized Laptop client
Always use PositionCenter for maximized windows
Fix click on trash plasmoid when on desktop and widgets are unlocked
Conflicts:
kwin/clients/aurorae/src/aurorae.cpp
kwin/libkdecorations/kdecoration.cpp
plasma/desktop/applets/trash/trash.cpp
plasma/desktop/toolboxes/plasma-toolbox-desktoptoolbox.desktop
plasma/desktop/toolboxes/plasma-toolbox-paneltoolbox.desktop
plasma/generic/wallpapers/color/plasma-wallpaper-color.desktop
plasma/generic/wallpapers/image/plasma-wallpaper-image.desktop
The logic to use $INCLUDE_INSTALL_DIR/KDE doesn't work there, since the
plasma includes land in a different path on the jenkins setup. Let's see
if this fixes it.
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.
Replaces the pure virtual method which the Decoration had to
implement. Instead the Decoration can now connect to the signal.
For KCommonDecoration there is no change at all except that the
invoked method is turned into a slot.
The property is of type bool and maps to isMaximized and not to
maximizeMode.
Replaces the pure virtual method which the Decoration had to
implement. Instead the Decoration can now connect to the signal.
For KCommonDecoration there is no change at all except that the
invoked method is turned into a slot.
Replaces the pure virtual method which the Decoration had to
implement. Instead the Decoration can now connect to the signal.
For KCommonDecoration there is no change at all except that the
invoked method is turned into a slot.
Replaces the pure virtual method which the Decoration had to
implement. Instead the Decoration can now connect to the signal.
For KCommonDecoration there is no change at all except that the
invoked method is turned into a slot.
Also isOnAllDesktop property is added using the same changed
signal as desktop property.
Replaces the pure virtual method which the Decoration had to
implement. Instead the Decoration can now connect to the signal.
For KCommonDecoration there is no change at all except that the
invoked method is turned into a slot
Replaces the pure virtual method which the Decoration had to
implement. Instead the Decoration can now connect to the signal.
For KCommonDecoration there is no change at all except that the
invoked method is turned into a slot.
