In D13535#278441, @fvogt wrote:

in TestDataDevice::testReplaceSource() and it fails without this patch.
With this patch however, the selection isn't offered (is that correct behaviour?) so the wait() times out.
Is there a better way to test this?

Should the patch be backported to 5.13 since it's a fix for the daemon according to the description?

What's with positioner2?

Superseded by D9040.

In D13492#277348, @davidedmundson wrote:

Is this a rule in the spec or one you've come up with?

• Use kconf_update mechanism instead of sed

In D13480#277125, @zzag wrote:

Why the kconf_update/ dir is in helpers/? That doesn't look like a helper.

We can remove every layout reference in the manager as well as in the VDs. I don't see the advantage then with a list in contrast to events desktopAdded / desktopRemoved and a done event. What is better about having an ordering? It's only relevant for the special case of having a "flow" of VDs over several lines, assumed we additionally share a single integer with the workspace (via config file or DBus).

• Spy on SurfaceInterface signal in test

Please wait for @mart's ok before pushing.

Abandoned in favor of D13084.

ping

I decided to add the test to KWin instead with: D13439

I think it makes sense to have a separate ScaleOut effect and not a monolithic Scale effect. Because a user can then select different effects for mapping/unmapping windows. So if you reclaim this diff, I'll accept it.

How is a change of neighbors supposed to work for clients already bound to the proxy objects? For example consider virtual desktop grid:

Can we get this merged now as a quick fix for the bug? In the future we might want to discuss the overall structure of internal windows and their Wayland interfaces.

• const Gamma parameter
• Rebase on parent revision changes

Rebase on parent revision changes

Small cleanup

Rebase on parent revision changes

Small cleanup

• Add ctor to Output
• Save outputs in Platform subclasses directly
• Rename Output to AbstractOutput
• Use std::copy for outputs getters
• Rename output files to abstract_output

1. XDGOutput landed. What's left to do in 2. and 3.? Can you expand upon the required changes?

Right, because it's a single tooltip instance for KWin and not per client. Ok, then let's land it like it is.

Do you need the m_toolTipShowing variable at all? On destruct just always calling requestHideToolTip should be possible, not?

In T8707#146055, @mart wrote:

In T8707#145633, @graesslin wrote:

We are not going to clip anything away from the windows. Sorry, but we cannot do that. It's in IMHO absolutely evil to clip away window content. If you want round borders follow the approach I outlined.

it's really eveil as it can break random applications, yes...
but what about there is a protocol that first asks to the window if it's ok to round, and does it only if the app answers yes?

In D13284#273208, @ngraham wrote:

Here's a UI idea: Instead of "Auto border size", how about inverting the logic and combining the checkbox and the combobox's label, like this:

[x] Override theme's default border size in favor of: [ Normal Borders ⮟ ]"

In D13277#273061, @hpereiradacosta wrote:

Now, no there is no reason not to turn it off by default, except that it will piss people relying on it (and now they will have to look for the option for turning it on again).

That's not a good reason against changing a default. Otherwise we could never change one.

I think this should land independently of the other diffs. I've always used the Normal border size in the past, but now trying out "No Borders" with my patch I don't see the reason for painting this handle. Is there any reason to keep this default as it is?

• Better object names,
• name combobox "Manual border size",
• disable its label as well.

I tried this patch on Neon with FFmpeg 2.8.14.

Fix: always fall back to normal borders when auto border size is used but the

plugin does not have a recommendation.

To test this for example with Breeze you need to recompile Breeze with the following change:

diff --git a/kdecoration/breeze.json b/kdecoration/breeze.json
index ca4a4e3..bb94302 100644
--- a/kdecoration/breeze.json
+++ b/kdecoration/breeze.json
@@ -64,6 +64,7 @@
     },
     "org.kde.kdecoration2": {
         "blur": false,
+        "borderSizeRecommended": "None",
         "kcmodule": true
     }
 }

Rebase on parent revision changes

Rebase on parent revision changes

Rebase on parent revision changes

Rebase on master. Include XdgOutput changes.

In D13153#270440, @zzag wrote:

@graesslin Should I add tests? If so, where should I put them? In libkwineffects/(as Unit tests) or integration/(as Integration tests)?

What's the current state of this patch and the KWin one?

In D13267#272151, @davidedmundson wrote:

If the scale changes now for the first screen, it wouldn't reload the theme, right? I.e. remove the multiplication but leave the connect.

scale would be the wrong thing to follow in that case
I can change it to pixelSizeChanged and keep it.

If the scale changes now for the first screen, it wouldn't reload the theme, right? I.e. remove the multiplication but leave the connect.

I agree with you both. Long term it's right what Martin says: We want to reduce the code base in KWin to have it lean and move additional functionality out so users can extend their desktop if they wish to on a solid base.

I can't say much about the code, but I tried out the change and didn't notice any regressions and I assume the change does improve the overall code quality and fixes some bugs. I would say let's get this effort merged into master and see afterwards if there are regressions reported. The effect is rather rarely used so breakage shouldn't be a huge problem.

When you have time please address my comment. I have to say though that I can't reproduce the crash when hovering over close button in Debug console.

On Neon (Xenial based) FFmpeg version is 2.8.14. It still doesn't fail on CMake. It maybe compares 3.1 with the version numbers of the FFmpeg modules. Their major versions are >50. Then it fails on build, because AVCodecParameters is not defined since 037208a787e0.