A cpufreq applet placed on the panel should render completely and remain so.
Almost always, the last column or two of pixels on the units label is missing (e.g. the z in Mhz is missing the right side).
Somewhat less often, more or all the the units label is missing entirely; likewise for the frequency label. On even more rare occasions the applet doesn't render at all, although it's really there as hovering over its known location will pop up the tooltip, left click opens the freq/governors menu, etc.
I have reason to think the total failure to render is a separate issue from the label truncations behavior.
Steps to reproduce the behaviour
No special action required. Just log in to a desktop which has one or more cpufreq-applets on a panel. Can also happen after resume from suspend or even any random moment.
MATE general version
1.18.0 currently, though this has been happening since at least 1.16.x.
Currently mate-applets-1.18.1-1.fc26.x86_64 but see above.
Fedora 25, 26
Link to downstream report of your Distribution
The patch below addresses the partial labels issue. I've been running this for several days and it seems solid.
The problem seems to have been in cpufreq-applet.c, where the get_max_???_width routines were trying to find the pixel width of various strings by inserting text into a freshly allocated GtkLabel and calling gtk_widget_get_preferred_width() on it, which just returns zero results. Wild guess: the freestanding GtkLabel has no associated font, so the width can't be determined. At some point someone decided it would be better to get the widths of the applet-> label instead but they're not initialized at first and who knows where the string pointer in that object was pointing. Wildly different values were returned from time to time, and the first time a positive value is acquired it becomes the sticky width for that label in *applet.
The patch gets around this by placing string values in the labels of the applet, then getting the preferred widths.
I just tested this, found it did not always work. Usually I do not get this bug, both with master and this code I tried changing between various themes, which sometimes would invoke it in BlackMATE. Once and once only, on restarting the panel after changing back to my own theme I get a truncated z in GHz.
My theme uses bold text, which caused the applet to jump until I added this to it:
Both with and without this I had had issues in the past with truncating the z on changing back to my theme, and sometimes on machines and kernels that would initially return "0GHZ" as value I would get a truncated applet. That was worst on one with an 800MHZ idle speed, and the same fix as for the jumping with bold test put a stop to that truncation. Now I saw a single, isolated instance of a truncated label even with the minimum width set, not sure how that was possible.
BlueMenta controls with Bluebuntu window borders, and Bluecurve icons and pointer.
Because of the way the applet holds onto the first positive width value it gets for the labels, you can best provoke the problem by adding cpufreq applets to the panel. If/when one turns out to be truncated, any others already present should be unaffected. Killing the panel works too.
Your observations are to be expected. The label widths are determined only once when the applet is instantiated, presumably using whatever font is currently configured, and the pixel width stored. Thereafter the stored value would be used, although after some debugging today it appears those widths are never queried again anyway, even when the font is changed. Generally, I'd expect anything you do which makes the font larger--theme change, type face, font size--than when the applet is instantiated could cause truncation.
So today I tried removing the check for an existing positive width from all the cpufreq_applet_get_max_XXXX_width() procedures. I also removed the check for applet->need_refresh flag in cpufreq_applet_update(). What I expected that to do was force a fresh determination of label widths each time the label contents changed, including a font change. That and forcing a cpufreq_applet_refresh() call each time would, I thought, render the labels without truncation. But no, I just see what @lukefromdc describes. Oh, and somewhat (un?)related, I find it truly bizarre that nothing on the panel renders any italic font.
My problem is I don't know enough yet about gtk to understand what has to happen to make updated widget attributes render visibly. More debugging is in order.
You might want to put off following through with that pull until this is sorted out. It really does seem like we're close.
I can't reproduce it, but I found 300ef94 which might be related.
So it always calls gtk_widget_get_preferred_width on applet->label, while a local label variable is just created and destroyed, but not used.
I see in #269 it's changed to modify applet->label instead. Are cpufreq_applet_get_max_xxx_width functions supposed to have a side effect?
We could fix this by hardocding a sane minumum size, but letting the labels be set larger when a theme requires it (say to accomodate a large or bold font). I had originally hardcoded in my summer 2015 kludge to make the labels show up at all because the original function to get the width that worked with GTK2 was always returning zero width in GTK3.
We've just has another user report of this mate-desktop/mate-panel#658
Closed it as a duplicate and against the wrong package. Since we seem to have a working fix we should merge it and not let this one fall by the wayside.