Bug 99807

Summary:	special windows settings (translucency) not applied on app startup
Product:	[Plasma] kwin	Reporter:	Mircea Bardac <contact>
Component:	compositing	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED WORKSFORME
Severity:	normal
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed In:

Description Mircea Bardac 2005-02-19 19:08:59 UTC

Version:            (using KDE KDE 3.3.92)

Howto:

1. Start Konsole.
2. Click on app icon (app titlebar) > Advanced > Special Windows settings > Preferences
3. Check "Active Opacity in %". Enter 80 (%).
4. OK
5. Exit Konsole
6. Start Konsole again. Opacity=100% (bug).

The values are saved correctly, but they are not loaded on startup.
Moving the window and releasing it would bring it to the saved Active Opacity for Konsole (in this example)

Comment 1 Thomas Lübking 2005-02-19 20:23:01 UTC

nope...
the value is not directly applied (so you have to change the window state after assignment) but correctly loaded on further windows
do you use the beta or the cvs version?

Comment 2 Mircea Bardac 2005-02-19 21:45:40 UTC

I use beta2.

I know it is not dirrectly applied, that's why I've tested it by restarting Konsole. I've even logged off/in and started Konsole again. Same behaviour. Per Window settings (opacity) not applied, but after moving the window, Konsole gets it's "customized" opacity as an Active Window.

The Active Window detection code might be a bit buggy...
Now that I think of it, it might relate with http://bugs.kde.org/show_bug.cgi?id=99805 (also about Active Window detection)

Comment 3 Thomas Lübking 2005-02-19 22:46:04 UTC

ok, at least in cvs the window gets its opacity right after showing up, so i assume it's fixed

Comment 4 Mircea Bardac 2005-02-19 22:51:03 UTC

Hmm.. I assume it gets the opacity BEFORE thw window is shown, am I right?

It might not help if the opacity is read after the window is shown, without a repaint (which produces flicker => the settings should be got before the window is shown)

Comment 5 Thomas Lübking 2005-02-19 23:26:28 UTC

getting was not meant... NITPICKER! ;)
if the window has an opacity before kwin greps it, kwin assumes this is a specific opacity usually set by the app itself and does not touch it
if kwin reads a special setting while grepping the window this is applied instead of the default value for active/inactive windows
"repainting" the window isn't necessary. (common active windows work, right?!)

again: this seems to be no more a problem on current cvs - so i assume this is allready fixed as long as there are no confirmations from cvs users

Comment 6 Philip Rodrigues 2006-09-09 18:35:12 UTC

Mircea, does this problem still exist in recent KDE?

Comment 7 Mircea Bardac 2006-09-16 16:24:34 UTC

I've tried reproducing the bug using the steps I've described above in KDE 3.5.4 and the bug doesn't appear.

Thanks for the great work.