Bug 290273

Created attachment 67283 [details]
screenshot of Plastik decoration

I'm not sure I understand the sentence;
  " all windows show a transparent strip"

How can you see something that is transparant?
Or, in other words; what is the actual user-visible change?

And I'm also not sure what the actual bug is.  A change in behavior is not per definition a bug. So please explain the problem you have run into :)

I was hoping my screenshot explains the problem, as I know that such a problem is hard to describe in words.

> How can you see something that is transparant?

I can see what is BELOW it.
That means, I see THROUGH the strip. So there is the window border, then there is a transparent strip which shows the window content of the window below, then there is the rest of my window.

I attach another screenshot where you can see better what I mean.

Created attachment 67338 [details]
another screenshot where you better see the problem

I can see, but couldn't reproduce.

a) are you using compositing and on which backend in case (look around in "kcmshell4 kwincompositing" for these infos)
b) try running "kwin --replace --graphicssystem native &" - does the issue remain?

Yes, I use desktop effects (OpenGL) as before with 4.6.5.

kwin --replace --graphicssystem native &
solves the problem!

kcmshell4 kwincompositing still shows OpenGL though...

Output when calling kwin... :

OpenGL vendor string:                   Tungsten Graphics, Inc
OpenGL renderer string:                 Mesa DRI Mobile Intel® GM45 Express Chipset x86/MMX/SSE2
OpenGL version string:                  2.1 Mesa 7.11.1
OpenGL shading language version string: 1.20
Driver:                                 Intel
GPU class:                              i965
OpenGL version:                         2.1
GLSL version:                           1.20
Mesa version:                           7.11.1
X server version:                       1.10.4
Linux kernel version:                   2.6.34
Direct rendering:                       yes
Requires strict binding:                yes
GLSL shaders:                           yes
Texture NPOT support:                   yes
NO VSYNC! glXGetVideoSync(&uint) isn't 0 but 5

This problem only shows with border size "normal". In all other border sizes this is not visible.

As this bug made it on a list of "showstopper regressions for 4.8" [1], I just want to add something to that.

This is no regression. The issue is caused by Qt 4.8 switching to raster by default. The window decoration Plastik is much older than the graphicssystem raster and is also in an unmaintained state since before raster was introduced. The last "real" commit to Plastik was on September 16, 2009.

If this is a "showstopper for 4.8" than the only solution is to drop Plastik completely as there is nobody working on the code and what we see here is a case of what is known as "bit rot". Something I will bring up for the next development cycle now as this report and mail to the release team clearly shows that we should not continue shipping code which is unmaintained.

[1] http://lists.kde.org/?l=kde-release-team&m=132549675216175&w=2

>This problem only shows with border size "normal". In all other border sizes
>this is not visible.

Interesting, but how could you test this, as here the change of the border size is simply ignored, meaning: whenever I close the configuration dialogs with OK, nothing happens and when reopening the dialog again, I still see "normal" ... ??

To your other argument:
I fully understand that it is suboptimal to have code which is not maintained.
However, if the code does not have bugs, then I see no reason why one should change anything.
So I read your concern as a statement that the old Plastik decoration has a bug which leads to the transparent strip ?
If so, then I agree but a (hopefully simple) fix should solve the trouble.
Otherwise, if there is no bug in Plastik code, do you see it as normal that changing something in a base lib (Qt here) breaks the application ?
I don't, and if this is a regression with Qt-4.8 then this should be brought up to the Qt support.

> >This problem only shows with border size "normal". In all other border
> >sizes this is not visible.
> 
> Interesting, but how could you test this, as here the change of the border
> size is simply ignored, meaning: whenever I close the configuration dialogs
> with OK, nothing happens and when reopening the dialog again, I still see
> "normal" ... ??
you have to trigger the apply button to be activated, change to another window 
decoration, change back to Plastik and click apply. Oxygen works fine when 
just changing the border size.
> 
> To your other argument:
> I fully understand that it is suboptimal to have code which is not
> maintained. However, if the code does not have bugs, then I see no reason
> why one should change anything.
> So I read your concern as a statement that the old Plastik decoration has a
> bug which leads to the transparent strip ?
> If so, then I agree but a (hopefully simple) fix should solve the trouble.
Who should fix it? The code is unmaintained! There is no developer around 
knowing the code and who could fix it. There are more than 360 open bug 
reports for KWin, why should we spent time on an unmaintained piece of code 
nobody cares about? Just think about: nobody noticed that there is a bug till 
a few days before the release and the code has not changed.
> Otherwise, if there is no bug in Plastik code, do you see it as normal that
> changing something in a base lib (Qt here) breaks the application ?
It is possible that there has been a bug in Plastik for years which was just 
not visible before. So yes changes in other areas can trigger bugs, that's 
what bit rot is all about.
> I don't, and if this is a regression with Qt-4.8 then this should be brought
> up to the Qt support.
there is no indication that there is a regression in Qt 4.8.

I think you have a wrong understanding about what is actually a regression.

a) plastik doesn't get the change but will apply to it when recreated (ie un- and reset)

b) there's no actual bug in the plastik decoration, but it's not prepared for non X11 rendering.

c) choosing the raster graphicssystem as default on X11 is defeatism. period. (so much for todays rant)

d)
> Otherwise, if there is no bug in Plastik code, do you see it as normal that
> changing something in a base lib (Qt here) breaks the application ?

Have you somehow missed the "qDeleteAll" case?

Changing the default graphicssystem is a serious move that has a great potential to break a couple of things (where QPainter is bypassed and the sublying graphicssystem is accessed directly. KWin saw quite some changes which took several revisions to get them bugfree until the raster graphicssystem was let through at all - this bug spotted a remaining issue in basically dead code nobody bothered to test)
Also KWin does not only depend on Qt, but as an X11 WM -naturally- on X11 as well.
Qt removed the anticipated equality of Qt and X11 rendering (plastik hasn't been touched since AGES) and this unsurprisingly breaks things.

e) I will not discuss the "showstopper" aspect, but maybe ask yourself whether you would have tagged it a showstopper if it had occured in the "Web" or BII decoration? And what the answer says regarding professionality and personal preferences.

f) I'd seriously vote to kick *all* legacy decorations and add smaragd and dekorator instead - if Christoph agrees.

Having a bunch of engines next to default KDE decoration seems a good idea.
Shipping unmaintained code from the nineties to provide a hook to KDE's legacy may be romantic, but it's not very effective.

Ok, I get your points that Plastik is unmaintained, and I have no problem with it being removed from KDE (if there is hopefully a somewhat equivalent which is maintained, but I think I will find one).

From a quality standpoint it would be better to remove it NOW instead later and mention this in the release announcement.
It's better to remove broken, unmaintained code than having more people hit the same problem.

P.S.:I did not "tag" it as showstopper. I just hit several regressions in a few days using 4.8RC1 and because I care for KDE, I thought I should inform the release team where I listed all points which I made a bko entry for.

https://bugreports.qt.nokia.com/browse/QTBUG-23430

> f) I'd seriously vote to kick *all* legacy decorations and add smaragd and
dekorator instead - if Christoph agrees.

I had hoped we would rather get a new decoration API, so that I can actually integrate those into KWin theme list...

On Tuesday 03 January 2012 23:59:31 Christoph Feck wrote:
> I had hoped we would rather get a new decoration API, so that I can actually
> integrate those into KWin theme list...
I want to add a QML based decoration (engine) and getting dekorator support 
into it is very high on the priority list :-)