Bug 311160 - Transparent app gets non-transparent when saving a file (and other situations)
Summary: Transparent app gets non-transparent when saving a file (and other situations)
Status: RESOLVED NOT A BUG
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 4.8.0
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-04 20:55 UTC by Matti
Modified: 2012-12-05 19:14 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
how it should look (14.69 KB, image/jpeg)
2012-12-04 20:57 UTC, Matti
Details
how it looks (17.35 KB, image/jpeg)
2012-12-04 20:57 UTC, Matti
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matti 2012-12-04 20:55:30 UTC
I have a transparent app (Rainlendar) that has been working for years without any problems.
Now, after some software update ~1 month ago, this app sometimes shows ugly window frames.
[How to attach a screenshot here?]
Mostly, this switching to non-transparent happens when I save a file.
Sometimes it happens when  a .jpeg file has been opened in GIMP.
It's really annoying, I always have to close and restart this app to get rid of this ugly look.

Reproducible: Always




Kernel=3.4.11-2.16-desktop
Architecture=i686
Memory=3052876 kB
DistributionVendor=SuSE
DistributionRelease=openSUSE 12.2 (i586)
VERSION = 12.2
CODENAME = Mantis
Desktop=KDE4
Window Theme: Oxygen
Workspace Design: Air openSUSE
Comment 1 Matti 2012-12-04 20:57:05 UTC
Created attachment 75627 [details]
how it should look
Comment 2 Matti 2012-12-04 20:57:57 UTC
Created attachment 75628 [details]
how it looks
Comment 3 Thomas Lübking 2012-12-04 21:59:44 UTC
The window is shaped (and by this automatically does not get a window frame) and apparently looses the shape for some reason (and by this automatically gets back its windowdecoration)

You can control whether the window ever gets decorated (using special application settings or just run "kcmshell4 rules" but the shaping (esp. once it's undecorated) is controlled by the client (rainlendar)

A change in that area has been that kwin did falsely not react on clients altering their shape in some cases, but that should rather not have an impact.

a) install and run "xeyes" - does it show the same behavior?
b) does this still happen if you setup a rule for the rainlendar windows to forcefully not be decorated (have a titlebar & frame, last page in the dialog)
Comment 4 Matti 2012-12-05 19:01:33 UTC
Thank you very much, Thomas.

a) 'xeyes' doesn't show this behaviour, so it's an application-specific reaction.

b) Didn't know that it is possible to set up window rules for a specific application. Great!
After some tests it seems to work as expected now, and if it happens again, I know where to screw.

So, this is no KDE bug, and I set the status to 'resolved/wontfix'. Hope this is correct.
Comment 5 Thomas Lübking 2012-12-05 19:14:20 UTC
More like invalid, since it's not our bug =)
You should ask for ARGB support in that application since the usage of the xshape extension means quite some overhead on (nowadays usually) composited desktops, esp. for very complex (round) structures with relatively small shaped away areas (plus you can get antialiased edges)