Bug 290273 - Plastik window decoration show transparent strip in window border
Summary: Plastik window decoration show transparent strip in window border
Status: RESOLVED UPSTREAM
Alias: None
Product: kwin
Classification: Unclassified
Component: decorations (show other bugs)
Version: 0.2
Platform: openSUSE RPMs Linux
: NOR minor (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-31 17:46 UTC by Martin Koller
Modified: 2012-01-04 16:21 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
screenshot of Plastik decoration (63.91 KB, image/png)
2011-12-31 17:46 UTC, Martin Koller
Details
another screenshot where you better see the problem (6.41 KB, image/png)
2012-01-02 11:26 UTC, Martin Koller
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Koller 2011-12-31 17:46:05 UTC
Version:           0.2 (using Devel) 
OS:                Linux

I upgraded KDE from 4.6.5 to 4.8-RC1 and now all windows show a transparent strip beside the left, right and bottom window border in the Plastik window decoration.
I attach a screenshot where I marked the transparent strip with a red rectangle.

Oxygen, Laptop, BII, QtCurve, Tabstrip do not show this problem, so it seems to be a Plastik only problem in 4.8RC1.

Reproducible: Always

Steps to Reproduce:
Use Plastik decoration.


Expected Results:  
No transparent strip as was in 4.6.5

OS: Linux (i686) release 2.6.34.10-0.4-desktop
Compiler: gcc
openSuse 11.3
Comment 1 Martin Koller 2011-12-31 17:46:42 UTC
Created attachment 67283 [details]
screenshot of Plastik decoration
Comment 2 Thomas Zander 2012-01-02 11:17:29 UTC
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 :)
Comment 3 Martin Koller 2012-01-02 11:25:46 UTC
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.
Comment 4 Martin Koller 2012-01-02 11:26:24 UTC
Created attachment 67338 [details]
another screenshot where you better see the problem
Comment 5 Thomas Lübking 2012-01-02 15:04:33 UTC
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?
Comment 6 Martin Koller 2012-01-03 07:28:47 UTC
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
Comment 7 Martin Flöser 2012-01-03 20:58:52 UTC
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
Comment 8 Martin Koller 2012-01-03 21:12:56 UTC
>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.
Comment 9 Martin Flöser 2012-01-03 21:37:14 UTC
> >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.
Comment 10 Thomas Lübking 2012-01-03 21:41:16 UTC
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.
Comment 11 Martin Koller 2012-01-03 21:59:28 UTC
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.
Comment 12 Christoph Feck 2012-01-03 23:59:30 UTC
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...
Comment 13 Martin Flöser 2012-01-04 16:21:39 UTC
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 :-)