Summary: | GTK icons are painted bigger than KDE icons | ||
---|---|---|---|
Product: | [Unmaintained] plasma4 | Reporter: | Daniele <danielekde> |
Component: | widget-systemtray | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | RESOLVED UNMAINTAINED | ||
Severity: | normal | CC: | crazy, eaton.mark, kevin.kofler, l.lunak, mefoster, moabi2000, progger1986, rdieter, renda.krell, StormByte, wolfger |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
Picture to explain this bug
Possible fix systray shot with GTK and TCL apps Unidentified object between nm-applet and kpowersave test-patch patch for review second try theird try testcase nr2 The white space to the right of the Klipper icon should be the Pidgin online state icon Systray icons now in 4.0.82 (OpenSUSE 11.0). Gentoo with a recent SVN checkout After removing/readding the applet Patch by Mathias Kraus for system tray layouting |
Description
Daniele
2008-01-10 09:02:43 UTC
Created attachment 22930 [details]
Picture to explain this bug
I don't know if this is a plasma problem. I was seeing the same behavior with pidgin in KDE 3.5 on Kubuntu. Yeah, Pidgin did that with me in KDE 3.5.x too. But the strange thing is that closing another icon, pidgin icon are painted correctly! The emesene icon looks fine. The icons can't be any bigger than 22x22 which is why the pidgin icon is being cut off. Are you sure this is not a pidgin bug? there are a lot more GTK ( basically no-kde apps because tcl apps have problems also ) appplication with that problem .. like xchat , bmpx etc Created attachment 22980 [details]
Possible fix
Looking at the screenshot, it appears that the GTK apps think their icon window
is bigger than it really is. I haven't been able to reproduce this yet, but I
wonder if this patch fixes it?
yeah, that patch looks familiar: i had to do the same thing in kde3's system tray ;) the application sets the size of the item even though it has absolutely NO WAY of knowing where it will appear. one more reason the current system tray if friggin' brain damaged. no, that's not kind to the brain damaged, because the system tray is far, far, far more annoying and stupid.... I doesn't fix anything here. I'll attach an shot with some gtk apps and a tcl one. Just in case you wonder what that strange thing on the desktop is , it is the amsn 'systray' icon =) Created attachment 22997 [details]
systray shot with GTK and TCL apps
Jason, I tried to apply your patch to the code but the situation is worst. Without patch, if I close another icon in the tray, pidgin icon are painted correctly. With the patch, if I close another icon in the tray, pidgin icon remains painted bad. *** Bug 155529 has been marked as a duplicate of this bug. *** I can confirm this too with pidgin (I didn't have this error in kde 3.5.x ) joy, here too with some other gtk-based apps, including (fedora's) sealert and puplet. I think one (or both) of these are inducing a plasma crash for me too (on session autostart), but I'll worry about that later. :) I confirm this with pidgin. In KDE 3.5 Pidgin icon just used to fill the whole height of the panel (thus taking up about 4x the space any other icon used), but in my KDE4 SVN build this is cropped to a normal icon size, with only the upper-left corner of the icon being visible as a result. Probably, GTK apps just expect to be able to take up the whole panel height and thus produce an icon larger than the tray widget expects? I discovered that as a temporal workarround: if you close another application in systray, GTK's icons will be normal size. For example: open pidgin, open kmix, close kmix from tray, and see pidgin icon correctly. Created attachment 24050 [details]
Unidentified object between nm-applet and kpowersave
In this instance, believed to be sealert which hides itself, but apparently
having problems due to this issue.
Tried workaround mentioned in comment #16 - but doesn't work for me... :-( #16 seems to work from time to time - but it's not consistent. How can we help debug is problem? - Gilboa I confirm this bug in Fedora 9 kde4 rawhide [development] packages, version 4.0.80, all gtk icons are painted too big and then cropped just like in comment 10's attachment and I also have this mysterious unidentified object like in comment 17's attachment Just installed kde 4.1 in ubuntu, instead of the pidgin icon only a white square appears. The Pidgin icon is not a KDE bug, Pidgin specified that systray icon minimum size is 48x48, but our systray sets sizes to 22x22, and the systray spec says apps are to cope with whatever size they get. $ xwininfo -tree | grep pidgin [click on Plasma now] 0xc0001e "Pidgin": ("pidgin" "Pidgin") 48x48+0+0 +1238+936 $ xprop -id 0xc0001e | grep minimum program specified minimum size: 48 by 48 Unless somebody can confirm a case where the app does not specify such size constraints, this is INVALID. How does KDE 3 deal with this? Does it give the apps what they request and then downsize the result? Oh, and I see this happening in _all_ GTK+ applets, so maybe this is inside GTK+'s own code. At least nm-applet (NetworkManager-gnome) and gnome-packagekit are known to behave that way. Moreover, all this doesn't explain the unidentified icon in comment #17 (I've seen more of these, usually there are some white rectangles in an otherwise all-black icon, though I've also seen the blue noise as in comment #17), is that actually a separate bug? From comment #22: "systray spec says apps are to cope with whatever size they get" Well, in KDE3 these apps seem to cope with it just fine. The problem only occurs in KDE4. So I'm not sure how anybody can be saying "oh, its an app/gtk+ issue". It's a dis-improvement on KDE. Thanks Lubos! Actually, in KDE 3 the systray windows for GTk apps such as Pidgin were just bigger than all the others. But it's constrained by the taskbar size (apparently shrunk to that size, because it's definitely not displayed as 48×48 which doesn't fit in my small taskbar) and not cut, so with a small enough taskbar, you don't notice. Created attachment 25179 [details]
test-patch
It seems GTK-apps try to be clever here since they scale there trayicon.
The patch above shows it. While e.g. klipper sticks with it's 22x22 size the
pidgin-trayicon always scales up/down to the maximal size. What a mess :-/
Created attachment 25180 [details]
patch for review
Attached patch fixes at least the pidgin-prob for me. Ok to commit?
Created attachment 25181 [details]
second try
ups, a small typo went in. Second try :)
Doesn't quite work - the icons are cropped at the first layout: http://ktown.kde.org/~lukas/pics/gtkicons-kdetray4.png However, after I start and quit some tray app, the icons relaid out and all is correct: http://ktown.kde.org/~lukas/pics/gtkicons-kdetray4.png Created attachment 25198 [details]
theird try
Thanks Lukas,
seems I am not able to reproduce the truncate :-/ Anyway, I did note that
MARGIN is used for the calculations but was never set on the layout what
would/could explain it.
Therefore; theird try/patch :)
It also contains 2 additional fixes;
1) according to some samples systemTrayClientId can be 0 and in that case we
wan't embed and
2) don't try to create a systray-icon if it was already created else we just
earn a black rect (reproducable by just trying to stark e.g. pidgin a second
time).
With the 3rd patch, things are now laid out correctly, but not on the first run. Furthermore, the icons are somewhat smaller now (scaled down) :/ On a side note, the systray gets completely busted when you position the whole panel on the sides (vertically) Created attachment 25199 [details] testcase nr2 > but not on the first run eh, I've no idea why that's the case now and can't reproduce it :-/ anyway, there is a small possibility that the "testcase nr2" attachment may fix it (or make things even more worse). So, if you are motivated to give it a try (last one I promise)?! :) > the icons are somewhat smaller now (scaled down) :/ but at least they respect now the margin and therefore don't overlap with the panel's border. Or does you mean they are not any longer 22x22 pixel like before even if the panel's height is big enough (as in ~26pixel height)?! hmpf, I can't reproduce this one too :-/ > completely busted when you position the whole panel on the sides even more worse, if you try to move it back to a horizontal position it jumps around here. But well, step by step ;) I've fixed the problem with the first layout in a patch on dashboard but haven't had time to get back to it yet. MARGIN and spacing are fine as they are. The problem lays with the data used in calculations in addWidgetToLayout or whatever that method is called. Ok, I've committed the changes I've mentioned above, but the following two changes aren't covered. Window ww = XCreateWindow(dpy, parentWidget() ? parentWidget()->winId() : DefaultRootWindow(dpy), - 1, 1, 1, 1, 0, ga.depth, InputOutput, ga.visual, + 0, 0, 22, 22, 0, ga.depth, InputOutput, ga.visual, If this fixes this bug, then it should definitely be applied. ;) + if (systemTrayClientId == 0) + return true; + + foreach(SystemTrayContainer* c, findChildren<SystemTrayContainer*>()) + if (c->clientWinId() == systemTrayClientId) + return true; In a perfect world this shouldn't be needed but I guess it's not very good practice to trust other applications. :) Especially GTK+ ones. ;-) re; - 1, 1, 1, 1, 0, ga.depth, InputOutput, ga.visual, + 0, 0, 22, 22, 0, ga.depth, InputOutput, ga.visual, probably your additional resize() does the same. No idea there. re; + if (systemTrayClientId == 0) + return true; better be safe then pay alimonies ;) re; + foreach(SystemTrayContainer* c, findChildren<SystemTrayContainer*>()) + if (c->clientWinId() == systemTrayClientId) + return true; This one fixes the case that unique-/single-instance apps seem to like to register a second time. iirc pidgin does so (or xchat?!) and it results in a SystemTrayContainer filled with a black rect. re; "patch on dashboard" oh, man. Linus is right, we (KDE) are stupid and ugly. Sorry for that, but those "review-board" is just the wrong way imho.[/grant] To me, all 3 of those changes (quoted in comment #37 and comment #39) look like they can't hurt, so I'd suggest committing them all. Hopefully Lukáš can do some more testing with the latest patches. Yes pls commit them so I can test, I just tested against current trunk and therefore cannot apply your previous patches fix committed with r818620 in trunk. It should now work as expected :) *** Bug 163320 has been marked as a duplicate of this bug. *** Even worse with current trunk :/ As you can see from the screenshot, gtk icons are not drawn at all (blank space), KDE 3 app (konversation) icon is chopped and other Qt4/KDE4 apps' icons are rendered mini small... http://ktown.kde.org/~lukas/pics/gtkicons-kdetray4-badagain.png hmmm, so we need to do the resize() then at a later time. r818824 should fix that now. Almost... now the GTK icons don't show at all; the blank space between konversation and kwallet is nm-applet. It doesn't react to any mouse event but it pops up balloon messages when I go online/offline :o) http://ktown.kde.org/~lukas/pics/gtkicons-kdetray4-stillwrong.png ok, it seems we got multiple new regressions since r818155 from comment #37 :-/ see bug #163320 and bug #163565 @jason any idea? Just for my own sanity if nothing else, are these genuine *kde* bugs, or are we simply patching/working-around gtk bugs? Or some middle ground? I just want to confirm the same problem with Pidgin in KDE 4.0.81 Beta1 (OpenSUSE 11.0 packages), there is a bad zoom factor of it's icon or bad colors. There are already problems in KDE3 with zooming the Pidgin icon, it always appears to be a bit bigger than the KDE icons around it in the taskbar. In KDE4, the initial Pidgin icon appears even bigger and after changing for instance on incoming messages it shows only a white space with a small piece of somewhat of the icon picture on the right downside corner. GTK version 2.12.9. Created attachment 25258 [details]
The white space to the right of the Klipper icon should be the Pidgin online state icon
Rex: imho neither of it, the X11-protocol for systrayicons just sucks :) Rene: what revision is that? >=r818824? Sebastian: I can't tell you the SVN revision reliably, since I use precompiled binaries from the OpenSUSE factory. Help->About KDE tells me: Version 4.00.81 (KDE 4.0.81 >= 20080527) "release 6.4" rpm -qi --changelog kdebase4-workspace-4.0.81-5.1: ---------------------------------------------------------------- Install Date: Tue 10 Jun 2008 08:06:02 PM CEST Build Host: build15 Group : System/GUI/KDE Source RPM: kdebase4-workspace-4.0.81-5.1.src.rpm Size : 18459986 License: GPL v2 or later Signature : DSA/SHA1, Tue 10 Jun 2008 09:35:23 AM CEST, Key ID 58d8ff412e1efa87 URL : http://www.kde.org/ Summary : The KDE Workspace Components Description : This package contains the basic packages for a K Desktop Environment workspace. Authors: -------- The KDE Team <kde@kde.org> Distribution: KDE:KDE4:UNSTABLE:Desktop / openSUSE_Factory * Wed May 28 2008 dmueller@suse.de - obsolete kdebase4-workspace-plasmoids * Thu Mar 13 2008 dmueller@suse.de - update to 4.0.66 ... ---------------------------------------------------------------- In the latest OpenSUSE packages versioned as 4.0.82 the systray problem with Pidgin is solved, except that the icon background of all icons is not transparent. Additionally, all icons are better aligned now to the systray (vertically centered). As far as I can see, there is a progress ... ;-) Thanks Name : kdebase4-workspace Relocations: (not relocatable) Version : 4.0.82 Vendor: openSUSE Build Service Release : 18.1 Build Date: Wed 11 Jun 2008 11:04:22 PM CEST Created attachment 25303 [details]
Systray icons now in 4.0.82 (OpenSUSE 11.0).
FYI: This is the way the systray icons look now in 4.0.82 (OpenSUSE 11.0).
After over six months this is good to hear. Good work by Sebastian. :) The background color issue is known and covered in a separate bug, so I'll close this one as fixed. Created attachment 25308 [details]
Gentoo with a recent SVN checkout
As for me, I still have problems with the systray. It looks fine as long as
there are few enough icons, but when more are added, they are displayed in two
rows, incorrectly resized (see the image). These are KMix, KNetworkmanager,
KBluetooth and KWallet. Space to the left is occupied by the digital clock,
which is displayed in black font for some reason. Thus, I believe that it is
not FIXED yet, unfortunately.
Do you have a revision number for the checkout? `svn info` in kdebase/workspace/plasma/applets/systemtray would be great to confirm. Jason, as you requested, here is my `svn info`: Path: . URL: svn://anonsvn.kde.org/home/kde/trunk/KDE/kdebase/workspace/plasma/applets/systemtray Repository Root: svn://anonsvn.kde.org/home/kde Repository UUID: 283d02a7-25f6-0310-bc7c-ecb5cbfe19da Revision: 820179 Node Kind: directory Schedule: normal Last Changed Author: sebsauer Last Changed Rev: 818824 Last Changed Date: 2008-06-09 23:08:32 +0400 (Пнд, 09 Июн 2008) The problem survives reboots. That's the latest. Reopening, but I can't reproduce it here. :( Same problems as in comment #56, the systray is basically unusable :{ nm-applet doesn't even show up although it is running Created attachment 25328 [details]
After removing/readding the applet
After removing the applet from the panel and adding it again, icon sizes are as
expected, but icons are drawn in a wrong place. This is the same SVN build.
Again, place to the left is not empty, but rather occupied by the clock.
Created attachment 25348 [details] Patch by Mathias Kraus for system tray layouting As posted on http://lists.kde.org/?l=kde-panel-devel&m=121345463825632&w=2 *** Bug 163565 has been marked as a duplicate of this bug. *** Comment on attachment 25348 [details]
Patch by Mathias Kraus for system tray layouting
Index: systemtraywidget.cpp
===================================================================
--- systemtraywidget.cpp (revision 820643)
+++ systemtraywidget.cpp (working copy)
@@ -132,31 +132,31 @@
// Figure out where the next widget should go
if (m_orientation == Qt::Horizontal) {
+ // Calculate the items that fit into a column
+ m_maxCount = (maximumHeight() + m_mainLayout->spacing()) /
(widget->height() + m_mainLayout->spacing()) -1;
+
setMinimumSize(QSize(22 * (m_nextColumn + 1) + m_mainLayout->spacing()
* m_nextColumn,
22 * (m_maxCount + 1) + m_mainLayout->spacing() *
m_maxCount));
+
// Add down then across when horizontal
m_nextRow++;
- if ((m_nextRow == m_maxCount && m_nextColumn != 0) ||
- minimumHeight() + widget->height() + m_mainLayout->spacing() >
maximumHeight()) {
+ if (m_nextRow > m_maxCount){
m_nextColumn++;
m_nextRow = 0;
}
- if (m_nextColumn == 0) {
- m_maxCount = m_nextRow;
- }
} else {
+ // Calculate the items that fit into a row
+ m_maxCount = (maximumWidth() + m_mainLayout->spacing()) /
(widget->width() + m_mainLayout->spacing()) -1;
+
setMinimumSize(QSize(22 * (m_maxCount + 1) + m_mainLayout->spacing() *
m_maxCount,
22 * (m_nextRow + 1) + m_mainLayout->spacing() *
m_nextRow));
+
// Add across then down when vertical
m_nextColumn++;
- if ((m_nextColumn == m_maxCount && m_nextRow != 0) ||
- minimumWidth() + widget->width() + m_mainLayout->spacing() >
maximumWidth()) {
+ if (m_nextColumn > m_maxCount) {
m_nextRow++;
m_nextColumn = 0;
}
- if (m_nextRow == 0) {
- m_maxCount = m_nextColumn;
- }
}
}
Patch from comment #62 resolved all the issues for me, looking forward for it to appear in trunk. Thanks to everybody involved! patch committed with r820991 in trunk. another try to mark the bug closed :) Yay! Nice work, all seems to be working fine so far (except the black non-transparent background, but that's another issue) *** Bug 164567 has been marked as a duplicate of this bug. *** Hello! Plasma 4 was replaced by Plasma 5 four years ago by the KDE community. In that time we have made great strides in stability and functionality. We are closing all Plasma 4 bugs as most of them are no longer applicable to the new frameworks Plasma 5 is built upon. If you could, please re-test with the latest version of Plasma 5, and submit a new bug to "plasmashell" if you continue to have an issue. Thank you! |