Message: previous - next
Month: February 2012

Re: Re: [trinity-devel] twin modifications

From: "Timothy Pearson" <kb9vqf@...>
Date: Mon, 13 Feb 2012 13:25:13 -0600
>> 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:

> 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?