Version: (using Devel)
Installed from: Compiled sources
KDE 4.2 beta 1 installed from OpenSUSE factory. Version 4.1.80 (KDE 4.1.80 (KDE 4.2 Beta1)) "release 7.3", on OpenSUSE 11, x64.
When resizing panel, the default containment looses its background, it turns black, the cashew is lost, the plasmoids cannot be seen. Only plasma restart helps.
You can see the effect in this picture: http://dot.kde.org/1227714704/1227775830/kde42b1.jpeg
To reproduce: simply resize the panel.
uhm. Guess it will be hard to address that since I am not aware of anyone who had such an issue before (what doesn't mean, that it doesn't exist but only that it's hard to find the reason for it).
The screenshot itself does more indicate that the setup of the user is complete broken somehow. E.g. that the "systemsett" does not expand to any single item may very likely means, that the runner-plugins are not found.
Anyway, the step to reproduce is invalid cause it doesn't work here or on any other system I did test. So, guess some more input (like what local changes to a default opensuse 11 was done? is that a mixed setup of KDE 3.5, 4.0, 4.1 and 4.2? Does that also happen with a new added user? etc.) would be needed.
Hello, I reused the screenshot from a dot comment, but only after I reproduced the mentioned problem. I didn't suppose there would be a problem in reproducing, since the commenter complained and I had exactly the same problem.
I will try to reproduce the problem this evening on a fresh empty user setup (delete all .kde dirs) and will send a follow up. Also I will attach more info about my setup (hw and X setup).
I am able to reproduce both the bugs, the krunner one with systemsettings not being autocompleted and the plasma one. See the attached screenshots. The panel resizing was doen using the "Height" button on the settings bar.
The behaviour is seen on OpenSUSE factory KDE4.2b1 packages: KDE 4.1.80 (KDE 4.1.80 (KDE 4.2 Beta1)) "release 7.3". I use the binary NVidia drivers
test@linux-65k6:~> rpm -qa | grep nvidia
test@linux-65k6:~> uname -a
Linux linux-65k6 126.96.36.199-0.2-default #1 SMP 2008-10-21 16:30:26 +0200 x86_64 x86_64 x86_64 GNU/Linux
with disabled desktop effects. xorg.conf is attached.
Please let me know if you need any additional information.
Created attachment 29217 [details]
screenshot of the workspace after resizing the panel. See the gray area over the folderview.
Created attachment 29218 [details]
screenshot of the krunner not autocompleting systemsettings
Created attachment 29219 [details]
xorg.conf of the test system
One more thing: krunner does autocomplete on almost anything, only not on the systemsettings. The test was performed on a fresh new user with no previous KDE configuration.
this is panel bug. read the name.
to reproduse simply resize panel to make it bigger
this is the same bug : https://bugs.kde.org/show_bug.cgi?id=176155
I can confirm this bug since KDE 4.2 Beta 1 (4.1.80) and now with KDE Beta 2 (4.1.85) on Kubuntu Intrepid 8.10
Linux winry 2.6.27-9-generic #1 SMP Thu Nov 20 22:15:32 UTC 2008 x86_64 GNU/Linux
I use the proprietary NVIDIA Linux drivers 177.80-0ubuntu2
*** Bug 176155 has been marked as a duplicate of this bug. ***
Can reproduce this. If you resize the panel even larger (1/2 screen and more), then stripes of the blank area near the top turn white for a second, then disappear. I can get the blank area down to ~1/5 the screen size from when it first appears.
When the blank area first appears, it never covers the cashew, always stops right at the lower edge of it.
The blank area in mine is black, as follows with my theme.
Also using nvidia drivers 177.80.
Created attachment 29581 [details]
Here reproducing the bug
KDE: 4.1.86 (KDE 4.1.86 (KDE 4.2 >= 20081221))
kdelibs svn rev. 900491 / kdebase svn rev. 900491
xf86-video-intel 2.4.3 (not the last version 2.5.0)
with an Intel GMA x3100 (965) integrated graphics.
on ArchLinux x86_64 - Kernel 188.8.131.52
I can reproduce this bug.
(This intel drivers seems to be faulty after the upgrade to Xorg-server1.5.3 + xf86-video-intel 2.4.3 (there were some problems for my distro to build the 2.5.0 intel driver.)
If compositing (OpenGL) is ON I see the black rectangle. If compositing is OFF for some seconds I see some another windows (the rect of the window that plasma shows as black when using compositing), and then I see a grey rectangle. (may be a random behaviour)
Also I see part of the KDM background ("Black Curl") (?)
*** Bug 179243 has been marked as a duplicate of this bug. ***
*** Bug 177707 has been marked as a duplicate of this bug. ***
Bug 176280 comment 2 and bug 176280 comment 3 have some additional information about the bug.
Here I can reproduce it even when using the VESA driver with a default Xorg config.
Qt: 4.4.3 + qt-copy-patches-889120
KDE: 4.1.86 (KDE 4.1.86 (KDE 4.2 >= 20081221))
kdelibs svn rev. 904138 / kdebase svn rev. 904138
on ArchLinux x86_64 - Kernel 184.108.40.206
And as stated in bug 176280 comment 3, this only happens if you have one panel (may be the bottom default). If you have another panel on top, this doesn't happen.
Created attachment 29800 [details]
Basic VESA Xorg.conf file
this is still an issue with latest trunk about 7hrs ago compiled (Xorg 1.3.0, nvidia 180.16, qt-copy: 904364, kdelibs:904337, kdebase:904348)
I also do get intermittent 'plasma unable to connect to dbus messages' when trying to reload plasma with kquitapp plasma & plasma &
after getting the blackscreen when making the panel size big.
<unknown program name>(32114)/ checkComposite: Plasma can use COMPOSITE for effects on 0x8064d70
plasma(32114): KUniqueApplication: Registering failed!
plasma(32114): Communication problem with "plasma" , it probably crashed.
Error message was: "org.freedesktop.DBus.Error.ServiceUnknown" : " "The name org.kde.plasma was not provided by any .service files
full log here: http://pastey.net/105421
i dont know if this of any help
@Sebastian Sauer: "The screenshot itself does more indicate that the setup of the user is complete broken somehow."
Original screenshot is mine and my setup is: $ rm -rf ~/.kde4; startkde
confirmed present as of svn rev 906310. intel drivers. clean, default ~/.kde.
I can confirm this bug.
As I tried to make a screencast of the panel, I have also a video where this bug appears.
If you think it could be useful, I will upload it.
I think it only occur when you resize it "too" much.
My system is:
Mandriva Cooker (2009.1 Alpha)
ATI x600 / free 'ati' driver (also appears with fglrx)
X.org Server 1.5.99
Used a new added user
I've restarted plasma with the --no-fork option but no messages appears, when the desktop got broken.
I just run into exactly this bug using KDE-4.2rc1 on Kubuntu-8.10.
Distro: openSUSE 11.1 (x86_64)
Kernel: 220.127.116.11-9-default x86_64
KDE: 4.1.96 (KDE 4.2 RC1)
Card: NVIDIA GeForce 8600M GS/PCI/SSE2
Driver: 2.1.2 NVIDIA 180.22
note this isn't just a graphical bug, ie it is not possible to "click though" the blackness to the desktop below
I also have this bug. I resized the panel to a smaller size than default and got 3/4 a black screen.
All background was gone and i could not click through. I removed the whole .kde config dir and restarted making a config from new but it did not help.
Created attachment 30302 [details]
3/4 Black screen - Result from resizing panel
I also have the same bug on Kubuntu nightly (neon) builds.
this is still an issue with trunk compiled about 1hr ago with:
*** Bug 181628 has been marked as a duplicate of this bug. ***
This is still broken in KDE-4.2 final. While I, personally, could live with this bug, this (and a number of other showstoppers) makes it impossible to hand out KDE 4 to our customers. Sorry guys, but this is still not "The Answer"...
Same here, but without crashing. The bit of the desktop I can see (about an inch at the top) shows that it is still working, but it is like the rest of it is under a black window which covers most of the desktop. killall plasma followed by running plasma fixes it.
Kubuntu 8.10, KDE 4.2 Final
ATI Technologies Inc Mobility Radeon HD 3650, fglrx driver.
I checked this out on svn. If I slowly resize the panel to be larger, there are no problems. Doing the resize at any >= normal speeds seems induce the problem. Also, this only occurs when resizing the panel to be larger.
Tested on KDE: 4.2.61 (KDE 4.2.61 (KDE 4.3 >= 20090127))
Well I played around with this for a bit. I noticed the start of the problem is at void Panel::constraintsEvent(Plasma::Constraints constraints) in the true portion of the if statement on 447.
Here, m_background->setElementPrefix(location()) is called. I haven't had a chance to actually read over the source and understand whats going on... but doing some random checks, I noticed taking out this statement makes the panel not paint, but the panel toolbox is still there. Resizing, at this point, doesn't cause problems. So I'm assuming some call from within or resulting from setElementPrefix of FrameSvg when resizing the panel is the culprit. Or maybe its something after that in the constraintsEvent function. Hopefully this gives a decent lead for further debugging. Well its late, I don't think I can think too clearly anymore.
I hope this helps. Not exactly pinpointed but maybe its something in the right direction.
SVN commit 927141 by mart:
theory: the desktop breakage could happen because the panel overlaps the
desktop for a while, making containment()->view() or
corona::containmentfordesktop() fails, leaving the desktop view without
try to reposition the panel before a vertical movement, it should
prevent the panel to go into the desktop for an instant
M +16 -10 containment.cpp
WebSVN link: http://websvn.kde.org/?view=rev&revision=927141
SVN commit 927158 by mart:
reverting the last change, the panel height is still the old one at that
M +10 -16 containment.cpp
WebSVN link: http://websvn.kde.org/?view=rev&revision=927158
A proposed patch was posted by Josh on review board this morning:
SVN commit 927169 by jleves:
Prevent horizontal panels from bleeding over into positive coordinates by creating a positioning offset, much like that given to vertical panels.
M +2 -2 containment.cpp
M +1 -0 private/containment_p.h
WebSVN link: http://websvn.kde.org/?view=rev&revision=927169
SVN commit 928671 by aseigo:
prevent panels from encroaching into positive space and screwing things up: constraintsEvent is delayed, and that event loop is entered between. this is something that needs to be done synchronously, however. SizeConstraint is triggered by Applet::resizeEvent, so putting this code in resizeEvent is no more or less immune to applets/containments reimplementing resizeEvent and not calling the base implementation.
M +14 -12 containment.cpp
WebSVN link: http://websvn.kde.org/?view=rev&revision=928671
SVN commit 928672 by aseigo:
backport fix for br#176280
M +14 -12 containment.cpp
WebSVN link: http://websvn.kde.org/?view=rev&revision=928672
*** Bug 183973 has been marked as a duplicate of this bug. ***