update

This means most our normal users in an office who don't know/care if they're running X11 or wayland have some extra tech-garbage after the name.

I don't really agree, for the same reasons that I would have happily accepted David R's patch

Keep canSwitchUser behaviour from KDisplayManager

I'd quite like to get this in as I'll end up moving part of this - and we've got too much bikeshedding here.

Exposing the options through a simple command line interface would be another option.

And IIRC this method isn't supported on Wayland where the stricter security matters.

I think I see where the difference of opinion is coming from.

Concept makes sense.
+1

Super long term I think we do want to have this, with the desktop-style widget wrapper being only a fallback.

You're right, lets step it back to discussing purely in terms of UX, get on the same page then that will direct the code.

I fully support a better split of colour correct and night mode, with nightmode being an interface into colour correction.
I didn't like really "nightmode" being an explicit part of kwin.

One nice pattern when it's not important whether something is processed an event loop or might have been done directly or via a previous event loop is:

update

From the old review:

update

This powers the plugin backend behind KWindowSystem.
That consists of static methods that can be invoked at any time. We can't change that API.

I'm away at a sprint without my git checkout of krita and poor internet.

Right, I fully understand what you're saying now, makes sense.

Much better, but it still has one callLater which I don't like.

I don't have a solid list, but I've met with Munich people a bunch of times. I tried to list the sore points I knew of above.

@ervin could you expand on what you mean. Especially in terms of actions we can undertake.

update

Testing done

Aye, I forwarded a patch doing that to the person with the crash yesterday.

Update merge issue

Review comments.

Spoke in person, investigated what was wrong.

Sorry, but I don't see the need for this protocol as that is already part of wl_keyboard.

Use QQuickWindow::setSceneGraphBackend instead of touching environment variables

+1 from me.

Why does this even exist?

Well it does so why does it compile? Would it just fail at runtime?