Bug 260360

could this be a kwin bug?

On Friday 17 December 2010 16:59:55 Beat Wolf wrote:
> could this be a kwin bug?
sounds more like an activity bug. AFAIK Present windows still shows all 
windows from all activities.

I don't believe that it matters for this bug but, but I configured "Present Windows" to show only the windows on the current desktop and on the current screen, and as far as I can tell, that works as advertised for me. 

I just mentioned "Present Windows" to show that windows are there and not just minimised or shaded. If I open an application (Konsole, Brower, etc.), its window is created and functions in principle, but it is not shown and I cannot click nor type in it, since it is invisible.

The exception are windows that are to be "Immer im Vordergrund"(Always in foreground), which are still shown/

Minimized windows would by default be shown as well.

- If you run "present windows" and click a (so far hidden) window - does it raise/show up afterwards?
- Do you use the normal "click to activate"/clickraise selection type?
- Could this be a netbook shell thing? I.e. "ps -Af | grep plasma" prints "plasma-netbook"

1. No. Selecting a window via Alt-Tab or PresentWindows does not raise it to the foreground. Once I release AltTab or end the PresentWindows effect, all I see is the background.

2. No,  I am not using the netbook variant
> ps -Af | grep plasma
jost      2812     1  0 12:21 ?        00:00:27 kdeinit4: plasma-desktop [kdeinit]             
jost     14955 14945  0 13:22 pts/5    00:00:00 grep plasma

Sorry, I forgot to answer that one:

3. Yes, I am using "Aktivierung nach Klick"(i.e. click to activate).

That's quite weird :\
Either it's activity related (but then why should keep above windows be present? 'nother bug?) or the desktop is no desktop and tagged keep above...

Can you please "xprop > plasma.xprop", click the offending desktop and post/attach the output?

Created attachment 55093 [details]
Xprop output while the bug is showing

I created this file as requested when the bug showed this morning upon booting.

I hit Ctrl-Alt-F1 to lookup the xprop command, which I had forgotten. Then I returned to the graphical screen with Ctrl-Alt-F7. Then I hit Alt-F2 for Krunner to enter "xprop > PlasmaBad.xprop", since I cannot use a Konsole window while the bug is showing.

The laptop was undocked, using only its internal screen. Previous boot was also undocked with the same resolution, although the background had been faulty, showing me the downscaled background pictures of both twinview screen from the previous boot on the one single screen (another probably unrelated bug that occurs sometimes when switching resolution).

Created attachment 55094 [details]
Xprop output after avoiding the bug with activity switching

This is the similar xprop output, just after I circumvented the bug by switching to another (identical) activity and stopping the initial activity. (I only have those two identical activities, since I don't get the activity idea yet and don't use them.) 

A few lines of the output have changed, but it does not make sense to me.

I also obtained this file by entering the command into Krunner. I did not start any other application or anything. I only switched activities before obtaining this xprop output.

Hope that helps! :)

Created attachment 55095 [details]
Again xprop output while bug is showing

And here is another one while the bug is showing.

I just rebooted and the bug happened to show again, so I took another xprop output for comparison. 

Note that there was no change in resolution nor the number of screens for the last three boots (i.e. single screen 1920x1080).

I must also add that widgets are shown when the bug is active. Windows and panels are not shown. (I have three panels: screen1,lower edge:windows go below; screen1,left edge:autohide; screen2, right edge:autohide.)

did you actually both times click the desktop (not some kind of panel), because the faulty outputs have both:
   _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK
   WM_WINDOW_ROLE(STRING) = "panel_0"
and (!)
   WM_NORMAL_HINTS(WM_SIZE_HINTS):
	user specified size: 32 by 528
	program specified size: 32 by 528
	window gravity: NorthWest

(looks like one of the autohide panels (left one?), the width is 32px)

while the working one has (proper)
   _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DESKTOP
and
   WM_NORMAL_HINTS(WM_SIZE_HINTS):
	user specified location: 0, 0
	program specified location: 0, 0
	user specified size: 1920 by 1080
	program specified size: 1920 by 1080
	window gravity: Static

a dock type "desktop" would however explain why only keepabove windows can raised above it (but the size hint is wrong)

Yes, I clicked the background picture. However, it could be that I accidentally clicked something I could not see.

How do I determine the width of the panels? The adjusting the width of the left auto-hide panel give a mouse-text saying 54. The number displayed while adjusting the height of the lower "windows-below" panel is 954. The right-edge auto-hide panel is currently inaccessible, since I only have a single screen today, while I am away from my office.

Suspend compositing. Whatever you can not see then is just not there ;-)

Is your lower panel really 954px high? (~90% of your screen height...)
You can roughly determine sizes by using "kruler".

1) Ok, next time the bug occurs, I will try to suspend compositing first.

2) Of course not! I just wrote the value down as it is displayed when adjusting the height. My lower panel, holding just the systray and time, is actually very thin. It is about 24pixels high, if I can read kruler right.

PS: and the auto-hide panel on the left edge is rather 30 pixels wide, according to Kruler, and not the 68 that is displayed now when I adjust it (I swear it displayed 54 this morning, without me adjusting anything).

Created attachment 55101 [details]
Xprop with Compositing deactivated

Lucky unlucky day: Every single boot today turned up this silly bug.

So this allows me to provide the xprop output once more, with compositing deactivated as requested. I definitely clicked the background, not a widget, not near a panel, nor anywhere where an invisible window could have been.

ok, everything in this window says that it's a dock.

the weird things are that
a) it looks like the desktop
b) the promoted size (32x528) do not match the effective size (1920x1080)

Is it possible that plasma-desktop "somehow" reparents the desktop into one of the panels?

@Steffen
does the problem go away if you unset the "autohide" character of the two side panels?

Well, the problem isn't always there, so it is hard to verify this, especially since I usually only boot once per day. 

Nevertheless, I will disable auto-hide and run the machine for a week and see what happens. 


Not that I know anything about this kind of stuff, but could there be a problem with the panel on the right edge being on the second screen, which is not there when I am booting with a single screen? I mean, this used to be buggy in previous KDE4 versions. For example, not so long ago, the right panel appeared on the right edge of the first screen if the second screen wasn't there. Then at the next booting with two screens, it remained in the middle between the two screens, although the unhide animation had it flying in from the right edge of the second screen to the left edge of the second screen (i.e. the middle).

Ok, I switched all three panels to "windows go below" and then to "always visible", but the bug still occurs like before.

It appears pretty much every time I boot with a single screen (laptop undocked) and very rarely in a TwinView setup when docked.

Anything else I can do or provide?

Could this bug be activity related ? I ask because the only way I found to make it disappear is to change one of my activities (don't why I have it) from "desktop" to "folder view". I think I created this activity when plugging a second screen. And it seems that when I don't have this second screen, the activity is above nearly everything.

possibly, but why the heck in a dock?
does the issue disappear if you just remove the extra activity?

Chani?

I can create new activity, but I have not yet found a way to delete one :-$, sorry. (Will try to edit a .kde4/... file)

first click the stop button, then it'll be replaced with a delete button. yes, it is a bit confusing at first :)

the activitymanager plasmoid lets you delete them without stopping, but there seems to be a bug in that at the moment - I got undead activities that way ;)

First, sorry for the lag between my answers.
Ok done that and all was appearing at this very moment. Then I restarted KDE and the problem was still there :-s
The only activity I have is an unnamed one (default ?). And when i switch it to folder view, everything is appearing again. Is there a way to not have any activity ?

I went to the point of having no activity anymore (on the list at least). The problem still occurs.

I can confirm everything Steffen said. The only exception is that the bug appears always at boot with a single monitor setting and never with a two monitor setting (i.e. extended desktop setting; the "clone" setting behaves as the single monitor one), so there is no randomness. But from the beginning:

KDE 4.5.5
kernel 2.6.34.7-0.7-default i68
single monitor setting: 1680x1050 on dvi0
dual monitor setting: dvi0 as above and dvi1 as right desktop extension with a resolution of 1440x900

The bug first appeared after switching from twinview to single monitor with the ati control center (driver version: ATI Catalyst 11.2), so a hot switch. But the problem persists even with the open source driver on my ati radeon HD4800. After I switched the settings all appeared fine except there was a rectangluar box on the screen which was either black or colored like my desktop background and was always on the front, so all windows disappeared behind it.

Thanks to Steffen's workaround I can use the single monitor view and also added the xprop output after booting ("with_bug.xprop") and after I did the workaround ("with_workaround.xprop"). I tried to select the same pixel and not to click on something other then the desktop. Before I did the workaround, it doesn't matter where I click, even at the position where my panel should be. It always produces the same xprop output.

Notice the lines

		user specified size: 1440 by 27
		program specified size: 1440 by 27

in "with_bug.xprop" and that the resolution of my _second_ monitor (not plugged in at this moment) is 1440x900.

Should I post xprop outputs with the two monitor setting, too?

As I played with two monitors the first time (i.e.e before the bug appeared), I noticed two new activities I haven't created and deleted them. Maybe this has something to do with the bug?

In the one monitor setting I have one panel at the bottom of the screen. As the bug first appeared, I noticed that it is gone and so I created (a couple of times) new panels (with I weren't able to see, too). I deleted them all afterwards but there seems to be one invisible panel left at the top of the screen. It's even invisible after the workaround. I noticed it because all info popups like "dropbox daemon started" or something like "Firefox: Download finished!" appear not only in the right bottom corner (where they should be) but also in the upper left one.

Created attachment 57329 [details]
xprop taken after boot with the bug

Created attachment 57330 [details]
xprop taken after the workaround at the same spot

I noticed that all widgets on my plasma dashboard became invisible, too.

Created attachment 57641 [details]
plasma-desktop-appletsrc with bugs

I found the source of the symptoms but not the source of the bug. But I will present a workaround which have to be applied only once until the bug appears another time (i.e. plugging in and out the second monitor).
Look at the attached file ("plasma-desktop-appletsrc") which you will find at ~/.kde4/share/config/ on your pc. Everytime I talk about "#x", I mean "[Containments][x]". In my case the structure of the file is like that:

#85: desktop of the primary screen
#147: desktop of the secondary screen
#3: panel of the primary screen
#152: panel of the secondary screen
#94: Dashboard (I chose the setting "Dashboard: Show an Independent Widget Set")

So the file is clearly wrong at some parts because I have only the primary monitor (1680x1050) plugged in and all settings confirm that.

After deleting #147 and #152 and logging in again, the bug disappeared, i.e. all windows and my panel were visible again because they aren't hidden behind panel #152 anymore (which shouldn't be there anyway because I'm in a single monitor setting). My dashboard kept invisible though and while trying to fix this, I observed some other bugs concerning the dashboard, so I simply deleted it out of frustration.

The source of the bug seems obvious: When you plug the second monitor in for the first time, a new desktop (#147) is created and I created the second panel (#152). If you now deactivate this monitor in the settings (like I did) or simply plug it out online or offline (like the other users here), the desktop and panels are not removed from the file "plasma-desktop-appletsrc".
Switching activities worked as a workaround because when you stop an activity the corresponding desktop (e.g. #85) is deleted from the file and written to the folder ~/.kde4/share/apps/plasma-desktop/activities/ (with the activity-ID as filename). I you start it again, it's written back and as a result of that the right desktop (#85 with its panel #3) appears in the foreground and (if you don't stop the second activity) the second desktop (#147 with its panel #152) appears in the background.

I haven't activated the second monitor yet, but I think my second desktop etc. will be gone (but it should be saved in another file) and if I deactivate it, the bug will appear again, so it has to be fixed.

Notice that there is another file called "plasma-desktop-screen-1-appletsrc" which only contains two desktops with the standard settings (opensuse wallpaper etc.).

Now it should be simple to fix this bug. I'm sorry that I'm not just that into linux yet to fix it myself. But there should be anyone out there? This bug prevents one from using two monitors, so its not minor in my opinion.

Why is the status of the bug still "UNCONFIRMED"? It should be changed at least now.

Same bug for me (the problem appears when i plug / unplug external monitor).

(In reply to comment #31)
> Same bug for me (the problem appears when i plug / unplug external monitor).

Can you provide your version number of KDE? I am still using KDE 4.5.5 but will switch to KDE 4.6 in the next few days. If the bug vanishes, I will let you know.

KDE 4.6.1 :(

I also still encounter that annoying bug in 4.6 (actually 4.6.0 as shipped with openSUSE 11.4). 

It actually feels worse, since the panel on the secondary screen is always mangled when the bug had shown in the previous boot (mangled = position is "up" instead of "center"; and "always shown" instead of "autohide"). Might be related, or might be unrelated though.

Same problem.

opesnSuSE 11.4
KDE 4.6.1 "release 390"
1680 x 1050 LVDS
1920 x 1200 DVI-0
ATI X1600 (radeon driver)

Krandr used for enabling and disabling DVI-0.

When not docked (and using second monitor) all normal windows are hidden on login.
Alt-tab will display all open windows as expected.
All windows disappear again when Alt-Tab released.
Switching between active activities does not fix problem.
switching to an activity that is/was not active, and turning off active activities reveals a functional desktop.

KennV

*** This bug has been confirmed by popular vote. ***

Same problem here, except that I do not use external monitors or any other screens apart from the laptop's. Only one activity configured, and the problem appeared immediately after upgrading from openSUSE 11.3 to 11.4 (previous KDE was 4.3-ish IIRC, whichever comes standard with 11.3).

I looked at ~/.kde4/share/config/plasma-desktop-appletsrc as suggested by #30 and found lots of stuff I didn't recognise (extra containments). I tried getting rid of those by eventually ran out of patience and deleted the file instead, which seems to have fixed it for now.

OS Info
OS:  Linux 2.6.37.1-1.2-desktop x86_64
System:  openSUSE 11.4 (x86_64)
KDE:  4.6.00 (4.6.0) "release 6"

Display Info
Vendor:  ATI Technologies Inc
Model:  Radeon Xpress 1200 (M)
2D driver:  radeon
3D driver:  R300 Gallium (7.10)

Hello, all,

I recently installed Kubuntu 11.04 (which comes pre-installed with KDE 4.6.2) and immediately started seeing this issue, and I tried the various solutions proposed in this bugtracker, to no avail. However, the thing that DID finally work for me was the following:

The hardware that I'm using is an ATI Radeon FirePro V4800, which has a DisplayPort and a DVI out: I have one monitor plugged into each output for a dual-head display. Since this is a desktop machine, every time I booted I saw this issue rear its ugly head. To work around it, I would have to:
    1. Open the activities pane
    2. Create a new activity
    3. Open that new activity
    4. Stop the old activity

Once I did that, my windows returned without trouble. However, when I restarted, I would have this issue, plus an issue where my dual-headed desktop configurations were replaced with a single, cloned configuration. 

What finally fixed it for me was to install the ATI proprietary driver. Once I did that, I had to configure the Catalyist control center to be in "Multi-display desktop with displays(s) 1", which solved both issues for me.

Hope this helps, and please let me know if there's any information I can provide to help with the tracking down of this issue.

Scott Fines

Observed with KDE 4.6.2 on Gentoo

I am currently seeing this issue whenever I log in on master. Next time it happens I will investigate.

I also ran into this bug With KDE 4.6.2 on Gentoo.

I tried to disable the recovering og the session, so no windows are started at login, and this made the problem go away, at least undtil now.

(In reply to comment #41)
> I also ran into this bug With KDE 4.6.2 on Gentoo.
> 
> I tried to disable the recovering og the session, so no windows are started at
> login, and this made the problem go away, at least undtil now.

But then today I ran into the bug again, so I had apparently just ben lukcy for a while.

(In reply to comment #41 and #42)
> I tried to disable the recovering og the session, so no windows are started at
> login, and this made the problem go away, at least until now.

I also tried this and it had no effect for me.

Within the last several weeks, the bug showed _every_ time I booted with a single screen, and _never_ when a second screen (via nVidia TwinView) was active.

The bug somehow suddenly disappeared for me.

I am not aware of any updates or changes, except that I moved my two additional auto-hide panels from the left screen edge (screen 1) and from the right screen edge (screen 2) to the top edge of their respective screen. My primary panel is on the lower edges of screen 1, with a windows-go-below setting.

Does this behaviour give any kind of clue to anyone, or is it coincidental?

(BTW, this my preferred panel setting anyway, but with previous KDE SC v4.x, both panels were displayed on top of each other if the second screen was unavailable. This other bug apparently no longer happens.)

Here is another wild observation of mine: 
The bug does not show for me if the panel's min/max width sliders are in the same position, but the bug shows pretty much always if the min/max size sliders of a panel on a screen that is currently not shown are in different position.

Maybe calculating the proper size for a panel that belongs to an inaccessible screen goes awry here?

This bug has been bothering me for a few weeks too.  On my system, I always boot up with on screen on, and then enable the other screen with nvidia-settings.  Thus, I see this problem 100% of the times I log into my system.  After reading this comments, it sounds like if I find a way to boot my system with dual-monitors already enabled, it should work for me?  I'm going to try to find a way to do that with my config....

Hope this bug gets fixed soon.  It's almost as bad as the "resize konsole window and now your computer locked up" bug that I'm also having.  :-(

Same here: I just updated to KDE 4.6.2-r3 (from 4.4) on Gentoo. I am really disappointed from my first impression of KDE 4.6. It _always_ happens to me, i.e. I just lost half a day to find this bug report and I did not yet see anything of KDE 4.6 (besides the login screen and my desktop picture). Also, I dont know what a KDE "activity" is, and I dont care.

Like some guys above, I also have two screens configured in my xorg.conf notebook internal + external. (The xserver leaves out the 2nd one, if no screen is connected.) Currently I just use the internal screen, but the bug still occurs.

Can someone post an easy-to-follow step-by-step guide on how to fix this? Or even fix this upstream?

(In reply to comment #47)
> Same here: I just updated to KDE 4.6.2-r3 (from 4.4) on Gentoo. I am really
> disappointed from my first impression of KDE 4.6. It _always_ happens to me,
> i.e. I just lost half a day to find this bug report and I did not yet see
> anything of KDE 4.6 (besides the login screen and my desktop picture).

The problem indeed turns up rather frequently, and is therefore also explicitly mentioned in the Gentoo KDE 4.6 upgrade guide (including bug number). :o)

Did anyone try the workaround I suggested above (i.e. removing panels from the second screen or setting them to a fixed size)? For me, setting the panel to a variable size produces the bug, while setting it to a fixed width/height eliminated it now.

@ Steffen #49
I would really like to try, but I only have one screen and there is absolutly nothing I can do on it, besides opening the right-click menu. No panel, no K-Menu, no settings, nothing.

@ Andreas #48
btw... if it does appear so frequently... makes me wonder if there is anyone testing the code before it is released? ^^ (probably a little out of fashion here, but that's what I would do after I made it compile... :-P )
</troll mode>

are there any log files I can provide or try something?

I also just updated to 4.6.3 (Debian Testing) from 4.4.x and I have the window hiding problem on a 2 monitor desktop system.  On the task bar I right click an icon of a running invisible window and select "Advanced" then "Keep Above Others" I see the window normally.  This is pretty annoying especially with dialog boxes I might not even know are there to set the "Keep Above Others" property.  Apparently this isn't remembered so each time I start an application I have to do this.

I am running KDE 4.6.4 on openSUSE 11.4 64 bit. I can confirm the symptoms as reported by Bob Weber. In my case it does not happen when I log in locally. But it does happen when I login remotely through VNC or NX. It is reproducable in my case.

1. Connect through NX to a KDE Desktop
2. Upon login only the plasma-desktop with wallpaper and widgets is vissible
3. Add "Taskbar" widget to desktop to access launched applications and right click -> Advanced -> Show above others to make visible.
4. When the netbook plasma desktop is selected windows *are* shown upon login, but ofc in this mode only 1 windows is shown at any given time - unpracticaly for a desktop environment.

The Desktop is running with the propreitary NVidia drivers and is locally configured to use TwinView (2 physical screens). Of course when connected through NX from a laptop using the official NoMachine client only 1 screen is configured to be used.

Should I create an xprop attachment?

Very similar situation except I'm running kubuntu 11.04 with KDE 4.6.5
Was using nvidia driver with Xinerama over two monitors, but had to revert to
nouveau which only shows the first screen on both monitors.

I'm also using the "Taskbar" to change the properties of application windows
to "show above others" and make them visible.

Everyone new to bug reporting: Don't forget to vote, so that some developer pays his attention to this bug.
For everyone who has switched to one monitor: See comment #30 on how to get rid of this bug forever (or at least till you decided to use two monitors again).
Like often with KDE: It's not a feature, it's a bug!

> Everyone new to bug reporting: Don't forget to vote, so that some 
> developer
> pays his attention to this bug.
 For everyone long time in bug reporting: forget about voting. It's the 
 best way to get developers not care about the bug, *especially* if 
 someone is asking others to vote. This feature has to be removed from 
 our bugzilla installation

@ #55 : sarcasm or tired of democracy?

btw, here is my workaround to get your computer working again: install Xfce :-P and use its window manager. you will still be able to use the kde programs.

> @ #55 : sarcasm
no, stating the reality
> or tired of democracy?
Huh? What has the bugtracker to do with democracy? If you refer to the voting feauture: that's the most undemocratic feauture I could imagine. It is not "voting", it's a "who yells loudest".
> 
> btw, here is my workaround to get your computer working again: install
> Xfce :-P and use its window manager. you will still be able to use the
> kde programs.
that's totally fine. Everybody should use the desktop which suits himself best.

> voting [...] is not "voting"
So I guess, "yelling" is not yelling either?

> voting: that's the most undemocratic feauture I could imagine
Now I clearly vote for sarcasm.

> Everybody should use the desktop which suits himself best.
Fine. I find the actual working one suiting best to me.

(Let us try if a flame war will drag some attention here. ^^)

Seriously, I consider this a critical bug - because it prevents working under KDE.

Has anyone from the KDE developers addressed this problem yet? Is anyone working on fixing it?  If not, would the KDE developers accept a patch to fix this bug from a third party developer?  This is a major bug since more and more people use multiple monitors, especially in work environments.  If KDE wants to be taken seriously in the industry, they need to fix critical bugs before they have been open for over a year.

> Has anyone from the KDE developers addressed this problem yet?
Personally I am no longer able to reproduce this issue with latest master.
> Is anyone working on fixing it? 
I don't know if anyone is currently working on it, but I tried to investigate it and did not find the 
cause for the bug. There have been fixes concerning the panel in multi screen setups which 
might have also fixed this one.
> If not, would the KDE developers accept a patch to fix
> this bug from a third party developer?
Of course, the KDE community is very open to external contribution and would very much 
appreciate help on such issues (assuming the bug is still valid).
> This is a major bug since more and more
> people use multiple monitors, especially in work environments.  If KDE wants to
> be taken seriously in the industry, they need to fix critical bugs before they
> have been open for over a year.
Please note that this is not a critical bug, as there is a simple workaround and the bug does not 
occur for all setups. Seriously also KDE developers are using multi screen setups.

If it's any help, here's the video for my case, which I made before knowing this issue is already reported:
ftp://ftp.cetaura.com/plasma-background.ogv

@ comment #61
Which KDE version did you make this video in? (Do you use an Nvidia card? Did you update from a previous KDE version? Does the bug _always_ happen to you?)

Hi, this is KDE 4.6.5. I think it started happening after the Debian upgrade from some 4.6.x to 4.6.5.

At first it happened every few times, but after I deleted ~/.kde to get a fresh config, it happens every time.

The card is Radeon HD 34x0 (RV620) with Mesa 7.11 and Gallium enabled.

I do experience this bug on KDE 4.7, Gentoo.

(In reply to comment #64)
> I do experience this bug on KDE 4.7, Gentoo.

I also still experience this bug on kde 4.7 on Gentoo.

Are there anyone for who this bugs disappered after upgrading to 4.7? 
Are there anyone none Gentoo users who still have this bug in 4.7?

Panels and windows hidden behind desktop background at start - is anyone still seeing this with KDE 4.7.3?

(In reply to comment #66)
> Panels and windows hidden behind desktop background at start - is anyone still
> seeing this with KDE 4.7.3?

Yes, this bug was not addressed as it seems from the changelog/buglist.

Git commit 5aad39dbb324aad4cac3f44967ee1fc1b3d2a168 by Aaron Seigo.
Committed on 20/11/2011 at 18:50.
Pushed by aseigo into branch 'KDE/4.7'.

don't count custom panel contaiments (e.g. the grouping desktop) the same as a desktop containment

from the "useful things missing from bug reports" and "wondering wtf is wrong with people
while trying to get the useful bits out of a bug report" files ...

BUG:260360

M  +4    -3    plasma/containment.cpp

http://commits.kde.org/kdelibs/5aad39dbb324aad4cac3f44967ee1fc1b3d2a168

this seems to have been a couple of different bugs, one of which was fixed prior to 4.7. the other, which kept the report persisting for some, came as a result of using custom panel plugins (e.g. the grouping panel, amongst others that are out there). that kind of information is, probably not suprisingly, useful to know.

only one person posted their plasma-desktop-appletsrc, and that was before the first set of fixes. more of that would have been great as the problem persisted for some. thanks to those who did post xprop attachments and/or their config files. that's truly useful and i respect that it requires effort and time.

====

3rd party patches: this is an open source project that is developed truly in the open. third party patches are submitted and accepted pretty much daily. we welcome, strongly, all participation that makes the products better.

===

reading through the other comments, i'm very, very disappointed in the tone some people chose to take. some of the things said were not said in a way that could be mistaken for a spirit of constructive participation. those individuals need to step back for a moment, perhaps read the KDE Code of Conduct and consider that we're all trying to work together here towards common aims. 

if that is not how you wish to engage, then please do everyone (including other users)l a favour and don't participate on bugs.kdeorg.

thank you.

In responds to #69 from Aaron J. Seigo

I'm glad this bug is fixed finally.

>only one person posted their plasma-desktop-appletsrc, and that was before the
>first set of fixes. more of that would have been great as the problem persisted
>for some.
When there is no dev here to read a bug report and tells us what information he needs to fix the bug, how shoul a normal user know this? I only posted the plasma-desktop-appletsrc after a long search for the reason of the bug. It was simply just luck.

>came as a
>result of using custom panel plugins (e.g. the grouping panel, amongst others
>that are out there). that kind of information is, probably not suprisingly,
>useful to know.
I actually just use the kde version shipped with my distro (back then openSUSE 11.4) and never installed any "custom panel plugins" (just widgets), so I (and I guess everyone else here) wasn't aware of that. As before: If a dev would have pointed out that this would make a difference, he would have gotten this information, too.

>reading through the other comments, i'm very, very disappointed in the tone
>some people chose to take.
I guess I'm a bit guilty for this, too (#54). But I've read again all the comments and the most offensive comment is #68 from an arrogant developer:
>from the "useful things missing from bug reports" and "wondering wtf is wrong
>with people
>while trying to get the useful bits out of a bug report" files ...
Do you know him?

Many people tried to help to solve this bug, but till now (after almost a year) no developer ever responded. Don't get me wrong, I'm happy you fixed the bug (in your free time for no payment), but all other users spent their free time, too - for waiting 11 months to see 4 lines changed? Seriously, if KDE devs cannot fix their bugs (and this was an easy one) in a reasonable amount of time, they should stop developing new fancy features and concentrate on bug fixing. This has nothing to do whether the devs are getting paid or not but is developing 101. I only can quote #59:

>If KDE wants to
>be taken seriously in the industry, they need to fix critical bugs before they
>have been open for over a year.

And to answers your rhetorical question "useful things missing from bug reports":
It's developers! Bug reports are missing developers who read and care about them.
But luckily you seem to be the exception.

Thanks again for fixing this annoying and critical bug.

(In reply to comment #70)
> When there is no dev here to read a bug report and tells us what information he
> needs to fix the bug, how shoul a normal user know this? I only posted the
> plasma-desktop-appletsrc after a long search for the reason of the bug. It was
> simply just luck.

> Many people tried to help to solve this bug, but till now (after almost a year)
> no developer ever responded.

> Thanks again for fixing this annoying and critical bug.

I'm glad the bug is fixed, too... but just to set the record straight, a number of devs posted here.

If you check the emails, Martin G has a kde email address, which should be checkable by anyone who can comment. (Simply hovering over the name in the comment header provides an email address in the status line, here, that anyone logged in should be able to check.)  Channi is also a kde dev, as I've seen that name in various kde blogs, etc.  I believe Thomas L is as well, tho I'm not as sure on that.  Andreas KH is a gentoo/kde project dev/maintainer, not kde but a distro dev, with gentoo obvious in his email, and of course Aaron JS is the kde/plasma project lead dev and a highly visible kde spokeperson.

The problem was, this was a very tough bug.  Nobody (including the devs) had a clue what was causing it, it appeared at the intersection between two kde projects (kwin, the window manager, and plasma, the desktop) and it wasn't obvious which was at fault, the devs weren't initially seeing it (thus explaining how it got in a release in the first place), and because it started before kde's switchover to git, bisecting the problem wouldn't have been particularly easy for the power user types either.  (Git makes that sort of thing MUCH easier, and while I'm no coder, I've been filing and bisecting kernel bugs for quite awhile now, and even one kde bug already, now that it's on git.)

I didn't have this bug, only coming across it after seeing a gentoo backporting patch mention it, but reading it was like reading a mystery novel, seeing the cluses appear one by one and trying to guess at the bug, myself.  Sometimes bugs, even critical bugs, *ARE* tough, taking some time to track down and kill, and this was simply one of them!

Meanwhile, while there were definitely devs working on trying to fix this, unfortunately, developer comments also helped make the situation worse.  Yes, I understand that not all devs like the voting system (there was quite a discussion about it on the gentoo-dev list that I followed.. as a user), because they try to fix all bugs regardless, and some are just tougher to fix than others, but disparaging bug voting without some sort of an explanation or (as said explanation has likely been repeated many times) some LINK to a reasonable explanation only confuses users who are in good faith trying to report bugs and play by the rules using the tools, including bug voting, available to them.

Similarly, nobody, dev or user, /requested/ that people post plasma-desktop-appletsrc, and the posting by one user was simply chance.  Back at that point, there wasn't much clue that posting it would have been helpful, so I can see why the devs hadn't requested it then.  But by the time 4.7 came out, fixing it for some but not for others, if it was so obvious that Aaron could comment WTF about users not posting it, why wasn't it obvious enough for a dev to actually request?  

And if it wasn't obvious enough to request, or even if it was, since nobody did so, the noise about users being too dumb to somehow read a devs mind and figure it out was... shall we say, more heat than light?

And with both triggers for the problem existing until 4.7, it had barely been established and confirmed that the problem continued to exist on 4.7, when it's fixed, but the dev fixing it complains about lack of information that probably didn't apply to most since they would have had the earlier fixed problem, and that the folks still with the problem had no clue they needed to provide, since they still thought it was the same problem as before.

So yeah, I'm glad it's fixed, but devs complaining about missing information, when it wasn't clear even to devs at first even where the problem was, and all requested information was provided several times over... then that same dev complaining about the tone on the bug...

What are the users /supposed/ to do, read minds, to know what information might be useful?  Unfortunately, it seems even the devs didn't know what files or additional information would have been helpful in tracking this down, until after the fact, so users would have to be psychic in TWO ways, reading the devs mind before the devs even thought the thoughts themselves!

IMO, said dev needs to examine his own comments for more heat than light.

(This said as a regular on a couple kde lists, who recently found myself apologized for a post I made in a similarly inappropriate tone, because I found myself tired of asking for missing information... that the rather ordinary user really couldn't have known they needed to provide in the first place.  So yes, unfortunately it happens, and I'm no saint myself in that regard.  We can all do with a bit of "introspection" in that regard from time to time.)

It helps to remember that fixing the bug is the goal of both the user and the dev -- we're all on the same side against the bugs, and killing (as in, driving away) someone fighting on our side, particularly when they've taken time out of their own schedule to report the bug and/or find it and add their own info as they can, doesn't tend to help! =;^)

I am also thankful that his bug is now hopefully fixed, even though I had found a workaround for myself as posted earlier. 

I really tried to help as much as I could to fix this bug, providing all requested information. Apparently this was not enough, which is sad, but I have no idea about the inner workings of KDE nor C and I am quite confused which config file is which. If I search through all the changes in ~/.kde4 within the last hour when a bug shows up, it is hard to identify the relevant files, because a lot of KDE config files change without any good reason (e.g. just reordering their content).

Is this bug supposed to be closed in KDE 4.7.4? Unfortunately it just happened to me with this newest KDE version.

I am affected by this bug in Kubuntu 11.10. How do I fix it?

(In reply to comment #74)
> I am affected by this bug in Kubuntu 11.10. How do I fix it?

Workarounds include (not all will work for everyone):

* Stick with two monitors, don't run with only one.  Or once you get one working, never plugin a second and run with two.  It's the switching from two to one that seems to trigger the bug, so if you don't do that, you shouldn't trigger it.  (This workaround would mean desktop users with multiple more or less permanent monitors setup, never switch to only one, and laptop users only use their builtin laptop monitor, never plugging in another.  Obviously this isn't going to work well for especially some laptop users, which will have to use other workarounds, but this could be the best choice for those who almost always use the same setup, they'll just have to be a bit more rigid in keeping it that way.)

* As described in the original report, setup a second activity (you'll need to do this when it's working, perhaps with a second monitor plugged in) identical to the first.  Then when the bug occurs, switch activities and stop the bad one, using the WORKAROUND procedure described in the original report.

* If you do run two monitors, don't put panels on the second one, only the primary.  It seems to be these panels that misbehave when switched back to only the primary, and if there aren't any, there aren't any to misbehave.  (This should be reasonably easy for many.  Just don't put panels on anything but the primary monitor, even when two or more are in use, but this might not cure it for everyone.)

* The original reporter reported that the problem went away for him when he had only horizontal panels, top and bottom, no side panels.  Thus, that might work for some.  (Additionally, I've noted other bugs, apparently unrelated, see bug #272663 for an example, with top panels.  It seems bottom panels are the most tested and least likely to cause other issues.  Thus, if you're having issues and can possibly work with only bottom panels, try that.)

* The problem appears to be related to configuration details stored in plasma-desktop-appletsrc (see comment #30, and note that kde ships with its config dur as ~/.kde but some distros change that to ~/.kde4, so whichever path you have).  Deleting it from a text login, or deleting the problem second monitor bits from within it, will probably help many people.  However, note that if you delete the file entirely, you'll return to a default desktop arrangement.  If you've done a lot of customizing, you'll need to redo it.  (Based on my experience with other bugs, that file's a magnet for them.  If you customize, get the setup the way you want and backup the file, so you can restore it and get your old settings back if it gets screwed up.  Also, once you're setup how you want, try not to screw with things, as unfortunately, it seems that every change is rolling the dice on getting a new bug as a result.  In my experience, just adding or moving around a plasmoid/widget isn't too risky, but adding panels or activities is rather more so.)  **This solution should work if you can't get a working desktop to try any of the others, assuming of course that you are comfortable logging in at the text console or in another desktop environment (gnome or whatever) to be able to edit or remove plasma-desktop-appletsrc.

* Someone mentioned that switching (one or more activities, he had to switch the one he'd created while running a second monitor) from desktop layout to folderview layout fixed the problem for him.  So switching layouts may work, at least for some people.

* There's always the backup your home dir (or less drastic, just the ~/.kde or .kde4 dir) and start from a clean config method.  Or create a new user with a clean config and see if the problem exists there.  Either way is an excellent troubleshooting method, to check if it's something in the user config or a general bug even with a clean config.  If it ends up being a user config issue, as it often does, you can use the bisect method to narrow it down from there.  The .kde (or .kde4 on some distros) dir has two primary subdirs, share/config, and share/apps.  Try with one but not the other.  Once you figure out which one it's in, try with half the content there and half missing.  Then on the bad half, try with half (so now a quarter of the total) there and half missing.  Continue narrowing down until you narrow it down to a single dir and then a single file, or until the pain of reconfiguring everything that's left is less than the pain of continuing to test.  Once you've reached an individual file, if desired, switch to a text editor and continue to narrow down to the individual [section] and then the individual line.

The bisect technique (last one, above) requires a bit of patience, but is an incredibly useful problem isolation technique that you can use on nearly every kde config-related problem, as well as on other problems in life in general.  The first time you use it (for a kde problem) is the worst.

(I've been using the bisect method for years, here, since early kde3 at least, and back in kde2 and before that in MS land, in some form.  It really does get easier at about the 3rd or 4th time, as you really do have a better understanding of how kde works and can shortcut the process accordingly.  And understanding kde better as a result isn't a trivial benefit, either, as it can help avoid many problems in the first place.)

The workarounds are all there (or in the case of the last one, bisect, are common sense if you think about it), but this brings them all together in a single list.  Hopefully it's helpful to those still dealing with the issue.

Duncan

another way is "kcmshell4 kwinrules"

if you can identify the overlaying window, you can ask kwin to do all kinds of "fixing" with it (position, size, window type - what impacts the layer).

Challenge 1: get the kcm up ;-)
Challenge 2: identify the window (eg. the attached xprop has a "panel_0" role, what sounds promising for identification

For those still affected by this on various 4.7.x...

I just came across yet /another/ commit (the third, now), from December 2, in the KDE commit digest for the week of December 4, that I think finally finds and addresses the root of the problem, so hopefully it'll be gone for good, now.  The problem was a mis-reference (well, same mis-reference on two sequential lines) to "type()" that should have been a reference to "containmentType()".  There's a number of similar bug reports and this got filed as a fix for a different one, since this one was already marked as fixed.

The git commit # and comment:

>>>>>

commit: e2108ede

containmentType() .. NOT type()!

and now we know the source of the "panel covers the entire screen" bug

BUG:259704

<<<<<

Also see commit 20037a9b , same fix, different branch.

Has that commit gone into 4.7.4? I currently have the problem again running that KDE version.

I confirm that this problem still exists for KDE 4.7.4.

I am running 4.8 and its fixed.

Had the problem when I was running KDE 4.7.4. (had to deactivate and reactivate my normal activity after each login)
Now upgraded to KDE 4.8 -> problem is gone.