KDE-Base from CVS HEAD 05/01/05: I use a pseudo-transparent kicker. When the systray is resized due to addition/removal of tray icons, applets like taskbar and pager are moved, but their background (displaying the background image) is not updated like it's done when moving/resizing the applets manually. Thus the background is "displaced" i.e. moved down: http://www-user.rhrk.uni-kl.de/~f_osterf/temp/kicker-transparency-bug.png The red arrow shows the displacement. Here you can see the background image without kicker: http://www-user.rhrk.uni-kl.de/~f_osterf/temp/kicker-transparency-background.png Note that also the systray background is distorted (The leaves belong in the upper part of the systray, the lower part should be clear). When changing desktops, the background gets "fixed".
*** Bug has been marked as fixed ***.
The bug is not fixed yet (kdelibs and kdebase from Feb 12th). When I open an app which adds a tray icon, it still breaks the taskbar background.
i actually committed the fix for this on the 12th. i tested it here (both after the commit and again just now), and it works: an icon added to the systray pushes the other applets over and their backgrounds are now updated. this is why closed the bug report. can you please update kdebase/kicker and try again?
Ok, I tried again. KDE start went just fine, after restoring the session and adding tray icons, the background was ok. I started Psi then (qt-only), and that broke the background. I switched desktops to fix it and tried akregator. Now it worked. Ok, I thought, it works for KDE apps using KSystemtray but not for non-KDE apps. But just now, every app, regardless whether KDE or non-KDE app, breaks it again.
*** Bug 98941 has been marked as a duplicate of this bug. ***
I'm still having issues with the repainting around the system tray in particular on a transparent kicker as well, on current cvs head.
i'll need screenshots, app names and what leads up to the transparency breaking to be able to attempt to fix these things.
Right after startup (klaptop, kmix, klipper, korganizer alarm daemon in the systray), the background is broken: http://www-user.rhrk.uni-kl.de/~f_osterf/temp/kicker-1-after_startup.png When starting akregator, the background gets fixed: http://www-user.rhrk.uni-kl.de/~f_osterf/temp/kicker-2-akregator_started.png Starting Kopete breaks it again: http://www-user.rhrk.uni-kl.de/~f_osterf/temp/kicker-3-kopete.png Closing Kopete: background moves too much upwards: http://www-user.rhrk.uni-kl.de/~f_osterf/temp/kicker-4-kopete_closed.png
I tried to reduce the number of applications to find the culprit, without success. All combinations I tried with <= 4 icons worked fine, the background was fixed. Sometimes it even worked with the icons from the first screenshot, sometimes not. Position and adding order also has an influence, but I don't see a pattern.
*** Bug 100430 has been marked as a duplicate of this bug. ***
*** Bug 101141 has been marked as a duplicate of this bug. ***
With some systray icons set to hidden, I can reproduce the same bug by clicking on the arrow to expand the systray to show all icons and then clicking again to only show the non-hidden icons. Hope this helps, and thanks for fixing.
Created attachment 10202 [details] snap1 - applets clips was turned off
Created attachment 10203 [details] snap2 - applets clips was set to rising on mouse cursor move over an applet
Created attachment 10204 [details] snap3 - it same
Created attachment 10205 [details] snap4 - another defect
As you can see from my attachement (snap1 - applets clips was turned off), after removing an icon from system tray, was the resized part of previous taskbar applet repainted with background on its origin not with background freed behind the system tray applet. And also (snap2, snap3 - applets clips was set to rising on mouse cursor move over an applet), you can see next irremovable defect (snap4 - You can see this defect after a clip rising, even if clips are hard turned on). Sometimes it moves with a whole applet background (a few pixels - lesser to a clip width) right/left, when an clip is rised/hided (on moving mouse cursor over/outside applet). Please, give me a chance to choose between a rising over an applet (after 3.3.2) and over the clip (to 3.3.2). This bugs comes with versions after 3.3.2. (sorry for my bad english)
I'm still finding this (or something very similar) on 3.5-alpha1. Every time I log in, the systray starts out with a messed-up, I suspect because amaroK auto-starts after it's been painted. (attachment 1 [details]) If I switch to another desktop, it paints itself fine. (attachment 2 [details]) If I then quit amaroK, I get a different symptom on the background. (attachment 3 [details]) Again, switching to a different desktop to force the repaint makes it be fine again. If I re-start amaroK at that point, the systray icon gets added and the background updates properly. But any time I quit any application that ends up removing a systray icon, I get the "attachment 3 [details]" problem again.
Created attachment 12562 [details] Attachment 1 [details]: how my systray always looks on login
Created attachment 12563 [details] Attachment 2 [details]: Switching to another desktop forces a repaint
Created attachment 12564 [details] Attachment 3 [details]: Systray after quitting amaroK
I see this problem very often. This happened when i just logged in. First the keyboard applet loaded, everything was fine. But then as the other programs started (superkaramba, kmail and akregator) the kicker background was moved. Tested in KDE 3.5beta2
Created attachment 12994 [details] kicker backround is moved and a small space is next to tray
All Say: Thank You Aaron Seigo ! :)
*** This bug has been marked as a duplicate of 113235 ***
this is actually not the same problem as in 113235
Created attachment 13378 [details] My kickerrc Here's my kickerrc.
system tray background problem: i can force to "redraw" the systray applet background by clicking on the resize applet handle. so i think some event is called to redraw the background. i guess it works like that: big panel pixmap -> cut down to small applet pixmap ->cut down to small tray size background pixmap -> set this pixmap to the parent window of the tray icon; now the tray icon can use this background as "ParentRelative". (at least non kde (gtk) programs works like that) this event to redraw (make new pixmap background) should now happen after each removing/adding of tray icons. this is probably already done. maybe to early ? to reproduce: *add one tray icon *add/remove klipper tray icon until the background image is wrong *click on the tray applet handle to fix the background
Created attachment 13421 [details] kickerrc Still here in 3.5rc1. I created a brand new user, the result is the same. Just open e.g. akregator and let it be in tray. Logout and login, session is restored, akregator gets into tray and **cks the tray transparency. Do you still need any more info? Would be nice if the problem was gone in final release.
Created attachment 13422 [details] screenshot watch the tray background
Created attachment 13423 [details] screenshot, how it should be after i clicked on a handle. systray is repainted now and looks like it should
i looked a little deeper into the code: after each change inside the tray applet AppletContainer::setBackground() should be called. which does not happen. i call this function in "void AppletContainer::slotUpdateLayout()" (probably not the right place). now the functions is called. but the "srcx, srcy" variables have the old position of all applets (this is the reason why all applets are affected)-> the wrong pixmap is cut of the panel pixmap. so this should happen after each change: 1. update all applets widget positions variables. 2. call SetBackground i'm not a C++/kde developer, so i'am out of the game ;)
*** Bug 116492 has been marked as a duplicate of this bug. ***
Is it really fixed in 3.5 or am I dreaming? :) When tasks in tray are loading, the background is redrawn correctly.
pholie: it's better in 3.5 compared to 3.4, but still not 100% perfect. it works well here, but i've seen it possible to make it break still ...
*** Bug 125562 has been marked as a duplicate of this bug. ***
Fixed in KDE 3.5.10