Summary: No need to keep them around for no reason.
Test Plan: Tested the plugins I thought could be affected. Have been using it for a couple of days without problems
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28062
Summary:
This is an alternative solution to T8707 and in comparision to D13276 a less
drastic change to KWin's default behavior.
Instead of changing the border size default for all KDecoration plugins by
switching the default from border size Normal to None introduce new
functionality, which allows a KDecoration plugin to recommend a border size in
its metadata. By default KWin listens for these recommendations and sets the
border size accordingly.
If there is no metadata recommending a border size, KWin falls back to the
current setting of Normal sized borders.
A user is able to override the recommendations from the KCM, which has been
extended accordingly.
Test Plan: Manually with adjusted metadata of Breeze.
Reviewers: #kwin, #plasma, #vdg, ngraham
Reviewed By: #vdg, ngraham
Subscribers: hpereiradacosta, filipf, anemeth, davidedmundson, abetts, graesslin, ngraham, zzag, kwin
Tags: #kwin
Maniphest Tasks: T8707
Differential Revision: https://phabricator.kde.org/D13284
Summary:
No one emits DecorationSettings::fontChanged signal, so if you change
the window title font, then titlebars might look differently after reboot.
Currently, there are two places where we can emit that signal:
- in KDecoration library itself;
- and in KWin.
Because we would need to listen for a Plasma specific D-Bus signal, the
latter option is preferable.
Surprisingly, KWin's implementation of DecorationSettingsPrivate already
reacts to refreshFonts D-Bus signal (even though indirectly), so all
what we have to do is get the current window title font in
SettingsImpl::readSettings, and if it's different from the previous one,
emit DecorationSettings::fontChanged signal.
BUG: 400980
FIXED-IN: 5.15.0
Test Plan:
* Increased the size of the window title font, titlebars got bigger;
* Decreased the font size, titlebars got smaller.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16908
Summary:
drop the global settings and export the service wich will activate
the appmenu kded
Test Plan:
adding the menu button makes new apps export it,
removing it makes new apps using the interlal one again
Reviewers: #kwin, #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: ngraham, davidedmundson, broulik, plasma-devel, kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D9216
This brings back global menu support in KWin.
The DBusMenu infrastructure is different that we just read the DBus service name and
menu object path from the windows rather than passing around window IDs on DBus which
won't work on Wayland.
Differential Revision: https://phabricator.kde.org/D3089
* Border Sizes
* Close menu double click
Both are added to the Settings and exposed in the decoration kcm.
As it started to no longer scale the kcm uses a ui file.
Still missing:
* buttons
* custom decoration configuration
* GHNS
* search
The Compositor is destroyed before the Client and Decorations are
destroyed on shutdown. This meant the Decorations reacted needlessly
on the alpha channel supported. E.g. Aurorae recreated the Decoration
and most likely crashed in Qt.
With this change the signal gets disconnected and the Decorations
just don't do anything.
NOTE: this is not working completely yet, lots of code is still ifdefed
other parts are still broken.
The main difference for the new decoration API is that it is neither
QWidget nor QWindow based. It's just a QObject which processes input
events and has a paint method to render the decoration. This means all
the workarounds for the QWidget interception are removed. Also the paint
redirector is removed. Instead each compositor has now its own renderer
which can be optimized for the specific case. E.g. the OpenGL compositor
renders to a scratch image which gets copied into the combined texture,
the XRender compositor copies into the XPixmaps.
Input events are also changed. The events are composed into QMouseEvents
and passed through the decoration, which might accept them. If they are
not accpted we assume that it's a press on the decoration area allowing
us to resize/move the window. Input events are not completely working
yet, e.g. wheel events are not yet processed and double click on deco
is not yet working.
Overall KDecoration2 is way more stateful and KWin core needs more
adjustments for it. E.g. borders are allowed to be disabled at any time.
