Version: (using KDE Devel) Installed from: Compiled sources Compiler: gcc version 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8) OS: Linux When I switch the desktops, the transperency in the window list, the system tray and the clock turns off to grey. When I switch back, sometimes it changes to transperency again, sometimes it doesn't. But at least after a couple of switches, I have transperency again. Sometimes I even can switch without problems. It seems to be very random.
Created attachment 12689 [details] Screenshot of the bug
*** Bug 113093 has been marked as a duplicate of this bug. ***
*** Bug 114702 has been marked as a duplicate of this bug. ***
Created attachment 13103 [details] Black buttons background on mouse-over. Looks like it happens when the panel is redrawn. My way out of it is to move it to a different orientation, then back. Also (might be related): noving the mouse over the buttons (K menu for instance) makes part of their background black, sometimes (this looks really random).
Hello people, this bug happens to me as well. But so far most people seemed to be unable to reproduce it. Now i know how to reproduce it: For me the bug is only triggered when the option "icon mouseover effects" is enabled. I just disabled this option and now there are no more grey/black backgrounds in conjunction with transparent kicker. In addition a bug with the k-menu's sidebar pictures is solved by disabling this option as well. For me, the sidebar looked very strange, like an uninitialized picture. But now it looks completely normal as it should. I hope this hint will help somebody to solve the problem :) Bye, Thomas
*** Bug 114891 has been marked as a duplicate of this bug. ***
> For me the bug is only triggered when the option "icon mouseover effects" is > enabled that's interesting, but not the cause since i have that feature turned on and there's no affect. might be a clue for later on though.
SVN commit 473880 by aseigo: fix a number of transparency regressions. also attempt to limit the number of times the background setting is done by limiting the number of times QTimer::singleShot() gets called. i can NOT wait until kde3 is a distant memory i can just use qt4's argb visuals. ffs. can someone who reported bug #113235 or one of the duplicates please check out these changes and let me know if these changes fix anything for them? thanks. CCBUG:113235 M +18 -7 containerarea.cpp M +1 -0 containerarea.h --- branches/KDE/3.5/kdebase/kicker/kicker/core/containerarea.cpp #473879:473880 @@ -85,6 +85,7 @@ _bgSet(false), m_canAddContainers(true), m_immutable(_c->isImmutable()), + m_updateBackgroundsCalled(false), m_layout(0), m_addAppletDialog(0) { @@ -341,7 +342,11 @@ saveContainerConfig(); } - updateContainersBackground(); + // while this is also called in addContainer (well, resizeContents()), + // it gets executed too soon. we need to wait until the containers are + // actually resized, but we enter the event loop prior to that happening + // above. + QTimer::singleShot(0, this, SLOT(updateContainersBackground())); } void ContainerArea::saveContainerConfig(bool layoutOnly) @@ -639,11 +644,7 @@ return 0; } - a->setFreeSpace(1); - addContainer(a, true); - scrollTo(a); - saveContainerConfig(); - + completeContainerAddition(a); return a; } @@ -890,7 +891,7 @@ if (ev->state() == LeftButton && !rect().contains(ev->pos())) { - // leaveEvent() don't work, while grabbing the mouse + // leaveEvent() doesn't work, while grabbing the mouse _autoScrollTimer.stop(); releaseMouse(); setCursor(arrowCursor); @@ -1621,7 +1622,15 @@ void ContainerArea::resizeContents(int w, int h) { + // this looks silly but is required otherwise (some?) c++ compilers can't see + // Panner::resizeContents(int, int) due to the overloaded ContainerArea::resizeContents() Panner::resizeContents(w, h); + + if (!m_updateBackgroundsCalled) + { + m_updateBackgroundsCalled = true; + QTimer::singleShot(0, this, SLOT(updateContainersBackground())); + } } void ContainerArea::slotSaveContainerConfig() @@ -1725,6 +1734,8 @@ void ContainerArea::updateContainersBackground() { + m_updateBackgroundsCalled = false; + if (!_bgSet) { return; --- branches/KDE/3.5/kdebase/kicker/kicker/core/containerarea.h #473879:473880 @@ -156,6 +156,7 @@ QTimer _autoScrollTimer; bool m_canAddContainers; bool m_immutable; + bool m_updateBackgroundsCalled; QWidget* m_contents; ContainerAreaLayout* m_layout;
*** Bug 114657 has been marked as a duplicate of this bug. ***
The last patch didn't completely solve the transparency issue I am seeing, although it did make it randomly intermittent, rather than consistently broken. So, on switching desktops, the panel on the new desktop sometimes loses transparency. If I keep switching desktops, the non-transparency on that desktop is persistent for a while, but may eventually become transparent again (but in the meantime, another desktop's panel may go non-transparent). Ah, some good news: on a hunch, I disabled transparency in the "Desktop Preview & Pager" applet, and now my problem seems to be completely gone: the rest of the panel is transparent, and remains so after many desktop changes. Maybe this will help track down the issue.
*** Bug 113977 has been marked as a duplicate of this bug. ***
*** Bug 96465 has been marked as a duplicate of this bug. ***
Hey, this bug doesn't seems to me too similar to bug 96465 (olded and with 61 Votes ;-) )! :-) The picture above (from Tilman Klaeger) you can repair (well, if original color of those kicker is blue and background is light gray) easy as in my case. Just set it back to default kicker color (K menu, aplication and desktop accessing could be enough). Then you will get bug 96465 relating IMO to applets handles (or drags?). Turn it off and background shift behind the applet will be gone. System tray will be broken after icon adding/removing to the next workspace change. (More pictures and more complex descriptions you can see by 96465 bug ;-) )
yes, you're right....
Aaron: Your Patch from comment #8 did not fix the bug (at least not for me).
well, i'm still unable to trigger this particular bug. the background is always painted on all buttons an applets i have. i've tried with different desktop wallpapers on different desktops, transparency turned on or off in the pager, etc... i really will need someone's config that triggers this problem. if someone could upload their kicker config file(s) that would be nice.
My kickerrc and minipager_panelapplet_*_rc are attached. This config causes the entire kicker panel to sometimes not get painted on switching desktops. If I remove the line "BackgroundType=BgTransparent" from minipager*rc, then the problem goes away. thanks, Jason On Friday 04 November 2005 01:37, Aaron J.Seigo wrote: [bugs.kde.org quoted mail] Created an attachment (id=13274) kickerrc Created an attachment (id=13275) minipager_panelapplet_rohtkrgrvhas7ofzeevz_rc
On Friday 04 November 2005 07:04, kstars@30doradus.org wrote: > My kickerrc and minipager_panelapplet_*_rc are attached. This > config causes the entire kicker panel to sometimes not get painted on > switching desktops. > Er, that should have read "...the entire kicker panel *background* to sometimes not get painted..." The widgets and icons get painted, of course. Sorry about that.
I have also seen the problem. I'm using KDE 3.5 beta as packaged in Mandrake cooker (3.4.92 (KDE 3.4.92 (beta2, >= 20051010), as reported by the bug tool). With X.org composite and kicker transparent (with a color tint), I can fully reproduce this problem - setting the pager applet's background to transparent disables kicker transparency completely on any desktop change and it will not enable again. Setting the background back to 'elegant' completely reverses the problem. Also, when the pager bg is set to 'transparent', when I switch desktops the background of the systray flashes purple (the tint color I set for kicker transparency).
Oded - if you stop the compmgr or simply not load the COMPOSITE extension, does the problem go away?
No, but it becomes less predictable - with composition disabled, when I go back to some desktop kicker becomes transparent again (for me its usually 3, but even that isn't predictable - sometimes it does, sometimes it doesn't). With composite its always 100% predictable.
As 3.5 RC has been released I think it is time to recheck this bug on a newely created account.
This bug seems to affect kmenu's logo-picture too. I get bits of the K-button repeated in the picture next to the menu-entries. This is using KDE 3.5 RC1.
*** Bug 116207 has been marked as a duplicate of this bug. ***
I agree with kstars@30doradus.org, if you disable the transperency in the pager you don't get the artefacts anymore. Supposingly the bug is somewhere in the pager applet.
Created attachment 13442 [details] Kicker bad transparancy upon login This is how my kicker looks like upon initial login
Created attachment 13443 [details] Kicker good transparancy This is how kicker looks like after I push kicker-hide button twice (to hide and to show).
Created attachment 13444 [details] Kicker bad transparancy after a new systray icon appeared When I connect to the Internet a new systray icon appeared (Knemo) and kicker transparancy broken
Created attachment 13445 [details] Miscellaneous kicker configuration files Miscellaneous kicker's configuration files
what version of Qt are people who are seeing this bug using? (if you are using binaries that came with your distro, please note the full package version)
*** Bug 116273 has been marked as a duplicate of this bug. ***
i have the same problem. when kde starts, kicker is wrapped, then i re-enter the desktop and it's good but when i add a new icon to systray, kicker's transparency is wrapped again... Qt: 3.3.4 KDE: 3.4.1 distro gentoo
SuSE 10.0 packages from ftp.kde.org Qt 3.3.5-15
I tried with various versions: 3.3.4 3.3.5 qt-copy (3.3.5) Always the same problem.
> what version of Qt are people who are seeing this bug using? (if you are > using binaries that came with your distro, please note the full package > version) % kde-config --version Qt: 3.3.5 KDE: 3.5 (RC1)
Hi, I´ve the same problem. Ubuntu QT 3:3.3.5-1ubuntu1
just to make it clear: this BR is *not* about the system tray. there is another BR about how sometimes when an icon is added to the system tray it messes up transparency. this is about grey (or just non-painted) areas appearing around and behind buttons and applets.
is there anyone on this bug report (not the systray issue) for whom changing the pager to "elegant" does *not* fix the problem?
$ kde-config --version Qt: 3.3.4 KDE: 3.4.2 kde-config: 1.0
>> just to make it clear: this BR is *not* about the system tray. there is another BR about how sometimes when an icon is added to the system tray it messes up transparency. this is about grey (or just non-painted) areas appearing around and behind buttons and applets. << Then is bug 116273 not the same as this bug. (Bug 116273 is marked as a duplicate of this bug) >>is there anyone on this bug report (not the systray issue) for whom changing the pager to "elegant" does *not* fix the problem? << Yes. (I´ve both this bug here and the systrea-Bug)
$ kde-config --version Qt: 3.3.4 KDE: 3.5 (RC1) Qt 3.3.4 vanilla + qt-3.3.4-visibility.patch: /usr/lib/qt-3.3.4/mkspecs/linux-g++/qmake.conf: QMAKE_CFLAGS_RELEASE = -O2 -march=pentium2 /usr/src/qt-3.3.4/configure -prefix /usr/lib/qt-3.3.4 -qt-gif -system-zlib -no-exceptions -thread -pch -no-cups -no-stl -no-nis -qt-imgfmt-png -qt-imgfmt-jpeg -qt-imgfmt-mng -system-libpng -system-libjpeg -system-libmng -dlopen-opengl GCC: 4.0.1 vanilla KDE 3.5 RC1 vanilla: CFLAGS && CXXFLAGS: -O2 -march=pentium2 KDELIBS: ./configure --prefix=/opt/kde3 --with-gnu-ld --enable-final --disable-debug --with-xinerama --enable-mitshm --enable-fast-malloc=yes --with-alsa --enable-sendfile KDEBASE: ./configure --prefix=/opt/kde3 --with-gnu-ld --enable-final --disable-debug --with-xinerama --without-shadow --disable-shadow
I always compile GCC/QT/KDE from vanilla sources with no patches applied (except Qt which requires a KDE visibility patch nowadays). My distro is FC4 partly upgraded to FC5/rawhide.
I also see this problem with the Debian Alioth packages for 3.5rc1, on QT 3.3.5. Xorg is 6.8.99.901 from Unstable, with no fancy xcompmgr stuff enabled. The problem occurs when switching desktops, or occasionally when mousing-over the panel icons. With the panel background set to transparent, the entire panel turns from transparent to grey. With a background image set for the panel, only the icon backgrounds turn grey. Also, I see bright purple artefact colours in the logo strip of the K-Menu, and the panel clock does not redraw properly -- those issues may or may not be related. Please ask if you need me to provide further information.
*** Bug 116530 has been marked as a duplicate of this bug. ***
Absolutely reproducible grey background panel distortion bug: No Bug is visible when: Pager Options -> Background -> Any Pager Options -> Text Label -> No Label Bug is triggered when: Pager Options -> Background -> Any Pager Options -> Text Label -> Desktop Name/Number [Common Options: Pager Options -> Window Thumbnails and Window Icons ON]
*** Bug 116924 has been marked as a duplicate of this bug. ***
*** Bug 117079 has been marked as a duplicate of this bug. ***
Stephan Kulow has recently announced KDE 3.5 rc2 (not that recently but I would like to grab your attention: kdebase xdelta weighs 675Kbs - something is definately worth investigating). Has anyone rechecked this bug? IMHO this bug is important that's why I have added Stephan to CC list (from http://lists.kde.org/?l=kde-i18n-nl&m=113261565213710 : put me on CC on bugzilla entries - don't send me private lists of show stoppers)
> Has anyone rechecked this bug? yes, anton, i'm on top of this situation. a) it's too late for 3.5.0 b) i really don't see how this is a show stopper. just don't run the pager with labels and in transparent mode. c) kicker's transparency mode is a huge hack anyways and not the default setting d) it isn't a crash inducing bug
While I had no problem with the transparency of kicker with the RCs of KDE 3.5(SUSE 10 RPMs), this bug occured to me with the new offical packages provided on the KDE ftp and SUSE ftp. First of all, I had just the 3/4 black (or gray) squares behind the icons -for example behind the K-Menu icon. Second, I noticed that there are some graphical fragments in the vertical K-menu bar (see attached png). Then, after playing around in the settings, I worsened the situation by changing the transparency color. By now, kicker gets completeley gray (just a little square on its top left is transparent) when I switch between the desktops (also see png).
Created attachment 13707 [details] Grey square effect caused by mouseover and a graphical issue in the vertical menu bar.
Created attachment 13708 [details] 99% grey and 1% transparent kicker Btw. the squares and the graphical fragments happens just after a while of playing around - maybe some memory leak?
*** Bug 116322 has been marked as a duplicate of this bug. ***
*** Bug 117571 has been marked as a duplicate of this bug. ***
Just confirming that this bug gets fixed if I set my Desktop Preview & Pager background to elegant.
*** Bug 118195 has been marked as a duplicate of this bug. ***
I also confirm that the bug is fixed with elegant Pager seting (or using Kicker Pager applet instead).
*** Bug 118187 has been marked as a duplicate of this bug. ***
*** Bug 118278 has been marked as a duplicate of this bug. ***
SVN commit 488745 by aseigo: without the shadow it doesn't look nearly as nice, but i've failed to nail down why that is intefering with other painting operations. and given that the shadow code is bloody slow and the feature is a minor thing <insert more rationalizing here> ... so out it goes for 3.5.1. people have lived without it until 3.5.0 after all ;) BUG:113235 M +0 -20 pagerbutton.cpp --- branches/KDE/3.5/kdebase/kicker/applets/minipager/pagerbutton.cpp #488744:488745 @@ -384,26 +384,6 @@ { QString label = (m_pager->labelType() == PagerSettings::EnumLabelType::LabelNumber) ? QString::number(m_desktop) : m_desktopName; - QPixmap textPixmap(w, h); - - textPixmap.fill(QColor(0,0,0)); - textPixmap.setMask(textPixmap.createHeuristicMask(true)); - - // draw text - { - QPainter tp(&textPixmap); - tp.setPen(Qt::white); - tp.setFont(font()); // get the font from the root painter - tp.drawText(0, 0, w, h, AlignCenter, label); - tp.end(); - } - - // draw shadow - QPixmap img; - img.convertFromImage(m_pager->shadowEngine()->makeShadow(textPixmap, - liveBkgnd ? Qt::black - : Qt::white)); - bp.drawPixmap(0, 0, img); bp.drawText(0, 0, w, h, AlignCenter, label); }
*** Bug 119445 has been marked as a duplicate of this bug. ***
confirm to have the same issue as #52 in KDE 3.5.0 (Mandriva Cooker)