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 patch applies a common language and type-setting to the
systemsettings modules in kwin.
Considerations:
- The comment field might repeat the name, or give more detail about the
specific settings on this page, this makes sense with how
systemsettings and kcmshell present it
- Mentioning the words settings, configure, options, etc. is avoided --
it is clear from the context that these are settings and options.
- Title-case throughout in line with human interface guidelines, see
http://techbase.kde.org/Projects/Usability/HIG/Capitalization
- The comment ends up being the title, so the
- tech slang is avoided as much as possible, but left in where really
necessary
- I've left the Name field "mostly untouched", as that one is key for
the user to find the right module in systemsettings' icon view and in
the sidebars
The most prominent change is "Compositor" to "Graphics Compositor" (in
the Title field). This is more like a "suggestion", if you don't like
it, I'll take it out again. Reasoning: "Compositor" is a very technical
term, people who know graphics might recognize it. Others might not
understand that "composite" is about graphics -- hence the
specialization. Please enter the commit message for your changes. Lines starting
REVIEW:118338
* 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.
