>> Care to elaborate?  I am willing to listen.  Your original message was
>> disregarded to some extent as you linked to changes that were made on
>> purpose, and I usually expect people who claim something is wrong to
>> make
>> an attempt at stating *why( they think said something is wrong.
> yes I know they are made on purpose, nevertheless they are wrong. It is
> quite
> common that developers not knowing a codebase do things incorrectly. I
> will
> now only elaborate on the two commits I outlined. In fact all commits I
> have
> seen so far would not pass a review request for KWin and as I mentioned
> there
> is at least one commit with the potential to prevent KWin from starting at
> all.
>
> Let's start with 1f40ada: you modify the inline getter for keepAbove. This
> is
> not how KWin internally works to have window being as keep above. The
> proper
> method to go through is Client::setKeepAbove() which would also tell other
> interested parties that the window is in fact kept above. This method is
> quite
> important to use as it also takes care of putting the window into the
> correct
> layer of the stacking order. I think you solved that by hacking the
> stacking
> order.
>
> The simplest way to achieve what you actually wanted would have been to
> make
> your "modal system notification" an override redirect window.

This would have caused the modal system notifications to lose their window
handles/decorations and drag/resize abilities, unless I have been reading
the FreeDesktop WM specifications incorrectly.  Example:
http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2528706

> The second commit I pointed out was 9cc1e2c1: I think others already
> commented
> in my blog comments why this one is rather bad from a users point of view
> (introducing new config options without removing the obsoleted ones). But
> well
> the main issue from my point of view is that it modified an enum in a
> public
> header by not appending to the end, but in the middle. I think you can
> imagine
> what happens to 3rd party offerings compiled against the previous version.

We are not too concerned about ABI compatibility here, but since the
requested change is so trivial I suppose I can push it through.

Anything else?

Tim