Version: 3.5 (using KDE 3.5.0, compiled sources) Compiler: gcc version 3.3.6 OS: Linux (i686) release 2.4.31 In the Knotes, the Baghira subject takes off the false transparency of the Knotes, placing a deep one in it. See: http://img30.imageshack.us/img30/2628/bugkicker17af.png If I choose another subject, as the Plastik, the deep one does not come back to be transparent, only dumb the color of the deep one of striped of the Baghira, toward only white. Then I believe that is one bug of the Knotes (or Kicker?), therefore a style could not intervene with another one. This also happens with the Clock and the Klipper, but for the time being, I obtain to reproduce with easiness the problem of the Knotes.
I really don't understand what you want to say... sorry. Can you please add another screenshot of how you think it should look like and mark the wrong parts with a red circle? Thanks!
It sees the background one of the Knotes (close to the Clock). Background its is normally transparent (with Kicker transparency activated), but when the Baghira style uses, the background one is not more transparent. Using another style later, the Knotes continues with deep the not transparent one See, with red circle: http://img73.imageshack.us/img73/1139/bugkicker9yh.png It forgives for the bad English =)
Aha, gotcha! If you enable transparency in Kicker while using the Baghira style the KNotes icon is not transparent anymore and switching back to Plastik does not fix it. Well, I have the same problem in KNotes 4/KDE 4. I don't know where the bug is but I *guess* it's Kicker. Aaron should know, so I CC him.
Ha, maybe I should also include what I do in KNotes, just in case it's wrong and so that Aaron doesn't need to search for it. The toplevel window is KNotesApp, a QLabel, and it does: KWin::setSystemTrayWindowFor( winId(), qt_xrootwin() ); setBackgroundMode( X11ParentRelative ); setPixmap( KSystemTray::loadIcon( "knotes" ) ); That's all. (BTW, could the bug also be in the Baghira style?)
i don't have baghira installed to test this, but it looks like the label is painting the background instead of leaving the alpha mask on the icon. i wonder if baghira. briefly looking at the code, the only difference i see between KNotesApp and KSystemTray (any reason for not subclassing KSystemTray instead of QLabel directly?) is that KSystemTray does setBackgroundOrigin(WindowOrigin); ... though it would be odd if baghira were looking at that property to decide whether or not to force painting a background.
Is this still valid with KDE 4.10?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!