Bug 315926 - Some windows cannot be made visible
Summary: Some windows cannot be made visible
Status: RESOLVED NOT A BUG
Alias: None
Product: kwin
Classification: Plasma
Component: activities (show other bugs)
Version: git master
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-28 21:35 UTC by George Kiagiadakis
Modified: 2013-03-02 09:06 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 George Kiagiadakis 2013-02-28 21:35:27 UTC
I am a gentoo user, normally building all of kde from git master. For quite some time now (~3 months I think), I hadn't upgraded KDE. Recently, however, I decided to upgrade it to the latest git master. After the upgrade, I discovered a serious regression in kwin.

The bug is that the windows of certain applications cannot be made visible, ever. So far, I have noted two affected applications:
* KeepassX
* ktp-text-ui

Both applications have something in common: They normally open without a window. Keepassx has a systray icon, which can be used to toggle the main window. ktp-text-ui opens in the background, waiting to handle a telepathy text channel; when that happens, it opens a window with the chat. However, this is something that other, unaffected, applications do as well. For example, clementine, skype and kgpg are not affected.

Switching to another window manager (I tried openbox) fixes the problem.

One other symptom: Under KDE Plasma desktop, the taskbar does not show entries for those windows either. Under Razor-qt with kwin, however, the windows are properly shown in the taskbar, although they are still not visible.

Disabling desktop effects does not solve the issue.

Reproducible: Always

Steps to Reproduce:
1. Install a recent kwin and kde-telepathy
2. Try to open a chat with a contact from the contact list

Actual Results:  
Chat window opens in the background (according to terminal output, if you investigate it), although it is not visible on the desktop

Expected Results:  
Show the window

I am using a dual head setup with one desktop spanning on two monitors.

% glxinfo |grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RS780
OpenGL version string: 3.0 Mesa 9.1-devel
OpenGL shading language version string: 1.30
OpenGL extensions:
Comment 1 Thomas Lübking 2013-02-28 21:51:08 UTC
The windows are probably in the wrong (likely "null") activity.

To confirm, run openbox and when the windows appear run

xprop | grep _KDE_NET_WM_ACTIVITIES

and click the (problematic) info.
Post the output.
Deleting the property will (likely) bring back the window under kwin.

See https://git.reviewboard.kde.org/r/107855/
Comment 2 George Kiagiadakis 2013-02-28 22:05:52 UTC
Looks like you are right.

On any window that is visible under kwin, I get:
_KDE_NET_WM_ACTIVITIES(STRING) = "00000000-0000-0000-0000-000000000000"

but on keepassx I get:
_KDE_NET_WM_ACTIVITIES(STRING) = "ALL"
Comment 3 Thomas Lübking 2013-02-28 22:18:44 UTC
xprop -remove _KDE_NET_WM_ACTIVITIES
then click the window.

@Martin
I think we either have to backport the commit or add a shim that simply treats the null activity as "ALL" as well.
-> 4.10.2, of course *sigh*
Comment 4 Martin Flöser 2013-03-01 07:00:05 UTC
@George: which version are you using? git master as stated in the version field or a 4.10.x?
Comment 5 George Kiagiadakis 2013-03-01 08:13:17 UTC
This is git master. I just rebuilt it to make sure, but I am pretty sure my last build was master from wednesday (I am rebuilding kwin frequently for the past two weeks that I have this problem, to see if there is any change)
Comment 6 Thomas Lübking 2013-03-01 11:30:48 UTC
ok, sorry.
does deleting the property make the window accessible again?
do you also build kactivities from git master? (it's not in kdelibs)
Comment 7 George Kiagiadakis 2013-03-01 14:14:01 UTC
Yes, kactivities is also built from master. I rebuilt everything today and logged out/in to make sure everything is fresh.

Deleting the property doesn't make any difference. This is what I did, step by step:

1) Opened ktp-text-ui under kwin (not visible)
2) openbox --replace
3) % xprop |grep ACTIVIT (and click on text-ui)
-> _KDE_NET_WM_ACTIVITIES(STRING) = "ALL"
4) % xprop -remove _KDE_NET_WM_ACTIVITIES (and click on text-ui)
5) % xprop |grep ACTIVIT (and click on text-ui)
-> No result
6) kwin --replace
-> text-ui is not visible again
7) openbox --replace
8) % xprop |grep ACTIVIT (and click on text-ui)
-> _KDE_NET_WM_ACTIVITIES(STRING) = "ALL"
Comment 8 Thomas Lübking 2013-03-01 14:26:33 UTC
The question is how "ALL" appears there.

Are you sure you've commit cda0dc1ce81ca432a05e8cdfe229cc4de18d442f

In case the only reason i could think of would be a client setting it directly (not using libkactivites) or eventually a rule bing in place (and since you compile yourself, you likely didn't run the kconfupdate script)

-> do you have setup rules for those windows?
Comment 9 George Kiagiadakis 2013-03-01 15:31:03 UTC
Bingo! I had forgotten about those rules. So, yes, I have rules for those applications to force showing them on all desktops and activities. kwinrulesrc contains this "ALL" string indeed.

Now the question is, why this hasn't been updated with kconfupdate. I compile master through gentoo's emerge system, so everything gets installed properly in /usr like on any other distribution...

...and kconf_updaterc contains:
[kwin_translate_activity_rule.upd]
ctime=1362143933
done=Kwin-4.10
mtime=1361013891

...so I assume it did run once...

After running it manually again, kwinrulesrc looks good, with zeros instead of "ALL". I don't know why this wasn't updated automatically....
Comment 10 Thomas Lübking 2013-03-01 15:36:10 UTC
I've actually never seen kconfupdate running by hand installations (of kwin only) why it would have not updated the settings (ran as root?) then, i can't say.
Heisenbug ;-)
Comment 11 Martin Flöser 2013-03-01 16:27:10 UTC
> ...so I assume it did run once...
did you restart the session?
Comment 12 George Kiagiadakis 2013-03-02 09:06:21 UTC
(In reply to comment #11)
> > ...so I assume it did run once...
> did you restart the session?

I did, although the first time after the upgrade where I noticed the problem, I remember I logged in to razor-qt instead of plasma... I don't know if this affects kconf_update in any way (it shouldn't, but...)