When logging in and restoring a previously saved session, all of the windows in restored applications have entries in the taskbar, but the windows cannot be raised. Clicking on the entry in the taskbar sometimes shows a flicker, like the window is coming up, but the window never appears. I tried disabling desktop effects, but the windows still were not visible. Any application window started after the session has been restored behave normally. Reproducible: Always Steps to Reproduce: 1. Save session with some open applications 2. Log out 3. Log in Actual Results: Windows of restored applications are not visible. Expected Results: Windows can be raised/lowered as normal.
how many activities do you use? can you eg. "openbox --replace" to replace kwin? in case the windows then show up, please attach the output of "xprop" on one of them
This looks like what happens to me a lot, meaning on several systems, and since several versions back, probably since 4.10, and continuing through 4.10.5. I don't specifically save anything, but I nearly always have Konsole in black on white open @0,0 36-40 tall and 120 wide, and rarely close it at session end or otherwise. Most of the time I end a session with only KSnapshot additionally open, or nothing else open. Approximately every other session start, Konsole is on the taskbar, and cannot be raised. Whether this happens on Mageia 3 or 4 or Fedora 18 or 19 I've not noted, but it's been happening at least in openSUSE 12.3, and possibly in 13.1 and/or 12.2. I don't use "activities", unless by accident without my knowledge. Application starter on all is set to old style. Panel height is usually in the 47-54 range. Most fonts are size 10. DPI on most is 120 or higher. Fresh start by stripping ~/.* used by KDE doesn't help. Once a session has been closed with Konsole left open, the misbehaving eventually begins again. Thread beginning http://lists.kde.org/?l=kde&m=137426265725507&w=2 suggests this could be compositing related, but my systems all have 'Options "Composite" "Disable"' set in xorg.conf.
(In reply to comment #2) When the "dead" konsole window is there, acquire the window id (maybe use an xterm to not mess up the konsole instances/windows) xwininfo -root -tree | grep -i konsole looks like: 0x1400014 "konsole": ("konsole" "Konsole") 640x409+0+0 +0+0 0x140000c "konsole": ("konsole" "Konsole") 640x409+0+0 +0+0 0x1400004 "konsole": ("konsole" "Konsole") 640x409+0+0 +0+0 0x140001c "loki : zsh – Konsole": ("konsole" "Konsole") 717x235+0+0 +562+341 then dump the window properties xprop -id 0x140001c > konsole.props (use the actual id instead of 0x140001c - it's the one with the proper geometry) and attach konsole.props to the bug. Does the konsole window have a titlebar?
Created attachment 81220 [details] response to comment 3 kdebase4-openSUSE-12.2-11.3.i586 kdebase4-session-4.10.5-1.1.noarch kdebase4-workspace-4.10.5-6.1.i586 kdebase4-workspace-branding-upstream-4.10.5-6.1.i586 kdebase4-workspace-liboxygenstyle-4.10.5-6.1.i586 kdelibs4-4.10.5-4.1.i586 kdelibs4-branding-upstream-4.10.5-4.1.i586 kdelibs4-core-4.10.5-4.1.i586 kdm-4.10.5-6.1.i586 kdm-branding-upstream-4.10.5-6.1.i586 konsole-4.10.5-1.1.i586 kwin-4.10.5-6.1.i586 (In reply to comment #3) > Does the konsole window have a titlebar? For a window that cannot be raised, how does one find that answer?
Created attachment 81223 [details] another response to comment 3 both this and comment 4 are from single core P4 host gx27b kdebase4-openSUSE-12.3-10.111.5.i586 kdebase4-session-4.10.5-1.100.1.noarch kdebase4-workspace-4.10.5-1.107.3.i586 kdebase4-workspace-branding-openSUSE-12.3-6.2.i586 kdebase4-workspace-liboxygenstyle-4.10.5-1.107.3.i586 kdelibs4-4.10.5-1.101.1.i586 kdelibs4-branding-openSUSE-12.3-6.38.1.noarch kdelibs4-core-4.10.5-1.101.1.i586 kdm-4.10.5-1.107.3.i586 kdm-branding-openSUSE-12.3-6.38.1.noarch konsole-4.10.5-1.100.1.i586 kwin-4.10.5-1.107.3.i586
(In reply to comment #4) > For a window that cannot be raised, how does one find that answer? Inject the term "usually" ;-) The props of the window says it's one time on activity "b6958e87-e4e7-4c56-891c-add046b1ca03" and another time on "8237b075-8362-40f4-a8f0-baeef583d365" - what sounds suspicious enough - esp. souce you claim to not use activities. compare your current activity: qdbus org.kde.kactivitymanagerd /ActivityManager/Activities CurrentActivity What should match the list of all activities? qdbus org.kde.kactivitymanagerd /ActivityManager/Activities ListActivities Does the window appear when calling this? xprop -remove _KDE_NET_WM_ACTIVITIES <figured_window_id_here>
(In reply to comment #6) > esp. souce you claim to not use activities. 'I don't use "activities", unless by accident without my knowledge' means I could be using "activities" unwittingly. I don't have any use for them, don't know how to use them, and wouldn't recognize that I was if I was. Different virtual desktops or X sessions or computers are where my different activities go. > compare your current activity: > qdbus org.kde.kactivitymanagerd /ActivityManager/Activities CurrentActivity $ qdbus org.kde.kactivitymanagerd/ActivityManager/Activities CurrentActivity Service 'org.kde.kactivitymanagerd/ActivityManager/Activities' is not a valid name. $ qdbus org.kde.kactivitymanagerd /ActivityManager/Activities CurrentActivity Service 'org.kde.kactivitymanagerd' does not exist. > What should match the list of all activities? ??? > qdbus org.kde.kactivitymanagerd /ActivityManager/Activities ListActivities $ qdbus org.kde.kactivitymanagerd /ActivityManager/Activities ListActivities Service 'org.kde.kactivitymanagerd' does not exist. > Does the window appear when calling this? > xprop -remove _KDE_NET_WM_ACTIVITIES <figured_window_id_here> $ xprop -remove _KDE_NET_WM_ACTIVITIES 0x2c00019 <nothing>
(In reply to comment #7) > $ qdbus org.kde.kactivitymanagerd /ActivityManager/Activities CurrentActivity > Service 'org.kde.kactivitymanagerd' does not exist. Did you kill or chmod -x or rename or whatever kactivitymanagerd? > $ xprop -remove _KDE_NET_WM_ACTIVITIES 0x2c00019 > > <nothing> Sorry, my bad - missed "-id" xprop -remove _KDE_NET_WM_ACTIVITIES -id 0x2c00019 (You should have gotten a usage help message, though ;-)
(In reply to comment #8) > Did you kill or chmod -x or rename or whatever kactivitymanagerd? No. > Sorry, my bad - missed "-id" > xprop -remove _KDE_NET_WM_ACTIVITIES -id 0x2c00019 Success. > (You should have gotten a usage help message, though ;-) Didn't.
(In reply to comment #9) > > xprop -remove _KDE_NET_WM_ACTIVITIES -id 0x2c00019 > Success. Well, definitively the window is on another activity then. > > Did you kill or chmod -x or rename or whatever kactivitymanagerd? > No $ ps ax | grep kactivitymanagerd $ which kactivitymanagerd $ stat `which kactivitymanagerd` if not running but available: $ kactivitymanagerd $ qdbus org.kde.kactivitymanagerd /ActivityManager/Activities CurrentActivity $ qdbus org.kde.kactivitymanagerd /ActivityManager/Activities ListActivities
All this activity seems to have made this harder to reproduce. It took me more than 20 session restarts this time for this to happen. Last time took at least 5. This time only occurred on 2nd or 3rd open after stripping ~/.kde4/ & other dirs it KDE uses in $HOME. (In reply to comment #10) > $ ps ax | grep kactivitymanagerd 2424 ? Sl 0:01 /usr/bin/kactivitymanagerd 2592 pts/3 Ss+ 0:00 /bin/bash -c ps ax | grep kactivitymanagerd > out 2594 pts/3 S+ 0:00 grep kactivitymanagerd > $ which kactivitymanagerd /usr/bin/kactivitymanagerd > $ stat `which kactivitymanagerd` File: â/usr/bin/kactivitymanagerdâ Size: 252860 Blocks: 496 IO Block: 1024 regular file Device: 80ch/2060d Inode: 263848 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2013-07-03 17:04:41.000000000 -0400 Modify: 2013-07-03 17:04:41.000000000 -0400 Change: 2013-07-20 11:40:53.000000000 -0400 Birth: - > if not running but available: > $ kactivitymanagerd <nothing> > $ qdbus org.kde.kactivitymanagerd /ActivityManager/Activities CurrentActivity 4573827d-2181-47e8-ad46-1c4fcd87ccac > $ qdbus org.kde.kactivitymanagerd /ActivityManager/Activities ListActivities d5f7667b-addb-42cc-9cfe-c21906afa687 4573827d-2181-47e8-ad46-1c4fcd87ccac 80a331fa-8a4f-4313-977e-a253373e4ad6
(In reply to comment #11) > All this activity seems to have made this harder to reproduce. It took me > more than 20 session restarts this time for this to happen. Last time took > at least 5. This time only occurred on 2nd or 3rd open after stripping > ~/.kde4/ & other dirs it KDE uses in $HOME. This will ultimately boil down to bug #264550 The konsole window is not on all activities (god knows why) and the "wrong" activity is stored in the session data (ie. either you re-login with another activity, or the stored activity is not the last current one) Since you don't have any use for activities: > $ qdbus org.kde.kactivitymanagerd /ActivityManager/Activities CurrentActivity > > 4573827d-2181-47e8-ad46-1c4fcd87ccac > > $ qdbus org.kde.kactivitymanagerd /ActivityManager/Activities ListActivities > > d5f7667b-addb-42cc-9cfe-c21906afa687 > 4573827d-2181-47e8-ad46-1c4fcd87ccac > 80a331fa-8a4f-4313-977e-a253373e4ad6 $ qdbus org.kde.kactivitymanagerd /ActivityManager/Activities StopActivity d5f7667b-addb-42cc-9cfe-c21906afa687 $ qdbus org.kde.kactivitymanagerd /ActivityManager/Activities StopActivity 80a331fa-8a4f-4313-977e-a253373e4ad6 $ qdbus org.kde.kactivitymanagerd /ActivityManager/Activities RemoveActivity d5f7667b-addb-42cc-9cfe-c21906afa687 $ qdbus org.kde.kactivitymanagerd /ActivityManager/Activities RemoveActivity 80a331fa-8a4f-4313-977e-a253373e4ad6 ie. NOT the current one.
Created attachment 81239 [details] screenshot of task manager settings and activity manager (In reply to comment #12) > Since you don't have any use for activities: > > $ qdbus org.kde.kactivitymanagerd /ActivityManager/Activities CurrentActivity > > 4573827d-2181-47e8-ad46-1c4fcd87ccac > > $ qdbus org.kde.kactivitymanagerd /ActivityManager/Activities ListActivities > > d5f7667b-addb-42cc-9cfe-c21906afa687 > > 4573827d-2181-47e8-ad46-1c4fcd87ccac > > 80a331fa-8a4f-4313-977e-a253373e4ad6 > $ qdbus org.kde.kactivitymanagerd /ActivityManager/Activities StopActivity > d5f7667b-addb-42cc-9cfe-c21906afa687 > $ qdbus org.kde.kactivitymanagerd /ActivityManager/Activities StopActivity > 80a331fa-8a4f-4313-977e-a253373e4ad6 > $ qdbus org.kde.kactivitymanagerd /ActivityManager/Activities RemoveActivity > d5f7667b-addb-42cc-9cfe-c21906afa687 > $ qdbus org.kde.kactivitymanagerd /ActivityManager/Activities RemoveActivity > 80a331fa-8a4f-4313-977e-a253373e4ad6 > ie. NOT the current one. 1-Stripping ~/.kde4/ & other dirs KDE uses in $HOME easier than remembering all that when this happens. I'm dealing with a lot of systems and logins where this happens. 2-I wonder if the screenshot holds any clues to a cause? 3-How does one make that area upper left with the four icons and toolbar never appear for a new user? Could it be related to this problem?
(In reply to comment #13) > 1-Stripping ~/.kde4/ & other dirs KDE uses in $HOME easier than remembering > all that when this happens. Afaics this will likely get you back 3 activities instead of somehow solving the problem. And just deleting all configurations to deal with a particular issue is ... your problem ;-P You can also use the activity manager plasmoid to remove activities. > 2-I wonder if the screenshot holds any clues to a cause? No. > 3-How does one make that area upper left with the four icons and toolbar > never appear for a new user? Could it be related to this problem? /etc/skel or /usr/share configuration for the plasma desktop. Entirely unrelated, that's just a folderview plasmoid.
(In reply to comment #14) > > 2-I wonder if the screenshot holds any clues to a cause? > No. Since it differs so much from default selections, particularly "show tasks", which I would expect developers to test little or none, I had high hopes for yes.
(In reply to comment #15) > Since it differs so much from default selections, particularly "show tasks", > which I would expect developers to test little or none, I had high hopes for > yes. You've three activities, all running. Windows from other activities show up in the taskbar. Clicking such *should* activate the other activity; Pitfall: the window is also on a different virtual desktop and the taskbar does not enforce activation (while it should and does here) You can switch through activities using the plasmoid (activity manager) and see whether the konsole window is on at least one of them. If not, it's on some junk activity id (you can also compare the activity property with the activity list) - what however should actually not happen either. Nothing on the sceenshot would explain why either the window can move to a bogus activity or not be activated.
(In reply to comment #16) > (In reply to comment #15) > > > Since it differs so much from default selections, particularly "show tasks", > > which I would expect developers to test little or none, I had high hopes for > > yes. > > You've three activities, all running. I don't have any idea what created them. I very rarely left click anywhere on the desktop, with one major exception, missing when trying to grab a window edge to try to resize, which probably happens more often than not. > Windows from other activities show up in the taskbar. > Clicking such *should* activate the other activity; > Pitfall: the window is also on a different virtual desktop and the taskbar > does not enforce activation (while it should and does here) What window is on a different virtual desktop? I see 5 empties and current in the pager. > You can switch through activities using the plasmoid (activity manager) and Except there should only be one, since I didn't add any intentionally. > see whether the konsole window is on at least one of them. > If not, it's on some junk activity id (you can also compare the activity > property with the activity list) - what however should actually not happen > either. Is there some way to get all that info without 5 minutes of lookup and typing? Xterm history is out, as they're apparently committed to sub-legible mousetype, while Konsole is hiding inaccessibly in plain sight. > Nothing on the sceenshot would explain why either the window can move to a > bogus activity or not be activated. Nothing there in any way explains in any way I understand why there is more than one existing activity either.
(In reply to comment #17) > > You've three activities, all running. > I don't have any idea what created them. You, by deleting config files or just never removing them. Don't ask me why there're three activities by default: i don't know and this is the wrong place to discuss such (-> forum.kde.org) > What window is on a different virtual desktop? According to the screenshot: none. If however the konsole window for some weird reason would (but then should not appear in the taskbar either - while it's for the moment not trustworthy because of this bug), it would not (unforcefully) be activatable. > Is there some way to get all that info without 5 minutes of lookup and > typing? C'n'P the commands into a shellscript, make it executable. Command history is btw. a feature of the shell (bash), not the terminal (xterm/konsole)
(In reply to comment #18) > (In reply to comment #17) > > > You've three activities, all running. > > I don't have any idea what created them. > You, by deleting config files When I delete config files because of KDE trouble I delete all that WRT KDE result in the same effect as a brand new virgin KDE login/user. I keep such files as .bashrc, .dmrc, .Xdefaults, .mozilla/, .mc/, .fonts/ & .opera/, deleting pretty much anything that a vivid imagination could imagine having any KDE dependence or influence. Two exceptions: nepomukserverrc & nepomukstrigirc, since nepomuk and soprano cannot be blocked or expunged at the package level. Such deletions are always performed while X is not running. Thus any activities created were created by KDE, not me. I don't click on anything that says "create an activity", or would give a happy KDE3 user some indication such would be the result of some familiar traditional pointing device action. > > Is there some way to get all that info without 5 minutes of lookup and > > typing? > C'n'P the commands into a shellscript, make it executable. Easy enough maybe for a single person with good memory for rare incidents using a single computer, not with dozens of installations sprawled across many machines.
Created attachment 81285 [details] activitiy fixing/wiping script The ability to say "i don't know how to do that" is not in you, is it? The attached script "fixes" windows by removing any invalid activity properties from all windows. If called with "force" as parameter, it will just withdraw all activity properties. I was not able to move a window to an invalid activity (kwin fixes it)
Created attachment 81286 [details] fixing script that can handle windows on legal and illegal activities just came to my mind that the window could be on one illegal ans some legal activities
Created attachment 81289 [details] script operating on org.kde.ActivityManager From latest findings on other bug, the service registration of the activitymanager may be wonky
*** Bug 322718 has been marked as a duplicate of this bug. ***
Problem continues in 4.11.2 (openSUSE).
We still lack information about on what activities the windows are and whether those activities exist and are running or whether running the script to remove activity properties from windows. KWin does not create activities and i've no ieda what would (nothing has ever randomly created activities here)
I'm unable to understand how difficult is is for devs to duplicate this, as I have so many different installations and users able to experience this. Would zipping up and attaching the content of ~/.kde(4) from a session that starts this way be of any use? The most recent was from an openSUSE 13.1RC1 installation just performed, virgin user, except for the following copied from 12.3: .config/fontconfig/ .config/mc/ .config/Trolltech.conf .kde4/share/config/nepomukserverrc, containing: [$Version] update_info=nepomukstrigiservice-migrate.upd:nepomukstrigiservice-migrate [Basic Settings] Start Nepomuk=false [main Settings] Storage Dir[$e]=$HOME/.kde4/share/apps/nepomuk/repository/main/ Used Soprano Backend=null rebuilt index for type indexing=false [Service-nepomukstrigiservice] autostart=false .kde4/share/config/nepomukstrigirc, containing: [General] exclude filters=autom4te,*.rcore,CTestTestfile.cmake,*.o,*.omf,.hg,*.m4,*.orig,moc_*.cpp,conftest,.xsession-errors*,CMakeTmpQmake,*.tmp,po,.svn,.histfile.*,lzo,.bzr,.git,litmain.sh,cmake_install.cmake,CMakeFiles,*.pc,*.nvram,*.elc,*.la,CMakeCache.txt,confdefs.h,*.gmo,*.csproj,*.rej,config.status,lost+found,confstat,*.pyc,_darcs,CVS,*.part,libtool,*.aux,*.po,CMakeTmp,Makefile.am,*.lo,*.loT,*~,*.moc,*.vm*,*.class,core-dumps exclude filters version=2 folders[$e]=$HOME/tmp/null index hidden folders=false index newly mounted=false .local/share/applications/ .mc/ .mozilla/ bin/ .bashrc .dmrc .kderc
Run the attached script and qdbus --literal org.kde.ActivityManager /ActivityManager/Activities ListActivitiesWithInformation ps ax | grep kactivity #ie. whether the activity manager is running on an affected system and report the output and whether it restores inaccessible windows. That is the really important runtime data to know what's going on there in the first place (whether there are windows on invalid activities and what activities of what state are there) The only interesting rc should be ~/.kde/share/config/activitymanagerrc The session is restored from ~/.kde/share/config/session/* And also kwin stores override rules about where to put windows in ~/.kde/share/config/kwinrulesrc This data might be worth a look, but only when knowing what to look for.
1-Virginize user during "runlevel 3" 2-startx 3-configure digital clock 4-configure task manager (no group, no sort, uncheck only when full, uncheck only current activity) 5-adjust panel height (53) 6-select classic menu style 7-application launcher menu settings a-deselect leave b-select log out c-set recently used to 10 d-deselect recently installed e-select show menu titles 8-open systemsettings a-adjust all fonts to 10 b-set small to 9 c-set taskbar to 9 d-set window title to bold e-enable anti alias slight f-turn on sound for open session and close session g-set paper size to letter h-set first day to Sunday i-deslect all checkboxes re screen edges j-turn on NUM k-set repeat to 20 l-set delay to 250 m-deselect button events handling n-set switch off after to 120 o-deselect confirm logout 9-open Konsole a-set current to white on black b-size to 40 rows c-size to 120 columns d-execute a script <http://fm.no-ip.com/Tmp/Linux/Xorg/xfetch07.sh> 10-log out 11-startx 12-attached script via "run command" 13-attached script from xterm redirect to file 14-log out 15-startx 16-attached script from xterm redirect to file: [redirect] ------------------------- Current Activity: ed96c167-f47e-434a-aff8-09d9d9bda5ec All Activities: 0a9f177e-8e57-4fc3-a745-9a3c4e6c8c28 ed96c167-f47e-434a-aff8-09d9d9bda5ec ======================== Checking ... Everything Ok. All Windows are on existing activities. Maybe on a stopped one? [/redirect] Both cases of redirect resulted in same content. Meanwhile, Konsole was stuck on the taskbar the whole time from starting session second time, until I right clicked to select to close it. After that I started it back up, logged out, startx, and it resumed where it belonged at 0,0. openSUSE 13.1RC1 kde-gtk-config-2.2.1-3.2.i586 kde4-filesystem-4.11-5.1.i586 kde4-kgreeter-plugins-4.11.2-2.1.i586 kdeartwork4-sounds-4.11.2-1.1.noarch kdebase4-artwork-4.11.2-1.1.noarch kdebase4-libkonq-4.11.2-1.1.i586 kdebase4-nsplugin-4.11.2-1.1.i586 kdebase4-openSUSE-13.1-8.4.i586 kdebase4-runtime-4.11.2-1.1.i586 kdebase4-runtime-branding-upstream-4.11.2-1.1.i586 kdebase4-session-4.11-3.3.noarch kdebase4-wallpaper-default-4.11.2-1.1.noarch kdebase4-workspace-4.11.2-2.1.i586 kdebase4-workspace-branding-upstream-4.11.2-2.1.i586 kdebase4-workspace-ksysguardd-4.11.2-2.1.i586 kdebase4-workspace-liboxygenstyle-4.11.2-2.1.i586 kdelibs4-4.11.2-1.1.i586 kdelibs4-branding-upstream-4.11.2-1.1.i586 kdelibs4-core-4.11.2-1.1.i586 kdepimlibs4-4.11.2-1.1.i586 kdm-4.11.2-2.1.i586 kdm-branding-upstream-4.11.2-2.1.i586
Previous comment I forgot about: qdbus --literal org.kde.ActivityManager /ActivityManager/Activities ListActivitiesWithInformation ps ax | grep kactivity #ie. whether the activity manager is running after running the script, and could not duplicate the problem until revirginizing after which: ------------------------- Current Activity: a78550cc-7fc6-4c96-b0c9-60de2ab2233f All Activities: fbdfaf45-ed61-41f7-b6b4-e4b11ced1730 a78550cc-7fc6-4c96-b0c9-60de2ab2233f ======================== Checking ... Everything Ok. All Windows are on existing activities. Maybe on a stopped one? [Argument: a(sssi) {[Argument: (sssi) "fbdfaf45-ed61-41f7-b6b4-e4b11ced1730", "New Activity", "", 2], [Argument: (sssi) "a78550cc-7fc6-4c96-b0c9-60de2ab2233f", "Desktop", "", 2]}] 6851 ? Sl 0:00 /usr/bin/kactivitymanagerd 7134 pts/3 S+ 0:00 grep --color=auto kactivity Konsole is still stuck on the taskbar. PS, FWIW: Xorg is configured with 'Option "Composite" "Disable" on all my installations.
On different host big41 configured with the same OS and packages, but running 64 bit instead of 32, if I do exactly the same from virginizing through starting Konsole, but don't use Konsole, then on alternate sessions Konsole appears as expected on desktop on odd sessions but only on taskbar on even sessions. This is from a session with Konsole stuck on taskbar (using an xterm window to execute the commands; redirected to a file): ------------------------- Current Activity: 50924eb7-601b-439d-a58a-fbdaf71f323b All Activities: 50924eb7-601b-439d-a58a-fbdaf71f323b 42262bc1-eb5f-4f83-b049-ce6669c7c13b ======================== Checking ... Everything Ok. All Windows are on existing activities. Maybe on a stopped one? [Argument: a(sssi) {[Argument: (sssi) "50924eb7-601b-439d-a58a-fbdaf71f323b", "Desktop", "", 2], [Argument: (sssi) "42262bc1-eb5f-4f83-b049-ce6669c7c13b", "New Activity", "", 2]}] 4592 ? Sl 0:00 /usr/bin/kactivitymanagerd 5096 pts/4 S+ 0:00 grep --color=auto kactivity
Ok, sum up: - There two running activities - No window is on an invalid activity - Konsole is (most likely) on "the other" activity - Activating Konsole from the taskbar does not switch to the other activity. Confirmation that konsole is on "the other" activity: either - just switch to the other activity and see whether it's there, or - compare : xprop -id `xwininfo -tree -root | sed '/konsole/ !d; /^ /!d; s/^ \(0x[^ ]*\).*/\1/'` | grep _KDE_NET_WM_ACTIVITIES with qdbus org.kde.ActivityManager /ActivityManager/Activities CurrentActivity Running the script and passing "force" as only parameter should immediately show the konsole window on the current activity. --- I'll assume that as confirmed for the rest. --- In this case, the only reason i could think of why activating konsole on the other activity would not work is that "your copy" of libtaskbar doesn't force activation (it's supposed to and does here) and it's on a different virtual desktop as well (or you're using a strict focus stealing protection, high or extreme should iirc hit) --- Now, why would this happen in the first place? --- The "Desktop" and "New Activity" activities seem to stem from plasma-desktop (at least it uses both names as defaults to create activities) - why it would create which for what purpose we'll have to ask plasma devs; i've no idea. --- What will presumingly happen: - You log in, ""Desktop" and "New Activity" are created, "Desktop" is active - "New Activity" gets activated (that's somehow important) - you launch konsole - you log out - you log in, "Desktop" is active again. --- You can check this by recording qdbus org.kde.ActivityManager /ActivityManager/Activities CurrentActivity on each step (the name is less important than the id) and running xprop | grep _KDE_NET_WM_ACTIVITIES and then click the just started konsole window to figure what activity it gets assigned to. (The IDs would be more important than the actual name) --- But i really can't tell why the activities are added or started this way ---> Ivan?
Created attachment 82865 [details] Workaround rule Attached is a rule to force all windows to be on all activities. run "kcmshell4 kwinrules", click import and select the file. Then apply. This should also immediately show all "missing" windows (well, unless they're minimized or on another virtual desktop)
(In reply to comment #32) > But i really can't tell why the activities are added or started this way Apparently you cannot reproduce this yourself. This indicates you are not using openSUSE, while I'm focused on openSUSE, and don't remember whether or not I can reproduce in Mageia or Fedora. It also indicates there's something unique about openSUSE's packaging of KDE that causes me to be able to reproduce this on so many installations. This is overwhelming me, conflicting with other demands on my time. So being that openSUSE 13.1 has already reached RC with no fix to this imminent, it looks like I need to file downstream, unless some KDE developer can very soon reproduce on his own system to fix this. I don't do anything consciously to cause creation of any new activity whatsoever. I don't know how activities work, nor do I care. I have only one "activity", KDE workspace. *My* activities are handled via use of virtual desktops and multiple users. Apparently what is needed but not available is a system level KDE config setting that unconditionally disallows the number of KDE "activities" to exceed one, unless that's what the comment 33 attachment is supposed to be, in which case it needs to be easier to apply, implemented system wide via config file someplace in /etc/kde(4)/.
(In reply to comment #34) > I don't do anything consciously to cause creation of any new activity > whatsoever. I don't know how activities work, nor do I care. I have only one > "activity", KDE workspace. bug 321781 ?
(In reply to comment #34) > Apparently you cannot reproduce this yourself. I've not yet tried your step list - (not logged out so far ;-) That it didn't happen to me so far does not mean it can not. Hrvoje has likely pointed the bug that causes activity creation and it's reported for gentoo. > unless that's what the comment 33 attachment is supposed to be No. The attachment is a rule that affects KWin only and unconditionally forces all windows to be on all activities (eg. no matter what the window wants) The rule system is in general supposed to allow users to tell KWin "I know better than the stupid client, do as I say" - it's not for "regular" usage and covers many more things than just activities.
Bug #321781 seems timing related (cold boot, warm boot, GL ./. XRender effects ...) and it seems to cause stm. like "trying to alter state of unknown activity!!" what could explain why we cannot switch to the activity with the window on it.
(In reply to comment #36) > (not logged out so far ;-) Probably better you don't. If you have only one system to work with, instead, use a virgin extra user to more conveniently preserve your settings/configuration/open apps in following the path I took, like so: Ctrl-Alt-F5 login: testuser $ startx -- :1
(In reply to comment #32) > xprop -id `xwininfo -tree -root | sed '/konsole/ !d; /^ /!d; > s/^ \(0x[^ ]*\).*/\1/'` | grep _KDE_NET_WM_ACTIVITIES > with > qdbus org.kde.ActivityManager /ActivityManager/Activities CurrentActivity I copied from the comment and pasted into a file, removed the "with" and blank lines, then ran it as a script in xterm on yet another host (m7ncd) exhibiting this. It gives a usage message for xprop followed by the qdbus output, which looks rather like a UUID string.
(In reply to comment #33) > Created attachment 82865 [details] > Workaround rule > Attached is a rule to force all windows to be on all activities. > run "kcmshell4 kwinrules", click import and select the file. Then apply. > This should also immediately show all "missing" windows (well, unless > they're minimized or on another virtual desktop) This succeeded to raise Konsole off the taskbar on host m7ncd. :-)
(In reply to comment #39) > It gives a usage message for xprop followed by the qdbus > output, which looks rather like a UUID string. bugzila.... remove the newline before "s/", it's part of the sed function, not a new command.
Created attachment 82878 [details] script used per comments 32 & 39 (In reply to comment #41) > bugzila.... remove the newline before "s/", it's part of the sed function, > not a new command. As I wrote, I copied and pasted from your comment in this bug. It's hard to see where spaces belong trying to type what I see in a browser window manually. I don't "see" newlines except twice, after "TIES" and after last "vity".
(In reply to comment #42) > Created attachment 82878 [details] > script used per comments 32 & 39 That has condensed whitespace compared to what my browser prints in the comment (there's also no false linebreak). CnP of the comment command works perfectly here. Notice that there needs to be a konsole window (visible or not) in order to have the xprop command work properly.
(In reply to comment #43) > That has condensed whitespace compared to what my browser prints in the > comment (there's also no false linebreak). > CnP of the comment command works perfectly here. Apparently C&P works differently there and here. I only ever get at most one space anywhere. I can't tell what amount of whitespace is intended. I don't know what a false linebreak is either. Please attach here a script that works.
I saved this whole bug page as HTML, then cut it down to the comment 32 script. The result has two instances of strings of 11 contiguous spaces. Both lines of output show the same ID string, but with or without force as input, Konsole stays stuck on the taskbar. I tried, unsuccessfully, to reproduce this on same host m7ncd booted to Fedora 19 running 4.11.2.
Created attachment 82929 [details] comment #32 script run the attached script, minor adjustment to only catch konsole and not windows with "konsole" in a random caption position
On single core hyperthreading 3.0GHz P4 i945G/ICH7 host gx62b it took a bunch of tries before Konsole 4.11.2 got stuck on the taskbar Comment 46 script output: ------------------------------- Konsole Activity: _KDE_NET_WM_ACTIVITIES(STRING) = "17fd6dcc-f37a-4b4b-b327-4a3104c56ed5" Current Activity: 17fd6dcc-f37a-4b4b-b327-4a3104c56ed5 -------------------------------
(In reply to comment #47) > On single core hyperthreading 3.0GHz P4 i945G/ICH7 host gx62b it took a > bunch of tries before Konsole 4.11.2 got stuck on the taskbar > > Comment 46 script output: > ------------------------------- > Konsole Activity: > _KDE_NET_WM_ACTIVITIES(STRING) = "17fd6dcc-f37a-4b4b-b327-4a3104c56ed5" > > Current Activity: > 17fd6dcc-f37a-4b4b-b327-4a3104c56ed5 > ------------------------------- Ok, that window is on the active activity. It does not activate through the taskbar though, but it appears when applying the activity forcing rule? Sounds strange enough. Ok, let's rule out the taskbar. - Install "xdotool". - When you got a "stuck konsole", run xdotool search --class konsole This will print some numbers like: 16777220 16777228 16777236 16777244 One of them (usually the last) is the actual konsole window. Next run xdotool windowactivate --sync 16777244 If this prints sth. like XGetWindowProperty[_NET_WM_DESKTOP] failed (code=1) this was simply not the actual konsole window, try another number. At some point the window should activate (despite being minimized or on another virtual desktop)
3.06GHZ core2duo host big41: ------------------------------- Konsole Activity: _KDE_NET_WM_ACTIVITIES(STRING) = "50924eb7-601b-439d-a58a-fbdaf71f323b" Current Activity: 50924eb7-601b-439d-a58a-fbdaf71f323b ------------------------------- # xdotool search --class konsole 41943041 41943049 41943057 41943065 # xdotool windowactivate --sync 41943065 # xdotool windowactivate --sync 41943057 XGetWindowProperty[_NET_WM_DESKTOP] failed (code=1) # xdotool windowactivate --sync 41943049 XGetWindowProperty[_NET_WM_DESKTOP] failed (code=1) # xdotool windowactivate --sync 41943041 XGetWindowProperty[_NET_WM_DESKTOP] failed (code=1) (In reply to comment #48) > but it appears when applying the activity forcing rule? Does it? Adding force or --force as parameter to the comment 46 script changes nothing I can see. Do you mean the comment 33 rule? Is it supposed to be kept in play still?
(In reply to comment #49) > # xdotool windowactivate --sync 41943065 Did konsole show up after this call? > Does it? Adding force or --force as parameter to the comment 46 script > changes nothing I can see. Do you mean the comment 33 rule? The rule. I was rather asking for based on comment #40, i was under the impression that adding the window rule made the konsole window available. > Is it supposed to be kept in play still? Not if it breaks debugging, ie. "fixes" the problem of non activatable windows.
(In reply to comment #50) > (In reply to comment #49) > > # xdotool windowactivate --sync 41943065 > Did konsole show up after this call? No. > > Does it? Adding force or --force as parameter to the comment 46 script > > changes nothing I can see. Do you mean the comment 33 rule? > The rule. I was rather asking for based on comment #40, i was under the > impression that adding the window rule made the konsole window available. It did. I applied it on host m7ncd only, but naturally going through the whole virginizing process would eliminate it.
On same hardware as which openSUSE is installed, I cannot reproduce this in 4.11.2 in either Fedora or Mageia.
From all input (thanks alot, btw.) i'd say there's some race condition related to the activities assigned by the session data and obtaining the current activity which ultimately leads a window on the current activitiy not getting mapped (while it should) I'll hunt it down (sounds like a promising game) If you can make use of a patch, one could temporarily brute-force ensure a window is mapped when it gets activated (beyond any other state) - something we might consider anyway...
If I needed a workaround on a normal system the one in comment 33 should suffice. I only use what others build, no patching except temporarily to a script or config file. My comments here have all been generated from use of systems used primarily or exclusively for testing pre-release Linux distros, pre-release web browsers, and web design accessibility.
Ok. Btw, if my assumptions about the problem are correct, rightclicking the taskbar entry and (first unminimizing, then) minimizing, then unminimizing the window should show it.
Clicking minimize on m7ncd host produces no checkmark, only closes the menu. Clicking maximize toggles the checkmark, but otherwise only closes the menu. I was able to produce the problem in Mageia 4/4.11.2 last night, but using wrong (fallback to VESA) X video driver instead of FOSS ATI/Radeon, which appears to load but X refuses to use.
"Blast" See this script: http://kde-look.org/content/show.php?content=161428 It will allow you to print WM internal status information about all windows. Check the description about how to configure debug out (there's no explicit print target in qscript/kwin) We'll then see whether a) konsole is in the list of managed windows at all b) on what activities KWin believes the window to be c) "other stuff" (like what geometry it has, on what screen and virtual desktop it is etc.)
Comment 57 made me think this problem may have arisen coincident with the replacement of krandr with kscreen. All my systems have a PreferredMode set in /etc/X11/xorg.conf*. (In few setups does the PreferredMode coincide with the EDID preferred mode.) In order that PreferredMode be obeyed at each session start, it is necessary on all my installations to have [Module-kscreen] autoload=false in /etc/kde[4]/share/config/kdedrc. Could this be why I cannot not reproduce and few or none others can? (comment 57 reply to follow as time permits)
(In reply to comment #58) > Comment 57 made me think this problem may have arisen coincident with the > replacement of krandr with kscreen. If it's a matter of "konsole is (on some powered) off screen" this should be easy to figure. compare the geometries obtained by xwininfo -id <konsole_wid_here> | grep geometry and xwininfo | grep geometry # pick the desktop or xrandr -q might be that the temporarily unmapped (not on current activity as there's no activity yet) konsole window manages to escape the visible screen bounds.
(In reply to comment #57) > See this script: http://kde-look.org/content/show.php?content=161428 > It will allow you to print WM internal status information about all windows. > Check the description about how to configure debug out (there's no explicit > print target in qscript/kwin) I don't know how to enable use of this "script". Viewing the file downloaded it looks like some kind of archive, not a script.
The most simple way to install the script (it' sin fact a zip archieve under the hood) is to use "kcmshell4 kwinscripts" (it's also in system settings) and either import or "get new script" it (latter directly accesses the kde-look.org server) Meta+Ctrl+Alt+D is autoregistered with the script and can be altered in "kcmshell4 keys" (triggering the shortcut will dump a snapshot of all current clients and their attributes into the debug output) Ensure to redirect all kwin debug output into a file using "kdebugdialog --fullmode".
[big41] I don't think the key combination defined on http://kde-look.org/content/show.php?content=161428 is working. No file is generated after using it, nor is there any observable response. I've never before needed any "meta" key. http://en.wikipedia.org/wiki/File:ModelM.jpg is the keyboard I use for most testing. The kcmshell4 applet accepts the designation of filename, in that on reopening it after closing it the same filename reappears in the designated space, but the "Apply" button always remains selectable after clicking it instead of being grayed out. (In reply to comment #61) > The most simple way ... (it's also in system settings) Where in systemsettings?
(In reply to comment #62) > [big41] > I don't think the key combination defined on > http://kde-look.org/content/show.php?content=161428 is working. No file is > generated after using it The script does NOT generate any ouput file. It writes into the global debug output for kwin, which can _only_ be adjusted in "kdebugdialog --fullmode" (Filter for "1212", set all to "File" and enter some absolute path like "/tmp/kwin.dbg" - after pressing "Apply" kwin should start to write there) > nor is there any observable response. I've never before needed any "meta" key The "Meta" key is the "windows" key on most keyboards - just adjust the shortcut if you don't have one (but since it's global, i picked a rather complex one as default) > The kcmshell4 applet accepts the designation of filename, in that on > reopening it after closing it the same filename reappears in the designated > space, but the "Apply" button always remains selectable after clicking it > instead of being grayed out. The scripts can be un/checked - those which are checked are loaded, the others are unloaded. It's pretty much the same dialog as for the effects. > Where in systemsettings? Windowbehavior - it is the exact same kcm - just in a different context.
This is happening in 4.11.2-3 in Mageia 4 (Cauldron) on a different host, gx27b, also running radeon rv200 gfx, but with FOSS ati/radeon driver.
Please load the script and dump the output into a file via "kdebugdialog --fullmode" It's still unclear why the window is not shown - and the issue is still not reproducible either.
Created attachment 83510 [details] screenshot response to comment 65 (from running attachment 82929 [details]) (In reply to comment #65) > Please load the script and dump the output into a file via "kdebugdialog > --fullmode" From first run of script on openSUSE 13.1/4.11.2/radeon host m7ncd. Second run redirected to file: ------------------------- Current Activity: e26ec012-993d-4488-b092-0455ab9d7496 All Activities: e26ec012-993d-4488-b092-0455ab9d7496 26851ee9-ef16-4083-b6dc-86281e85abc7 ======================== Checking ... Everything Ok. All Windows are on existing activities. Maybe on a stopped one? > It's still unclear why the window is not shown - and the issue is still not > reproducible either. Reproducible more often than not here on openSUSE, occasionally on Mageia, not at all so far on Fedora. I'm not aware that I ever do anything whatsoever to cause creation of more than one activity. Script fails to raise Konsole off the taskbar.
Occurring on host gx27b running Mageia 4/KDE 4.11.3.
Kinda missed the last comment. I meant the kwin script to debug all clients from within KWin, not the one checking the window properties. (see commet #60 and following)
Happening in a fresh installation with 4.13.1 (Cauldron).
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
Cannot reproduce with Plasma 5.22. Can anyone?
I cannot remember when I experienced this last, so must be many moons ago, likely expired with expiration of KDE4.