this is not gonna help you on #271023 - see last comment on #248570 (#271023 is a dupe)

Well, the Atom could define a region the window tells KWin it occupies.

If no atom is defined, window geometry is used (default behavior).
If the region is empty (0x0), then such window is omitted when snapping and placing other windows.

The Window-Specific option mentioned above would set the region to 0x0.

Did you read what i wrote?

a) This window property DOES exist and is used to make panels shrink the desktop size or (by another kde prop. atom) to extend the window by its frame (to allow windows to snap against each other)
b) the shadow is NOT an extra window, setting an empty frame won't help
c) only decorated clients (windows with a titlebar) cause strutting an therefore exists a (KDE prop.) property which could eg. be used by decorations to manage strut areas (when windows snap against each other etc.)

The onlya problem is that plasma uses the default way Qt sets dock window struts what does not match plasmas needs because a part of the window is "the shadow area" - neither Qt/QWidget, nor the WM know about this.

The plasma containments have to fix this by setting the strut on it's panels correctly.
Technically that's not very hard (KDE has a nice convenience function), but i guess the theme specification just lacks support.

So to work around plasma you'd have to add a rule for every panel to fix the strut area depending on the plasma theme de toujours, also implicating you'd know about the window system, strutting and the particular client structure what makes this hardly a usable solution, eg. this
> The Window-Specific option mentioned above would set the region to 0x0
is wrong since the shadow is no window by it's own.

I have read your comment.

This Window-Specific option does not aim to fix this particular shadows issue.

I would just like to be able to make some windows being omitted when snapping/placing other windows.

> b) the shadow is NOT an extra window, setting an empty frame won't help
> > The Window-Specific option mentioned above would set the region to 0x0
> is wrong since the shadow is no window by it's own.

I meant empty Atom to make the window being completely omitted.

> to extend the window by its frame
> (to allow windows to snap against each other)

Is it possible to shrink the window with it by its shadow? If so, that would solve the problem with shadows.

> Is it possible to shrink the window with it by its shadow? If so, that would solve the problem with shadows.
This is not the same thing, but otherwise yes: the strut area (as set by docks) can be completely arbitrary and unrelated to the window size at all. (eg. i've got a dummy "window" here which -while completely invisible- adds some "virtual" strut areas to the desktop)

Martin howver want's to "force" Marco to use the KWin shadows, no idea whether that's gonna work w/o a gun - there might be other translucent things than a shdow in the them (eg. a reflection or whatever) and on top of that svg has it's own pitfalls - not to mention this would break existing themes. We'll see.

For regular windows the snapping stuff is a KWin feature anyway and so they could easily be taken into account or not, but allowing the user to manipulate the strutarea for a regular window other than on/off sounds quite like a wrong way to workaround a certain bug.

In current master we have support for KWin scripting which is a much more powerful way than the static window rules and should solve custom placing issues.

But the actual issue this feature request should have worked around has been fixed properly which is in my opinion a much better solution than adding workarounds :-)