Bug 99807 - special windows settings (translucency) not applied on app startup
Summary: special windows settings (translucency) not applied on app startup
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: compositing (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-19 19:08 UTC by Mircea Bardac
Modified: 2006-09-16 16:24 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.