发表文章

[C] cpufreq-小程序: 频率/单位标签呈现部分或根本不 cpufreq-applet: freq/units labels render partially or not at all[mate-applets]

dwtokarski 2017-10-9 65

预期行为

放置在面板上的 cpufreq 小程序应完全呈现并保持不变。

实际行为

几乎总是, 单位标签上的最后一列或两个像素丢失 (例如, Mhz 中的 z 缺少右侧)。

较少经常, 更多或所有单位标签完全地是缺掉的;同样为频率标签。在更罕见的情况下, 小程序根本不渲染, 虽然它的真正存在的悬停在其已知的位置将弹出的工具提示, 左键单击打开频率/州长菜单, 等等。

我有理由认为, 完全失败的渲染是一个单独的问题, 从标签截断行为。

重现行为的步骤

不需要特殊操作。只需登录到一个面板上有一个或多个 cpufreq applet 的桌面。也可以在从暂停或任何随机时刻恢复后发生。

大副通用版

1.18.0 目前, 虽然这已经发生, 因为至少1.16.x。

包版本

目前的队友-小程序-1.18.1-1. fc26 x86_64, 但看到上述。

Linux 发行版

Fedora 25, 26

链接到您的配送的下游报告

还没有

建议的修补程序

下面的修补程序解决了部分标签问题。我已经运行了几天, 这似乎是固体。

问题似乎出现在 cpufreq 的小程序中. get_max_ 在哪里?_width 例程试图通过将文本插入新分配的 GtkLabel 并调用 gtk_widget_get_preferred_width () 来查找各种字符串的像素宽度, 这只返回零结果。野生猜测: 独立的 GtkLabel 没有相关的字体, 所以宽度不能确定。 在某种程度上, 有人认为最好是得到的小程序 > 标签的宽度, 但他们没有初始化, 谁知道该对象的字符串指针指向。大量不同的值是从时间返回的, 第一次获得正值时, 它就成为该标签在 * 小程序中的粘滞宽度。

通过在小程序的标签中放置字符串值, 然后获得首选的宽度, 补丁就得到了这一点。

diff -ur ../mate-applets-1.18.1-ORIG/cpufreq/src/cpufreq-applet.c ./cpufreq/src/cpufreq-applet.c
 --- ../mate-applets-1.18.1-ORIG/cpufreq/src/cpufreq-applet.c   2017-04-06 15:02:40.000000000 -0400
 +++ ./cpufreq/src/cpufreq-applet.c     2017-08-20 16:05:37.056044732 -0400
 @@ -292,7 +292,6 @@
  cpufreq_applet_get_max_label_width (CPUFreqApplet *applet)
  {
        GList *available_freqs;
 -      gint   width = 0;
  
        if (applet->max_label_width > 0)
                return applet->max_label_width;
 @@ -302,7 +301,6 @@
  
        available_freqs = cpufreq_monitor_get_available_frequencies (applet->monitor);
        while (available_freqs) {
 -              GtkWidget     *label;
                gint           label_width;
                const gchar   *text;
                gchar         *freq_text;
 @@ -312,34 +310,26 @@
                freq = atoi (text);
  
                freq_text = cpufreq_utils_get_frequency_label (freq);
 -              label = gtk_label_new (freq_text);
 +              gtk_label_set_text (GTK_LABEL (applet->label), freq_text);
                gtk_widget_get_preferred_width (applet->label, &label_width, NULL);
 -              width = MAX (width, label_width); 
 +              applet->max_label_width = MAX (applet->max_label_width, label_width);
  
                g_free (freq_text);
 -              gtk_widget_destroy (label);
  
                available_freqs = g_list_next (available_freqs);
        }
  
 -      applet->max_label_width = width;
 -
 -      return width;
 +      return applet->max_label_width;
  }
  
  static gint
  cpufreq_applet_get_max_perc_width (CPUFreqApplet *applet)
  {
 -      GtkWidget      *label;
 -      gint            width;
 -
        if (applet->max_perc_width > 0)
                return applet->max_perc_width;
  
 -      label = gtk_label_new ("100%");
 -      gtk_widget_get_preferred_width (applet->label, &width,&width);
 -      applet->max_perc_width = width +20; /*for some reason width always comes up 2 characters*/
 -      gtk_widget_destroy (label);
 +      gtk_label_set_text (GTK_LABEL (applet->label), "100%");
 +      gtk_widget_get_preferred_width (applet->label, &applet->max_perc_width, NULL);
  
        return applet->max_perc_width;
  }
 @@ -347,20 +337,19 @@
  static gint
  cpufreq_applet_get_max_unit_width (CPUFreqApplet *applet)
  {
 -      GtkWidget     *label;
 -      gint           w1, w2;
 +      gint           mwidth;
  
        if (applet->max_unit_width > 0)
                return applet->max_unit_width;
  
 -      label = gtk_label_new ("GHz");
 -      gtk_widget_get_preferred_width (applet->label, &w1, NULL);
 +      gtk_label_set_text (GTK_LABEL (applet->unit_label), "GHz");
 +      gtk_widget_get_preferred_width (applet->unit_label, &applet->max_unit_width, NULL);
  
 -      gtk_label_set_text (GTK_LABEL (label), "MHz");
 -      gtk_widget_get_preferred_width (applet->label, &w2, NULL);
 +      gtk_label_set_text (GTK_LABEL (applet->unit_label), "MHz");
 +      gtk_widget_get_preferred_width (applet->unit_label, &mwidth, NULL);
 +
 +      applet->max_unit_width = MAX (applet->max_unit_width, mwidth);
  
 -      gtk_widget_destroy (label);
 -      applet->max_unit_width = MAX (w1, w2)-1;
        return applet->max_unit_width;
  }
  
 @@ -757,6 +746,20 @@
          guint        cpu;
          const gchar *governor;
  
 +        /* Call refresh only the first time.
 +         *
 +         * Because the label width determinations now modify the actual labels
 +         * in *applet to size the max label width in pixels, do this first
 +         * before setting the label text below.
 +         */
 +        if (applet->need_refresh) {
 +                gint w;
 +
 +                cpufreq_applet_get_preferred_width(applet, &w, &w);
 +                cpufreq_applet_refresh (applet);
 +                applet->need_refresh = FALSE;
 +        }
 +
          cpu = cpufreq_monitor_get_cpu (monitor);
          freq = cpufreq_monitor_get_frequency (monitor);
          perc = cpufreq_monitor_get_percentage (monitor);
 @@ -810,12 +813,6 @@
                gtk_widget_set_tooltip_text (GTK_WIDGET (applet), text_tip);
                g_free (text_tip);
        }
 -
 -        /* Call refresh only the first time */
 -        if (applet->need_refresh) {
 -                cpufreq_applet_refresh (applet);
 -              applet->need_refresh = FALSE;
 -        }
  }
  
  static gint
~
原文:

Expected behaviour

A cpufreq applet placed on the panel should render completely and remain so.

Actual behaviour

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.

Package version

Currently mate-applets-1.18.1-1.fc26.x86_64 but see above.

Linux Distribution

Fedora 25, 26

Link to downstream report of your Distribution

None yet.

Proposed Patch

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.

diff -ur ../mate-applets-1.18.1-ORIG/cpufreq/src/cpufreq-applet.c ./cpufreq/src/cpufreq-applet.c
 --- ../mate-applets-1.18.1-ORIG/cpufreq/src/cpufreq-applet.c   2017-04-06 15:02:40.000000000 -0400
 +++ ./cpufreq/src/cpufreq-applet.c     2017-08-20 16:05:37.056044732 -0400
 @@ -292,7 +292,6 @@
  cpufreq_applet_get_max_label_width (CPUFreqApplet *applet)
  {
        GList *available_freqs;
 -      gint   width = 0;
  
        if (applet->max_label_width > 0)
                return applet->max_label_width;
 @@ -302,7 +301,6 @@
  
        available_freqs = cpufreq_monitor_get_available_frequencies (applet->monitor);
        while (available_freqs) {
 -              GtkWidget     *label;
                gint           label_width;
                const gchar   *text;
                gchar         *freq_text;
 @@ -312,34 +310,26 @@
                freq = atoi (text);
  
                freq_text = cpufreq_utils_get_frequency_label (freq);
 -              label = gtk_label_new (freq_text);
 +              gtk_label_set_text (GTK_LABEL (applet->label), freq_text);
                gtk_widget_get_preferred_width (applet->label, &label_width, NULL);
 -              width = MAX (width, label_width); 
 +              applet->max_label_width = MAX (applet->max_label_width, label_width);
  
                g_free (freq_text);
 -              gtk_widget_destroy (label);
  
                available_freqs = g_list_next (available_freqs);
        }
  
 -      applet->max_label_width = width;
 -
 -      return width;
 +      return applet->max_label_width;
  }
  
  static gint
  cpufreq_applet_get_max_perc_width (CPUFreqApplet *applet)
  {
 -      GtkWidget      *label;
 -      gint            width;
 -
        if (applet->max_perc_width > 0)
                return applet->max_perc_width;
  
 -      label = gtk_label_new ("100%");
 -      gtk_widget_get_preferred_width (applet->label, &width,&width);
 -      applet->max_perc_width = width +20; /*for some reason width always comes up 2 characters*/
 -      gtk_widget_destroy (label);
 +      gtk_label_set_text (GTK_LABEL (applet->label), "100%");
 +      gtk_widget_get_preferred_width (applet->label, &applet->max_perc_width, NULL);
  
        return applet->max_perc_width;
  }
 @@ -347,20 +337,19 @@
  static gint
  cpufreq_applet_get_max_unit_width (CPUFreqApplet *applet)
  {
 -      GtkWidget     *label;
 -      gint           w1, w2;
 +      gint           mwidth;
  
        if (applet->max_unit_width > 0)
                return applet->max_unit_width;
  
 -      label = gtk_label_new ("GHz");
 -      gtk_widget_get_preferred_width (applet->label, &w1, NULL);
 +      gtk_label_set_text (GTK_LABEL (applet->unit_label), "GHz");
 +      gtk_widget_get_preferred_width (applet->unit_label, &applet->max_unit_width, NULL);
  
 -      gtk_label_set_text (GTK_LABEL (label), "MHz");
 -      gtk_widget_get_preferred_width (applet->label, &w2, NULL);
 +      gtk_label_set_text (GTK_LABEL (applet->unit_label), "MHz");
 +      gtk_widget_get_preferred_width (applet->unit_label, &mwidth, NULL);
 +
 +      applet->max_unit_width = MAX (applet->max_unit_width, mwidth);
  
 -      gtk_widget_destroy (label);
 -      applet->max_unit_width = MAX (w1, w2)-1;
        return applet->max_unit_width;
  }
  
 @@ -757,6 +746,20 @@
          guint        cpu;
          const gchar *governor;
  
 +        /* Call refresh only the first time.
 +         *
 +         * Because the label width determinations now modify the actual labels
 +         * in *applet to size the max label width in pixels, do this first
 +         * before setting the label text below.
 +         */
 +        if (applet->need_refresh) {
 +                gint w;
 +
 +                cpufreq_applet_get_preferred_width(applet, &w, &w);
 +                cpufreq_applet_refresh (applet);
 +                applet->need_refresh = FALSE;
 +        }
 +
          cpu = cpufreq_monitor_get_cpu (monitor);
          freq = cpufreq_monitor_get_frequency (monitor);
          perc = cpufreq_monitor_get_percentage (monitor);
 @@ -810,12 +813,6 @@
                gtk_widget_set_tooltip_text (GTK_WIDGET (applet), text_tip);
                g_free (text_tip);
        }
 -
 -        /* Call refresh only the first time */
 -        if (applet->need_refresh) {
 -                cpufreq_applet_refresh (applet);
 -              applet->need_refresh = FALSE;
 -        }
  }
  
  static gint
~
相关推荐
最新评论 (15)
flexiondotorg 2017-10-9
1

请您提交您的补丁作为拉请求

原文:

Please can you submit your patch as a pull request

dwtokarski 2017-10-9
2

当然, 这不是问题, 但我要花点事情来设置它。

我应该基于 v1.18.1, 还是你更喜欢别的?

原文:

Sure, not a problem, but it'll take me a bit to set it up.

Should I base off of v1.18.1, or would you prefer something else?

raveit65 2017-10-9
3

请高手。

原文:

To master please.

lukefromdc 2017-10-9
4

我只是测试了一下, 发现它并不总是工作。通常我没有得到这个 bug, 无论是与主和此代码, 我试图改变不同的主题, 有时会调用它在 BlackMATE。一次又一次, 在更改回我自己的主题后重新启动面板时, 我在 GHz 中得到一个截断的 z。
applet_w_cutoff_units

我的主题使用粗体文本, 这导致小程序跳转, 直到我将其添加到它:

/*Stop jumping cpufreq labels with bold text*/
#PanelApplet>widget>box>box>label{
	min-width: 35px;
}

无论有和没有这一点, 我曾在过去的问题, 以截断 z 改变回我的主题, 有时在机器和内核, 将最初返回 "0GHZ" 作为价值, 我会得到一个截短的小程序。这是最坏的一个有一个800MHZ 的闲置速度, 和相同的修复, 为跳跃与大胆的测试, 把停止, 截断。现在, 我看到一个单独的、被截断的标签的实例, 即使是最小的宽度集, 也不知道这是怎么可能的。

原文:

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.
applet_w_cutoff_units

My theme uses bold text, which caused the applet to jump until I added this to it:

/*Stop jumping cpufreq labels with bold text*/
#PanelApplet>widget>box>box>label{
	min-width: 35px;
}

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.

raveit65 2017-10-9
5

@dwtokarski
你看到这个问题的主题是什么?
我将尝试重现它。

原文:

@dwtokarski
With which theme(s) you saw the issue?
...i will try to reproduce it.

dwtokarski 2017-10-9
6

@raveit65
BlueMenta 控件与 Bluebuntu 窗口边框, 以及 Bluecurve 图标和指针。

由于小程序在标签上所获得的第一个正宽值的方式, 您可以通过在面板中添加 cpufreq 的 applet 来最好地解决问题。如果一个结果被截断, 任何其他已经存在的都应该不受影响。杀了小组的工作。

@lukefromdc
你的观察是意料之中的。当小程序被实例化时, 标签宽度仅确定一次, 想必使用当前配置的任何字体和存储的像素宽度。以后将使用被存放的价值, 虽然在一些以后调试今天它出现那些宽度从未再被询问无论如何, 即使当字体被改变了。 一般来说, 我希望你做的任何事情, 使字体更大-主题更改, 字体大小-比当小程序实例化时可能会导致截断。

因此, 今天我尝试从所有的 cpufreq_applet_get_max_XXXX_width () 过程中删除现有正宽的检查。我还删除了 cpufreq_applet_update () 中的小程序 > need_refresh 标志的检查。 我希望做的是在每次标签内容更改时强制重新确定标签的宽度, 包括字体更改。我想, 每一次 cpufreq_applet_refresh () 调用都会使标签不被截断。 但不, 我只看到@lukefromdc描述的内容。 哦, 有些 (联合国?相关的, 我觉得这真的很奇怪, 在面板上没有渲染任何斜体字体。

我的问题是, 我还不够了解 gtk+, 了解如何使更新的小部件属性呈现可见的情况。 更多的调试是有序的。

你可能想把它拖到这一拉, 直到这个被整理出来。 好像我们很亲近

原文:

@raveit65
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.

@lukefromdc
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.

raveit65 2017-10-9
7

好的, 心理的主题是我们的默认, 我喜欢使用它。:-)
所以我可以测试这几天来重现这个问题。
4芯的小程序。

原文:

Ok, Menta themes are our default and i like to use it. :-)
So i can test this several days to reproducing the issue.
....with applets for 4 cores.

monsta 2017-10-9
8

我不能重现它, 但我发现300ef94可能与此相关。
因此, 它总是调用 gtk_widget_get_preferred_width on applet->label , 而本地标签变量只是创建和销毁, 但不使用。

我在#269中看到它更改为修改 applet->labelcpufreq_applet_get_max_xxx_width函数应该具有副作用吗?

原文:

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?

lukefromdc 2017-10-9
9

我们可以通过 hardocding 一个正常的最小大小来解决这个问题, 但是当主题需要时, 让标签更大一些 (比方说, 可以容纳大号或粗体字体)。 我原本硬编码在我的夏天2015组装, 使标签出现在所有, 因为原来的功能, 以获得宽度, 与 GTK2 的工作总是返回零宽度在 GTK3。

原文:

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.

monsta 2017-10-9
10

那太糟了我只是测试它和 gtk_widget_get_preferred_width 确实返回零, 当调用的小部件, 这是不可见的 (这是真实的那些本地标签变量)。

原文:

Well, that sucks. I just tested it and gtk_widget_get_preferred_width indeed returns zero when called on a widget that's not visible (which is true for those local label variables).

monsta 2017-10-9
11

不知道发生了什么事在 gnome-倒叙/侏儒-面板。它们仍然具有该代码 (请参见此处)。

原文:

Wonder what's going on in gnome-flashback/gnome-panel. They still have that code (see here).

monsta 2017-10-9
12

好的, 我找到了一种方法来获取不可见标签的宽度。检查#272的人。

原文:

Ok, I've found an alternative way to get the width of an invisible label. Check #272 guys.

lukefromdc 2017-10-9
13

#272不起作用, 给了我有史以来最严重的截断问题

原文:

#272 did not work, gave me the worst truncation problems ever

monsta 2017-10-9
14

已在新提交中添加了对#272的可能修复。

还添加了#274以在增加配对外观属性时修复截断问题。这是一个单独的问题, 修复程序也可以单独应用。

原文:

Added possible fix to #272 in a new commit.

Also added #274 to fix truncation issue when you increase font size in mate-appearance-properties. It's a separate issue, and the fix can be applied separately as well.

lukefromdc 2017-10-9
15

我们刚刚有另一个用户报告
mate-desktop/mate-panel#658
关闭它作为一个副本和反对错误的包。因为我们似乎有一个工作的解决办法, 我们应该合并它, 而不是让这一下降半途而废。

原文:

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.

返回
发表文章
dwtokarski
文章数
1
评论数
2
注册排名
60624