* 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
The option changes the behavior of the menu button, thus we should point
out to the user that the behavior changes.
This is only done for Auroae configurations as other decorations have to
take care about it themselves.
CCBUG: 331462
REVIEW: 116715
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
In KCommonDecoration the OnAllDesktops button gets hidden or shown
depending on the number of desktops. For that KDecoration is extended
by a new property which delegates to the bridge to return whether
onAllDesktops is available. In KWin Core this is implemented using
the number of desktops.
FEATURE: 321611
FIXED-IN: 5.0.0
REVIEW: 116076
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
The ::palette() in KDecoration and KCommonDecoration returns the
QPalette the decoration should use for the decorated window. The
call delegates into the bridge and KWin core might provide a special
QPalette for a given Client depending on the _KDE_NET_WM_COLOR_SCHEME
property.
It's basically a run of the port-cmake.sh script in here, mostly the changes
are the following:
- Using KF5::* targets
- Using the proper macros, following recent developments in frameworks
All the rendering to QPixmap code in the Model and the Preview is
deleted as it's no longer used.
The model still has the plugin for the border size functionality.
This probably needs a change in the API to make it completely bound
to the decoration and not a global thing.
Using a QQuickPaintedItem for the rendering. The item gets the library
name from the model and loads the decoration with its own decoration
plugin. Thus each preview has its own plugin which eliminates the need to
constantly recreate the decoration as it is done with the preview.
Having a QQuickItem gives new possibilities. The item accepts hover
events and forwards them as enter and leave events to the widgets inside
the decoration. By that the mouse interaction of e.g. Oxygen is still
functional. If the decoration uses the new update approach the bridge is
forwarding the updates to the item and triggering a repaint so we even
have animations in the preview although the widget is never shown.
The PaintRedirector calls the new method KDecoration::render and passes
it's PaintDevice and the region to update to it. A decoration can
implement this method and provide an optimized implementation for the
painting which does not go through the deco's QWidget at all. In addition
the decoration can invoke an update() slot which will schedule a repaint
in the PaintRedirector and thus completely replaces the need for
intercepting paint events on the QWidget and also allows to add QWindow
based decorations in future.
- B2 linked to the wrong slot (instead of changed signal)
- border size change was not written (for B2, Laptop etc)
- Aurorae didn't recreate decos when required
BUG: 325946
FIXED-IN: 4.11.3
REVIEW: 113229
This introduces quite some changes. We cannot include a QQuickView
directly in the QWidget based UI as a replacement for the
QDeclarativeView used before.
Instead a QScrollArea is used as replacement for the view and a
QQuickView is embedded into a widget container in the scroll area's
view port. This allows us to keep the existing semantic of having a
native scroll bar synced with the list view. It might be an idea to
change this to QtQuickControls in future.
As the list view is now only inside the scroll area we do not need to
pass the slider width to the root context and can by that more easily
calculate the width of one decoration.
Reset on the factory cannot be invoked directly anymore. The factory
connects to change signals and emits a signal in case the decorations
need to be re-created. So we need to connect to this signal whenever
we expect that a change might trigger a recreation.
addImportPath prepends the path to importPathList so we must add our
paths in reverse order.
Based on the fix for kdeclarative.cpp in kdelibs
400b9f2e9d10386bb175b6123fe0cdaafeaffe61
REVIEW: 110670
REVIEW: 103948
BUG: 91703
BUG: 299245
FIXED-IN: 4.11
- The setting is ignored, the decoration always gets a "true" for it
- moving a maximized window requires breaking a "strong" snap (1/16 of screen height - unless you use quick maximization)
- all snapping is done towards the client, not the frame
- QuickTileMode is exported to the decoration (just as the maximizeMode) so that it can fix the bordersize alongside that.
Many headers included KLocale to use i18n and co. But those methods are
defined in KLocalizedString and not in KLocale.
With KF5 klocale.h does no longer include KLocalizedString causing lots
of compile errors.
The preview code still contained all the old logic for embedding the
preview into another widget. Most of the code had been dead for quite
some time.
The only preview rendering code now is the one to render into a pixmap.
This is actually changed to render the widget directly at the right
position obsoleting the previous widget positioning code.
The no preview available label is dropped as it did not get rendered into
the pixmap at all.
Last but not least we fake that compositing is on. This has always been
the case for Aurorae themes and just looks better. Especially on Oxygen I
had always had some corruption when rendering this preview with
compositing disabled.
REVIEW: 108777
BorderNoSides is what is known from Oxygen as "No Side Borders". The name
should indicate that there is only a border at the bottom. BorderNone is
a mode with no borders at all.
The new enums are added to KDecoration and the KCM so that all decos can
make use of it.
Aurorae is adjusted to support the new sizes for QML themes (it breaks
the old svg based themes) and Plastik makes use of it, by rendering a
one-pixel border around the window, which illustrates that it's still up
to the decoration to decide how to make use of the setting.
REVIEW: 108164
If the decoration listing gets initialized directly in the ctor as it
used to be, there is the chance of the list being not rendered in case
that there are multiple KCMs in one container and one has to switch to
the decoration KCM. This is the case for e.g. opening the KWin
configuration through the Alt+F3 menu. But that never happened when
going through Systemsettings as there (at least with English) it is
listed as the first module.
BUG: 310613
FIXED-IN: 4.10
Plastik has been removed and the new Aurorae has the same requirement as
Oxygen. This fallback was anyway useless given that KWin nowadays uses
raster paint engine by default and hardly anything would work with such a
small QPixmap::defaultDepth().
REVIEW: 106613
If the decoration package contains a ui file in ui/config.ui and
and KConfigXT xml file in config/main.xml the configure dialog
is extended by the custom values.
For this the ui file is loaded and included in the dialog's
layout. To make this possible the AuroraeConfigForm is changed
to a VBoxLayout containing the so far used FormLayout.
The configuration settings are loaded using Plasma's ConfigLoader
and attached to the widget through a KConfigDialogManager.
Marking this commit as the one which implements QML support for
Aurorae themes:
REVIEW: 105751
REVIEW: 105768
BUG: 303810
FIXED-IN: 4.10
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
When the decoration is reset a signal is emitted that the config
might have changed which the decoration can connect to for
reloading its configuration. For this an invokable method is
added to Aurorae allowing to read a config value which just
returns the QVariant.
Proper support for border sizes are added by providing the enum
in DecorationOptions, so that QML themes can use the enum values
to decide which border size to use.
The kcm is adjusted to also support these config mechanisms and
to properly load and save the border sizes for QML based themes.
Model is extended to support QML based Aurorae themes as well
the preview is able to handle it. For this a new qml component
is added which loads the decoration preview.
so we don't mess up our plugins on reload
also invoke it by loadPlugin()
and fix some KLibrary memleaks
REVIEW: 105499
BUG: 303247
(cherry picked from commit fd272b06954029b554197be1d10e252b01f56502)
Stop at bounds while flicking to have a list which behaves in a
natural way on the desktop and ensure that the scrollbar
handles cannot overshoot the list.
Thanks to Nuno for providing the QML based scrollbar. Obviously
this does not improve the consistency with other widget styles, so
a proper solution is still required.
BUG: 291612
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.
