Bug 242152 - clicking a program systray icon brings up a window in an inactive state and applied translucency and dim inactive settings
Summary: clicking a program systray icon brings up a window in an inactive state and a...
Status: RESOLVED DUPLICATE of bug 240649
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-19 12:10 UTC by Ivan Lezhnjov Jr.
Modified: 2010-06-19 15:27 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 Ivan Lezhnjov Jr. 2010-06-19 12:10:21 UTC
Version:           unspecified (using KDE 4.4.4) 
OS:                Linux

ilj@sega:/home/ilj % kwin --version
Qt: 4.6.3
KDE Development Platform: 4.4.4 (KDE 4.4.4)
KWin: 4.4.4 (KDE 4.4.4)

Setup
Compositing is ON.
Dim Inactive is ON.
Translucency for inactive (and only this) windows is ON.

Description of the issue.
Do LMB click on kopete/ktorrent/amarok kicker icon to bring a window to the front. It comes up in an inactive state with dim and translucency applied. See the following screenshots:

kopete
http://simplest-image-hosting.net/i0-plasma-desktopal2721-jpg.jpg
ktorrent
http://simplest-image-hosting.net/i0-plasma-desktopzn2721-jpg.jpg
amarok
http://simplest-image-hosting.net/i0-plasma-desktopsu2721-jpg.jpg

This seems to be happening only when there's at least one window active already. If I minimize all of the windows and click kicker icon the windows come up in active state.

Consistency.
The issue is pretty much consistent.

Miscellaneous.
I found "a way to toggle and force an app to remember" its state. Kind of. It seems to work rather consistently.

So, I click on a kicker icon to say bring Kopete to the front. It comes up in an inactive state. I click window title bar (the area where window title and control buttons are placed) to make it active then. Next I click Close button (a X button) which makes Kopete window disappear and then I click kicker icon again and Kopete comes up in an active state now. I can click kicker icon again and again to bring up and down Kopete and it is always coming up in an active state now, thus "toggling". If I click kicker icon and Close (a X button) the state remains "toggled" to active.

Now, the same applies to amarok and ktorrent. You can "toggle the state" for three apps and have them coming up in an active state one after another, in a switching manner (i.e. bring amarok up, bring amarok down, bring ktorrent up, bring ktorrent down, etc.) but only one at a time by just "toggling" them to active state as described above. If you have say ktorrent brought up in a "toggled" active state and try to bring amarok up that already has its state "toggled" to active it'll come up as inactive.

Sometimes it takes two attempts in a row to do a successful "toggling", i.e. kicker icon->close button->kicker icon->close button->kicker icon and now this time it comes up as active.

Reproducible: Always
Comment 1 Martin Flöser 2010-06-19 12:21:50 UTC
Just for clarification: what is a kicker icon? There is no such thing as 
kicker in KDE 4 and your description could be a launcher item, a taskbar item 
or a systray item.
Comment 2 Ivan Lezhnjov Jr. 2010-06-19 12:58:43 UTC
Oh, it's systray icon. Just to avoid any misinterpretation here's a screenshot of the icons I clicked to gather the data for this bug report:

http://simplest-image-hosting.net/i0-plasma-desktopvf2721-jpg.jpg
Comment 3 Ivan Lezhnjov Jr. 2010-06-19 13:46:24 UTC
Mmm by the way before KDE 4.4.4 only Kopete was affected. As of KDE v 4.4.4 at least kopete, ktorrent and amarok are affected. Blogilo for instance isn't affected.
Comment 4 Christoph Feck 2010-06-19 14:15:23 UTC

*** This bug has been marked as a duplicate of bug 240649 ***
Comment 5 Ivan Lezhnjov Jr. 2010-06-19 14:40:27 UTC
It seems to me that bug 240649 is a different one.
Comment 6 Thomas Lübking 2010-06-19 15:20:10 UTC
(In reply to comment #5)
> It seems to me that bug 240649 is a different one.

why...?
at least the commited fix forces a window activation next to a raise.

source of the bug is probably that (due to the new dbus protocol) the mouseevent now happens on the systray server (plasma-desktop) instead of the client (amarok etc.) what breaks kwins heuristics reg. transient windows (ie. clicking on another window of the application was allowed to activate the mainwindow, clicking "somewhere else" is not unless using force)
Comment 7 Ivan Lezhnjov Jr. 2010-06-19 15:27:29 UTC
okay, it seems you really have an idea of why it is a duplicate so let it be so. I just can't really argue with your last statement :)

*** This bug has been marked as a duplicate of bug 240649 ***