After lowering the message severity for the KWIN_CORE logging category,
it has been found that the Workspace calls the updateDecoration() method
for every mapped popup surface.
Since the XdgPopupClient doesn't implement that method, a warning message
is printed every time a popup is mapped.
Given that XdgToplevelClient updates the decoration when needed, we can
remove the call to the updateDecoration() method.
Warning messages are not the kind of messages that should be ignored,
they indicate that something is off or wrong.
Also, this makes triaging bugs easier as we no longer have to ask people
to run kwin with the QT_LOGGING_RULES environment variable set.
With xdg-toplevel windows, the value of the "no border" property can be
sometimes out of sync with the fact whether the window is decorated. This
may result in Deleted windows being frameless.
In order to address that issue, we need to store the current value of
AbstractClient::isDecorated() during the construction of Deleted.
If all outputs have been disconnected, the screensQueried() signal won't
be emitted and Screens::count() and Screens::size() won't be updated.
The signal is not emitted to ensure that kwin is initialized properly when
there are no outputs.
Unfortunately, this breaks repaint scheduling code as it doesn't take
into account that the Screens class may lie in rare cases.
The drm backend should probably create a placeholder screen in case all
physical outputs have been disconnected, but in meanwhile, let's work
around this issue by porting the scene to the output api in the Platform.
Some applications set their own geometry after start,
which overrides the initial rule settings for placement:
position, size and initial placement.
This happens now more often, after introducing the
"Remember app last position" feature for KXMLgui apps.
There is a mechanism to avoid that, by Forcing the rule property
"Ignore geometry", but it is unknown to many users.
This MR adds a hint when some rule properties might not be
respected by the application, so users can set this property
and hopefully avoid bug reports.
BUG: 428781
Improves portability by avoiding the non-standard 'uint'. For example
this fixes building with musl libc:
".../kwin_wrapper.c:45:9: error: unknown type name 'uint';
did you mean 'int'?"
A situation meant we want to only enable the new keyboard applet by
default on wayland, using the legacy one from the X11 daemon on X11.
We need a unique service name so that we can use DBus activation on it.
QMap::value() failed to find existing keys when tow ComparablePoint
shared the same x but not the same y.
This commit improves the operator<() to fix that.
Previously code was if socket fd is greater then 0, then we start
process, but new code in 05ebe676d2 reversed logic. So this
made it not start input method at all.
On that signal, we asquare the new layout anyway all over the places.
Better just pass it along with the signal instead.
Also it's in-line with DBus API signal.
The base handle for layouts in libxkbcommon is an index. Let's follow
this notion in our API to set/get layout, instead of using it's name as
an ID.
On the way, do cleanup. Following methods are removed as not needed any
more:
- Xkb::layoutShortNames()
- Xkb::layoutNames()
If user set custom name for the layout, country flag is not displayed.
Instead, Display Name is shown in the applet.
This reveals shortcomings in current DBus API design.
We need more data to pass over DBus to fix this.
Then, multiple improvements are possible:
- fix aforementioned bug
- add flags to context menu
- display correct translated Layout Name in the context menu
- simpler, cleaner DBus API and applet implementation
- etc.
At the moment we are getting the input method from the command line
which is not very handy (but very secure).
This patch changes it so it can be specified from a configuration
setting.
CCBUG: 427972
If the maximizedChanged connection is queued, several configure events
will be sent. If the client acks the first configure event and later on
acks the second one, the maximize animation will be cancelled due to
"unexpected" geometry change.
Based on the code, there is no clear reason why the connection is queued
in the first place.
CCBUG: 431415
