Description of problem: nm-applet, which is started from KDE auto-run section, is not visible (icon in system tray is blank). It is possible to activate popup ment and even use it. But menu is really huge. Version-Release number of selected component (if applicable): [sergeil@ua-dudn00000 ~]$ rpm -qf `which nm-applet` NetworkManager-gnome-0.8.9997-2.git20110531.fc15.i686 How reproducible: 90%. Steps to Reproduce: 1.delete plasma network manager applets 2. Add nm-applet to KDE auto-start 2. Reboot system 3. login into KDE Actual results: nm-applet icon is blank, pop-up menu is really huge Expected results: nm-applet show standard icon and standard menu Additional info: `service NetworkManager restart` from konsole help.
I'm having the same problem on F15 after upgrading (using preupgrade) from F14. On F14 using nm-applet with KDE still worked without problems. Version-Release number of selected component (if applicable): $ rpm -qf `which nm-applet` NetworkManager-gnome-0.8.9997-4.git20110620.fc15.x86_64
I'm also having this problem (clean F15 install). For me it's not that the icon is invisible, just that its size is wrong. When it's too big and I'm connected to a wireless network the only part of the icon visible is the (blank) top-left corner. The icons in the menu are similarly sized. Sometimes I have the opposite problem and the icon is smaller than it should be, which is ugly but at least functional.
Maybe it is depend to hardware or video-driver? [root@ua-dudn00000 ~]# lspci -nn | grep VGA 00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) Screen is 12"
I don't believe this is NetworkManager-specific, I've seen similar problems with other GTK-based applications (e.g. pidgin or nall): Icons of GTK applications that are embedded in the KDE system tray are sporadically displayed either too large, too small or simply white. Workaround: Have you tried using kde-plasma-networkmanagement instead of nm-applet? It's available either as a system tray icon or a standalone plasmoid, it blends in nicely with the other KDE icons, and you don't need to use any auto-run tricks to get it started on login.
I've tried switching to kde-plasma-networkmanagement once, but it didn't work for me for the following reasons: - kde-plasma-networkmanagement didn't offer all the functionality that nm-applet has - the configuration I made (VPN connection profiles etc.) in nm-applet were not available in kde-plasma-networkmanagement so I would have to redo all the configuration again from scratch So right now switching to kde-plasma-networkmanagement is not really an option for me.
>> - kde-plasma-networkmanagement didn't offer all the functionality that nm-applet has +1 I use mobile internet very much and nm-applet show me when I'm in rouming (cost of traffic is 3 times). Also nm-applet visualise me when vpnc connection is estableshed. It is very important in case if internet is unstable...
I've also seen this (in the past, admittedly) with other apps (mainly pidgin). In the past I used GNOME on my laptop, but since I find GNOME3 dreadful, I've switched to KDE4 there - hence being exposed to this with nm-applet. It seems to be that the app fails to determine what size icon it should use for the system-tray. I much prefer nm-applet to the KDE networkmanagement tool, however the latest update to the plasmoid fixes the major problem I had (not showing what network I'm actually connected to) so it's an acceptable workaround for me now.
I got some issue , sometimes on startup nm-applet not show in systray-icons in kde. and others times pidgin icons too big. I got this problem since early Fedora 14.
(In reply to comment #4) > I don't believe this is NetworkManager-specific, I've seen similar problems > with other GTK-based applications (e.g. pidgin or nall): Icons of GTK > applications that are embedded in the KDE system tray are sporadically > displayed either too large, too small or simply white. I agree, my workaround is simply , killall nm-applet and run it again, on second time always appears correctly. Same for pidgin, quit and lunch again always solve the problem.
> my workaround is simply , killall nm-applet and run it again, on > second time always appears correctly. For me it do not work (not every time). For me it is much more effective to restart NetworkManager `service NetworkManager restart` when nm-applet is running.
(In reply to comment #10) > > my workaround is simply , killall nm-applet and run it again, on > > second time always appears correctly. > For me it do not work (not every time). For me it is much more effective to > restart NetworkManager `service NetworkManager restart` when nm-applet is > running. Both should really have the same effect AIUI (causing nm-applet to create the tray icon again), but killing the applet only seems less drastic. I usually tried killing and restarting nm-applet and often it worked, but sometimes it just made the icon a different (still wrong) size... I guess the bigger issue is why do some GTK (only GTK?) apps have such trouble getting their tray icons the right size in KDE?
OK, so we have wrong size (or invisible - for magnified empty corner) gtk tray icons in kde. So far confirmed for nm-applet, pidgin and I can add ibus applet too. So this is not nm-applet/NetworkManager's fault. Tray icons are part of gtk_status_icon_* from gtk -> changing component. I don't know if it's gtk's fault or kde's fault, but gtk is definitely better component than NetworkManager. So I'm changing component to gtk and cc-ing people from kde sig.
An odd/interesting workaround at least in the nm-applet case I've seen, is to quit/kill nm-applet, and restart it. It more often that not works on the second try.
(In reply to comment #13) > An odd/interesting workaround at least in the nm-applet case I've seen, is to > quit/kill nm-applet, and restart it. It more often that not works on the > second try. Hi , can't quit nm-applet because haven't the option , so have to be kill. Today I got a small nm-applet icon and try service NetworkManager restart, which also work . but on pidgin , I just have the quit and lunch again, or in preferences -> system tray icon to never and after apply to always.
Asking Ryan for an opinion as to whether this belongs in GTK or KDE.
To me, seems a problem on kde startup, I never notice the icons problems after startup finish. I also saw problems on bluedevil-monolithic on startup , but can be not related.
The trayicon of krb5-auth-dialog is sometimes also scaled wrong on my system.
hi, I found a way to reproduce this problem easily, if you run on konsole nm-applet and ctrl+c to break, if you try it a few times after 3 or 4 times, one of than will leave nm-applet icon empty .
I'm not sure if this is relevant to this issue but I also see similar issue with ibus. ibus icon on systray is sometimes scaled wrong and the icons are overlaid when turn IM on/off. I tried this on Fedora 17 RC3 on KVM.
still happens on F17
*** Bug 844037 has been marked as a duplicate of this bug. ***
https://bugs.kde.org/show_bug.cgi?id=278131 I asked to file that bug 278131 but I don't know if GtkStatusIcon could be used without the xembed method.
I see that my bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=844037 has been closed as a duplicate of this one. I just want to emphasize that I don't have any icon visibility issues and that restarting ibus-daemon does not result in any changes reported in the bugzilla that I reported. I have cases of the ibus icon showing improperly, it looks like a line a few pixels high, and restarting ibus-daemon will cause the icon to appear normally 9 times out of 10. But, I can never get the ibus menus to display by right or left clicking on the icon. It didn't seem to me that these were related...which is why I filed 844037.
GtkStatusIcon only supports the old XEmbed-based system tray spec. :-( GTK+ apps need to use Canonical's indicator implementation to use the new spec, but patches to GNOME apps making them use that library have been rejected by almost all upstreams, under the excuse that the library is supposedly not stable enough. So we're stuck with the legacy protocol. :-(
I'm wondering why one didn't ask for updating GtkStatusIcon's implementation in gtk+ to upstream instead of asking for using Canonical's implementation. aside from that, if the updates isn't yet reflected to the systray spec in freedesktop.org - apparently the last updates looks like made 3 years ago. is gtk+ not compliant to it ?? the last updates on xembed spec has been made 10 years ago!? anyway, just wonder what's "new" and "old" - it should be done first IMHO.
The (XEmbed-based) systray spec (the "old" spec) was superseded by the status notifier spec (the "new" spec) as far as KDE and Canonical (Unity) are concerned. The problem is that the GNOME developers refuse to support the new spec because they don't like its wording and because they think it doesn't fit the gnome-shell design. So we're stuck with the old legacy spec everyone considers deprecated (including GNOME, who consider the entire system tray deprecated in the first place). GNOME is blocking any improvements for political reasons (they want the system tray to go away entirely).
The symptoms of this seemed to have gone away and then come back for me (now on F17). Kevin, does KDE intend to provide backwards compatibility for the old spec? If so, the current state would be a KDE bug (and the oddness about different behavior on startup vs. subsequently raises an eyebrow about this). If not, it would be a GNOME RFE.
Yes, the Plasma system tray widget is supposed to support the legacy XEmbed spec, to the extent possible. The problem is that the spec is very broken, which is why we have a new spec in the first place. Its handling of size is poor (it was originally designed under the assumption of a fixed hardcoded system tray size), its handling of transparency is poor (which is why the system tray does not have gradient backgrounds anymore in Plasma: GTK+ uses an opaque RGB visual to draw the XEmbed-based icons, and forcefully changing it to ARGB would cause crashes and misrenderings) etc.
I see the bug mentioned in the comments here: https://bugs.kde.org/show_bug.cgi?id=133936 Not sure if that bug represents the root cause or not. Anyway, probably not fair to assign to gtk3 at this point. P.S. there's a NEEDINFO on this bug for me from 'desrt' but I can't find the question. Clearing in case it's old; please re-ask if I can be helpful.
Sure. but given that KDE is really compatible with old spec, how does it explain one work on GNOME and one doesn't on KDE? the old spec may be broken. but there should be a reference implementation to get it working properly. indeed, it may be a RFE for GNOME but sounds not a bug for gtk+ so far. it would rather sounds like a regression bug in KDE to me as it worked before.
*** Bug 822762 has been marked as a duplicate of this bug. ***
Well .. I'm facing the problem in $Summary -> *NO* gtk looking apps are shown in tray on my laptop. It is F18 - fresh install. Examples: clementine, pidgin, stardict, liferea, ... Is there some workaround? And yes - if I remove all KDE configuration it works, but I don't want to do this anymore. This is tooo annoying. What file exactly should I remove to reset my try space? Point me where should I look, how should I debug it, etc. Where is the code I need to observe and debug? What you need from me to help you to find the core of this problem? I would like to debug the wrong tray size also (it was present on my box before the tray icons left completely to make it important bug). How to speedup reproducing of this bug - try to approach xrandr/krandr* with external monitores (switch to double head and back, ...). Thanks, Pavel // other info (just for sure - but it should not be as important - similar problem was on my ATI about 6 year old ATI box, and NVIDIA box 3y+ old) 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
this still present on F18
>> this still present on F18 +1 Version: 17 → 18
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.