GNOME Bugzilla – Bug 556099
cpufreq-applet sometimes invisible on panel
Last modified: 2009-01-15 08:58:37 UTC
Sometimes when I log in in GNOME 2.24 (on Mandriva Linux 2009.0 x86_24), the cpufreq applet is invisible. On the location where it should appear, there is a grey area. If I click on this area, the cpufreq pop-up menu appears normally and also the right click menu works fine. In the applet's preference, I have it set to monitor CPU 0 and the appearance is set to Graphics and Text, with the CPU frequency shown as frequency and showing frequency units. All other applets (tomboy, notification area, gnome menu, launchers, volume applet, date/time, workspace switcher etc...) are appearing without any problem.
Created attachment 120490 [details] Screenshot of "invisible" cpufreq applet
Yes, I've noticed it too, but I have no idea why this happens and it's not always reproducible so I'm afraid it's not going to be easy to fix. Thanks for reporting.
This also reproduces in Ubuntu 8.10. Here is the Ubuntu Launchpad bug for reference: https://bugs.launchpad.net/bugs/267047
I had this bug on a clean new Ubuntu 8.10 install (on two different machines, both dual core with 2 cpufreq applets running, Compiz, transparent panel). However, two days ago an update of gnome-panel and some other GNOME packages were released for Ubuntu, and since then, the situation has improved significantly. On one machine the problem seems to have gone away completely since I installed the updates (before the update, there was always at least one of the two cpufreq applets which was not drawn correctly). Still have to check out the second machine.
Ah sorry. Please ignore my former comment. Seems like I just had luck for two days, when the applet suddenly worked. Now the problem is back again.
As I already mentioned in the related Ubuntu bug report, this does not happen, if you have "None (use system theme)" set as panel background. Or can somebody disagree?
I've just committed a few changes to svn trnk that might fix this problem, but I'm not sure because it's hardly ever reproducible for me. Could you guys confirm this is fixed in svn trunk, please? Thanks.
I too am affected by this bug (I have a quad-core so at least one of them dies every time I log in :P) Running Ubuntu Intrepid, 64-bit Carlos, I will test it, but I probably won't have time until after Christmas.
I checked out a copy, and tried to compile it, but automake (I assume that's what I'm supposed to use given the Makefile.am) keeps telling me: automake: `configure.ac' or `configure.in' is required I've never used automake before, and a quick google doesn't turn up any useful results. Can somebody tell me what I'm missing? (So much for after Christmas :)
(In reply to comment #9) > I checked out a copy, and tried to compile it, but automake (I assume that's > what I'm supposed to use given the Makefile.am) keeps telling me: Great, thanks :-) > automake: `configure.ac' or `configure.in' is required > > I've never used automake before, and a quick google doesn't turn up any useful > results. Can somebody tell me what I'm missing? > try with: $ ./autogen.sh $ make or take a look at jhbuild (http://live.gnome.org/Jhbuild).
(In reply to comment #10) > try with: > > $ ./autogen.sh > $ make There is no autogen.sh in gnome-applets/trunk/cpufreq/ only in gnome-applets/trunk/ Does this mean I can't rebuild only the cpufreq applet but need to rebuild all of the applets together?
(In reply to comment #11) > Does this mean I can't rebuild only the cpufreq applet but need to rebuild all > of the applets together? > Well, you can run autogen.sh and then make under cpufreq
Successfully built and installed ('about' now shows 2.25.2). I rebooted once after the install, and all four loaded properly. That happens sometimes anyways, so I wouldn't call it conclusive, but still a good sign. I'll let you know in a few days how they're working.
It's working fine. This can be marked fixed.
Is it possible to apply the fix to the 2.24 branch?
Backporting to 2.24 would be pointless since there are no more scheduled releases. Marking as fixed.
According to http://live.gnome.org/TwoPointTwentyfive/ Jan 12: GNOME 2.24.3 Stable tarballs due Seems like a good reason to me to apply this to 2.24 branch.
Sorry, my mistake. Carlos: do we have a clear idea about which of the recent updates cured the problem? Most of the changes look fairly harmless, is it safe to apply the lot?
I've backported all the changes that seem appropriate from trunk to the 2.24 branch.
(In reply to comment #18) > Carlos: do we have a clear idea about which of the recent updates cured the > problem? Most of the changes look fairly harmless, is it safe to apply the lot? > hey Callum, sorry for not replying before but I was on vacation. Thanks for backporting the patches.