I'll try to reason that out, because I think there's some confusion about the development of the topic.

Quick reminder: the constantly brought argument for this was that it would allow mass closing of windows, what's outright silly, because the window layout would change w/ every closed window - not necessarily in a predictable way (not only because of the re-layout but attempting to close a window might instead add a dialog - in worst case not a transient one)

In D14850#309476, @zzag wrote:

The functional justification for translucent moving/resizing windows has always been to control its geometry in relation to windows lower in the stack ("what and how much will be covered", "where's a free area")
There may also have been references to early WMs when windows were just hinted by an outline during geometry transitions (though typically not unmapping the actual window), simply because displaying them while resizing them is resource intense (what's more of a concern when you're short on resources) - those WMs would often have presented an outline to allow controlling the initial position for the window before actually mapping it.

iirc the set rules are used by kstart

'key...?!
I'd assume the const casting avoids deep copies of the QList - at least that's the only explanation I could come up without a deeper investigation.

Did you compare that to a profile with the updated cast?
This makes little sense and a simplified testcase doesn't measure significant differences in casting times on the wall clock time. And certainly not factor 22.

I'm not actually smiling ...

Why was that a problem?
(Or how can I see the previous patch in this messy review tool which draws an entire core when typing...)

On a general note, UI-wise: if there's no way to ever enable an item it should not be shown anyway.

The original implementation based the fullscreen status on the stack position of the window (ie. whenever a window would rise above the plain stack position of the FS window, it would loose the FS status, ie. top layer)
The result was iirc that random notifications would not only show up but also de-fullscreen the window and also virtual desktop switches would constantly kill the FS state.

Should the lock screen not be guarded by a black layer in the compositor?
As of the effect, maybe this should rather fade in a black layer than fade out everything else?

requestToolTip(QString) and treat an empty string reasonably?

Ignore the request as "probably temporary" and just freeze rendering?

Why should it? The stack remains the same, just one window changes its visibility.

There's a major pitfall to inter-process modality:
In case of a persistent transient (used by several clients), the leader may loose the focus access "forever" (because the modal window remains)

Probably to handle internal WhatsThis online help (ie. you click the maximize button of a deco and get the information that this is a maximize button) but I don't know either.
Apparently even Lubos was already unsure what this was about.

I take there's no such support announcement on native wayland at all?

Pretty uninformed consideration:
When dealing with X11/wayland hybrids, won't one end up with two property indexes which are hard -if not impossible- to align (because one will be assigned by kwin internally and the other by the casual xwayland server)?
Might the xwayland property even change over the runtime of kwin (is the xwayland server conditionally removed)?

Unless things changed for the worse, clients (through this function) still send a client message (on _NET_ACTIVE_WINDOW) - the difference between the regular call and the force version is the source indication being "2" ("i'm a pager/taskbar and know what i'm doing so please do") - but the actual property is still set by the WM after receiving (and honoring) such message.

There's no technical advantage in a local static, only a design one. You prevent it from future mis-use beyond its limited purpose, because m_activeWindow isn't actually a "property" of RootInfo.
If you however at some point need several instances, that's no longer an option (resp. you'd need a local hash which is but even uglier than the "false" member)

David has some point though - m_activeWindow *can* get out of sync (server error, mal... stupid client - and will be temporarily due to the async setup) and must not be used directly to query the active window.

2¢ - you don't have to expose the cursor position for those effects, just a signal that the cursor position changed and the ability to "do some" at the "current" cursor position (which is then resolved by the core)

What about lldb and in case this is meant as security measure(?): this only checks a tail, ie. ~/mysuperspytool/trick_kwin/gdb would work just as well - check the binary to be UID0 at least?

I think what David has in mind is a shadow constellation like

In D6077#114439, @apol wrote:

Just saw this because of a bug report.
Why was this patch approved at all?

Matter of semantics only (if you would want to use the XCB_CURRENT_TIME symbol wrt backend abstraction matters and readability - the invalidity isn't implicitly explained, maybe read as bool "if (timestamp && ...") but I'm out of position for an informed comment on this.

0L is XCB_CURRENT_TIME iow "kinda invalid", so it's sane to block that in setX11Time()

In D5704#106951, @cfeck wrote:

I may be totally unaware about what the changes do, but from reading the comments on the bug report, I had expected to see something like

if (timestamp > m_X11Time || int(timestamp + INT_MAX / 2) < m_X11Time) ...

The desktop grid seeems more suited to handle the windows VD.
There're PW modes where this feature is pointless (because you only see the current VD anyway) and for the other ones there's (as mentioned) no feedback nor oversight on the status quo. Nor is there even visibility of the feature.
A merge between PW and DG (aka "Mission Control"; what you seem to be after?) would imo require a sane re-draft of such effect/tool.

KWin *has* global shortcuts for minimizing and stickyness. Those should either be forwarded or picked up from KGlobalAccel, rather than adding some randonmly hardcoded strings where the user might have entirely different expectation on what they do.

Another problem related to timestamp handling is KWin getting broken by wrong timestamps sent by applications. A prominent example is clusterssh

This should also mitigate the "idiotic client confused X11 time with epoch" condition (iirc some ssh per script?), yesno?

According to the bug kwin_wayland receives a SIGINT, not a SIGSEGV?

This boils down to the question why the process is still lingering around. If the only parent/child link is actually the socket, then it's more likely to zombie around on a bad socket.
In this case you can fire as many signals as you want - they'll never be handled (the process isn't interruptable)

If the child survives the parent that normally means it's forked at some point and the fork will clear the flag - anyway:
Kai says the process knocks out gdb - is it a zombie process (indicated by "D", cannot be stopped or killed, let alone being terminated) and/or is the socket actually closed or still around?

ftr, not sure about --transform correctnes, but metamodes ViewportIn/ViewportOut work flawless on at least the nvidia blob.

In D5245#98917, @graesslin wrote:

This is something we do not know. We do not know what color scheme the window uses. Given that a desaturation is probably the best we can do.

In case you'd rather not want to introduce a git history wall:
-Wno-inconsistent-missing-override -Wno-inconsistent-missing-destructor-override -Wno-initializer-overrides

In D5164#98159, @lunakl wrote:

To keep the delay, one would have to wire the call through a secure dispatcher which guarantees (by searching the list of all windows) the effectwindow still points valid memory before passing the function call on (or use a guarded pointer)

In D4220#78878, @graesslin wrote:

"On Wayland that kded has no real access to the layouts and cannot
properly implement switching. Given that it's better to integrate the
SNI directly in KWin."

The entire parsing is totally not safe against JoeReddiot murking around in the config file, I wonder what happens if we pass "-1" and what is " " cast as...

xcb_randr, gamma ramps. yes.
Look at the inversion implementation in kwin and/or simply the xgamma/xcalib code =)

I'm no longer sufficiently in touch with the code, but one could probably "abuse" the (unstyled) effectframe for the matter (ie. generalize it and make the current frame a special case reg. color, roundness and opacity) - or introduce a similar class for such purposes.

Wouldn't it make more sense to leave the windows alone and trail the screen paint with a black rectangle, in doubt by adding a black window?

Featurewise, there's iirc a config item to wrap around virtual desktops - maybe this should be invoked here? (Although that link is currently not made clear by the config dialog)

On a general note: this terribly looks like doubling all (or a lot of) the core logics reg. tabs - which we had in initial KDE 4 tabbing and which made tabbing *incredibly* buggy.
I'd suggest to forward the cores tab logics and not keep local states, counters etc. around, you'll easily get out of sync.

In D3037#56298, @graesslin wrote:

Errrr... this does not allow the dock to control input, ie. the dock can or can not take focus but you want focus if eg. clicking into a lineedit while do certainly not want it when clicking a button that will activate a window (FSP trouble)

This looks like editing the rule while the activity daemon does not respond (in time) is prone to alter the setting?
Maybe disable the combo until there's response from the activity dameon and ensure to not write back the setting until it's enabled?

The statement is legal, this is either a problem in Qt (API break) or the compiler (resolving function signatures, maybe related to "explicit" or template usage)

Sounds reasonable enough, but seems to point out an issue in wayland:

This is BC, but undocumented.