trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: February 2012

Re: [trinity-devel] twin modifications

From: "Timothy Pearson" <kb9vqf@...>
Date: Mon, 13 Feb 2012 14:07:57 -0600
> On Monday 13 February 2012 23:25:13 Timothy Pearson wrote:
>
>> > 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.
>
> This is completely useless and broken patch because all the same
> functionality already existed in KDE3 (i.e. the shadows).
> And the newly introduced shadows have less functionality than those
> existed originally (i.e. they are not displayed when moving a window).
>
> I suspect this patch was introduced before the final KDE 3.5.10 was
> released, when KDE still had no shadow function in kwin.

I do agree that if shadow code has been duplicated, the broken code should
be removed.  I seem to remember KDE 3.5.10 having badly broken shadows,
though at this distance I could be mistaken.

Actually, with all the repairs I made to kompmgr, and given the inherent
bugginess of the non-composited kwin shadow code, I'd like to see the
non-composited shadows removed altogether.  Non-composited fading has a
similar problem IIRC, although I have not tested it as I run kompmgr
exclusively on my systems.

Tim