Dunst: 外部资源颜色

创建于 2017-08-10 · 27评论 · 资料来源: dunst-project/dunst

我仅凭标题的意思可能很明显。
把它写成一个完整的句子，我很乐意在配置中使用/引用 Xresource 颜色。

我使用pywal生成一个调色板，并且暂时使用包装脚本来启动应用所有颜色的 dunst。
这我想摆脱。

Feature

资料来源

tadly

👍11

最有用的评论

对于pywal用户：我通过将dunstrc编写为用户模板文件并将生成的缓存文件符号链接到~/.config/dunst/dunstrc解决了这个问题。

这是 pywal 的一个新功能，在打开此问题时不可用。

donovanglover 于 2018-10-25

❤10

所有27条评论

Dunst 目前不是 Xorg 特定的，因此这实际上意味着维护两个配置源，其中一个是编译时可选的。 😕

WhyNotHugo 于 2017-08-10

手掌
我什至记得在我关注的其他一些问题中读到了关于 dunst 不是 xorg 特定的。
完全忘记了这一点。

作为自己的开发人员，我看到这可能/可能会变得多么“丑陋”......
...作为用户，我想要一个中心点来配置我的调色板而无需黑客攻击。

让头脑风暴开始吧！到目前为止……什么都没有。

tadly 于 2017-08-10

嗨，我通常不评论 dunst 问题，我只是关注它们，因为我使用并且非常喜欢 dunst！
Xresource 的颜色是否来自以下内容：
/usr/share/X11/rgb.txt
你是说颜色名称吗？由于这些颜色名称（尽管 X11 特定的也用于网络），因此支持这将是有意义的。
这是我使用的一个函数......

#include <X11/Xlib.h>
///etc...
std::string x_color_from_name(const char *colorName){
        Display *dpy;
        Colormap map;
        int scr;
        XColor rgb, nearest_rgb;
        dpy = XOpenDisplay(NULL);
        scr = XDefaultScreen(dpy);
        map = DefaultColormap(dpy, scr);
        XLookupColor(dpy, map, colorName, &rgb, &nearest_rgb);
        int red = (int)rgb.red>>8;
        int green = (int)rgb.green>>8;
        int blue = (int)rgb.blue>>8;
        char tmp[8];
        std::snprintf(tmp, sizeof(tmp), "#%02x%02x%02x", red, green, blue);
        std::string output = tmp;
        return output;
}

ghost 于 2017-08-10

只需在 makefile 中搜索 Xlibs，并设置一些定义，然后将函数包装在该定义中

#ifdef X_EXISTS
//function from above converted to c string
#endif

ghost 于 2017-08-10

你是说颜色名称吗？由于这些颜色名称（尽管 X11 特定的也用于网络），因此支持这将是有意义的。

不， @Tadly谈论的是完全不同的事情 - 能够从 .Xresources 文件自定义颜色，您谈论的是 X11 颜色值支持。

我反对使用 X11 来解析颜色值，因为如上所述，dunst 不是特定于 X11 的，我目前正试图将 X 代码与其余的绘图内容分离，并使其仅在使用 X 时才起作用将是一个功能和文档混乱。

在问题的实际主题上，添加对 Xresources 解析的支持，我同意@hobarrera 的观点，即拥有 2 个配置源和一个可选的配置源是丑陋的，但解决方法是将颜色设置为某个值来解析它外部资源。例如

background = "$xresources.bg"

Dunst.bg: #0000ff

对此有何看法？

tsipinakis 于 2017-08-11

@ Israel- @
我说的是在 .Xresources 文件中维护的颜色。

我喜欢这个提议。
这就是我能说的全部:)

据我所知， background和foreground是通常使用的，所以我们有：

Dunst.background: #0000ff
Dunst.foreground: #0000ff

Xresources 中的其他颜色通常使用通配符配置，因此也应该很容易访问（取决于课程的实现）

*color1: #0000ff
*.color1: #0000ff
...

tadly 于 2017-08-11

👍1

@Tadly @tsipinakis我明白了，在那种情况下，我必须同意@tsipinakis我们已经有了处理类似事情的 dunst 配置文件。您是否想将颜色配置移出 Xresources 文件？对于您的个人用例，您应该编写一个简单的脚本来生成您的 dunst 配置......使用

while read LINE
do
  case $LINE in
    Dunst.background:*)BACKGROUND="${LINE/*:}";;
## ETC
    *);;
  esac
done < "$X_RESOURCE_FILE_NAME"

然后你可以使用另一个类似的循环或永远有用的sed
然后将 chmod +x 脚本放入您的启动中（这取决于您使用的是 WM 还是 DE）
一旦它运行良好，就将其放入 contrib :smile:

ghost 于 2017-08-11

@Israel-抱歉花了这么长时间。
我已经有了 OP 中提到的解决方法。

这只是让生活更轻松的东西，因为 i3、polybar 等确实支持读取 Xresource 值，我认为让 dunst 也支持它可能很酷，不记得 dunst 不是特定于 Xorg 的。

tadly 于 2017-08-14

@Tadly你介意在这里放弃你的解决方法:)

我试图实现相同的目标，只是进入问题列表以找到此讨论。
我建议使命令在配置文件中可用。例如，我可以有以下内容：

frame_color = `xrdb -query all | grep *colorN | awk '{print $x}'`
# or
frame_color = $(same as above)

这不需要有两个不同的配置基础，因为用户将负责；e 将颜色提供给 dunst，同时他更容易这样做。

_我真的不知道让用户能够在配置中执行任意命令的能力有多糟糕/有多好。_

nhatzHK 于 2017-10-28

@nhatzHK _workaround_ 只是一个脚本，以 cli 标志开始 dunst，但你去吧:)

#!/usr/bin/env bash

source "${HOME}/.cache/wal/colors.sh"

/usr/bin/dunst \
    -lb "${color0:-#F0F0F0}" \
    -nb "${color0:-#F0F0F0}" \
    -cb "${color0:-#F0F0F0}" \
    -lf "${color15:=#000000}" \
    -bf "${color15:=#000000}" \
    -cf "${color15:=#000000}" \
    -nf "${color15:=#000000}"

tadly 于 2017-10-28

我真的不知道让用户能够在配置中执行任意命令的能力有多糟糕/有多好。

我认为这是一个值得考虑的想法，如果有的话，它将允许在配置中进行更多自定义。不过，我也不确定这对安全的影响。

该解决方法只是一个以 cli 标志启动 dunst 的脚本，但您可以这样做:)

如果您不知道随着这些标志被弃用，此解决方法可能很快就会消失，请参阅 #328

tsipinakis 于 2017-10-28

如果您不知道随着这些标志被弃用，此解决方法可能很快就会消失，请参阅 #328

哇你要杀了我！ ':D
猜猜我将不得不开始生成配置文件或其他东西。
谢谢你让我知道:)

tadly 于 2017-10-28

我真的不知道让用户能够在配置中执行任意命令的能力有多糟糕/有多好。

我认为这是一个值得考虑的想法，如果有的话，它将允许在配置中进行更多自定义。不过，我也不确定这对安全的影响。

如果能够使用 STDIN 中的配置呢？

像这样：

#!/bin/sh

get_color(){
echo '#hex_val' and so on.
}

dunst -config - <<-END
[global]
frame_color = $(get_color frame)

END

你只限于外壳，你不必实现任何令人毛骨悚然的东西。当文件名是-时，执行读取 STDIN 就足够

无论如何，我提出另一个问题：地平线上出现了wayland，并且在 Ubuntu 17.10/18.04 中它获得了很大的推动力。实现这样的 X11 特定功能实际上值得吗？

bebehei 于 2017-10-28

很抱歉发布此问题，但我真的相信这将是一个杀手级功能，我不同意我们应该仅仅因为 Wayland 就将其传递下去，X11 不会因为 Wayland 变得更加稳定而神奇地消失。 .. 此外，除了将其限制为解析 xrdb 值之外，还可以解析配置本身的值......就像 polybar 配置系统一样，这太棒了，也是 TOML 一样，只有惊人的${}具有某种解析引擎来替换值的语法，没有任意代码。

samuelhnrq 于 2017-12-22

@samosaara我知道 Xorg 不会很快消失，但鉴于 dunst 支持 Xorg 和 wayland 意味着它不能_just_支持 Xorg，因此，需要保留当前的配置机制。

添加特定于 Xresources 的代码的问题是，增加了阅读配置的_很多_复杂性（并且基本上重复了相关代码的数量）。这不仅仅是实现的额外工作，也是未来维护和调试的工作。

WhyNotHugo 于 2017-12-22

@samosaara您不是在发布问题。我们重视对此的任何合理意见。 @WhyNotHugo给出了一个很好的解释，为什么我们不愿意添加任何 X11 特定的东西（以及 Wayland 特定的）。

我想知道为什么没有人回答我通过 STDIN 添加配置文件的建议，它为您提供了 shell 的全部功能，而无需在 dunst 中实现任何令人毛骨悚然的东西。

bebehei 于 2017-12-23

好吧，我相信不支持 xrdb 只是不完全支持 Xorg，只是部分支持，我理解试图保持显示服务器不可知，但您必须了解它们中的每一个都有自己的特殊性。

而且我实际上花时间研究了您关于复杂性的主张，我只是相信事实并非如此，无论如何，因为它已经被使用了，XLib 提供了一堆方法来轻松处理 X 资源（此处）。它实际上是加载当前 Xrdb 的单个方法调用（具有显示实例），也是读取任何值的单个其他方法。大约 20 行在这里添加这样的方法调用一些简单的解析（例如以$开头的值）并从 X 资源数据库中读取它。

如果你不想实现它，因为它会感觉 Wayland 方面缺少功能，当然，（即使，无论如何，Xwayland 不实现它？）但是

增加了很多复杂性（并且基本上复制了相关的数量增加了很多复杂性（并且基本上复制了相关代码的数量）

事实并非如此。

samuelhnrq 于 2017-12-23

大约 20 行在这里添加这样的方法调用一些简单的解析（例如以$开头的值）并从 X 资源数据库中读取它。

那是行不通的，那时 dunst 甚至还没有连接到 X 服务器，我们需要阅读配置以了解调用x_setup()所需的一切。虽然它可以分解成更小的部分，但它使代码复杂化了很多，而且它向配置解析器添加了 X11 特定代码的直接依赖，这将使得禁用 X11 的编译时选项在支持wayland 后更难实现添加。

tsipinakis 于 2017-12-23

如何提供读取 dunst 配置文件中另一个文件内容的能力。对于 X，您拥有存储某些内容的文件，您可以使用xrdb获取该信息（我想我之前说过）。它不必是 X 或 Wayland 特定的，因为您只是在阅读文件。类似的东西：

frame_color = xrdb -query all | grep *color7 | awk '{print $x}'

现在唯一要实现的是检测某些字符（在本例中为``）并特别处理它们内部的内容（在本例中为shell命令）。

如果您想从 STDIN 指定值，这也将起作用，因为其他程序（如 cat）已经支持-作为从 STDIN 读取的标识符。
Polyabr 对background = ${xrdb:color7}方式有所不同（但以更特定的方式），由于您之前所述的原因，您可能不会喜欢那个。

无论如何，我认为在配置文件中具有更大的灵活性是一件好事。例如，我在多台机器上使用相同的配置文件，我依靠这样的小东西使它们在任何机器上都能正常工作。此外，例如，如果您更改颜色方案，则不必通过每个配置文件来更新每种颜色是一个加号 imo。

我不知道这会增加多少复杂性，因为我不熟悉代码库。我相信这是一个很好的（便携式）替代方案。

nhatzHK 于 2017-12-23

👍3

FWIW，您不能编写一个脚本来读取 Xresources 值并输出有效的dunst配置文件吗？这听起来简单得多，并且不需要对dunst本身进行任何更改。

WhyNotHugo 于 2017-12-24

Hugo 的想法是合理的，再一次，在 Xlib XrmDatabase XrmGetFileDatabase(char *filename);有一种方法可以做到这一点，但这有点阴暗，因为这个人可能有一个非默认的 xresources 文件名，em 的倍数，等等。所以，我认为更聪明的仍然是解析 xrdb 的输出，它为我们做了所有繁重的工作。

samuelhnrq 于 2017-12-24

大家好。 @lulivi创建了 #525，声称可以解决此问题。在我看来，代码看起来非常好，但我还没有测试脚本的功能。我没有使用 Xresource 文件。如果你们中的任何人有兴趣加速解决此问题，请测试 PR #525 并在那里提供反馈。你会帮我们所有人的忙。提前致谢。

bebehei 于 2018-07-02

👍2

对于pywal用户：我通过将dunstrc编写为用户模板文件并将生成的缓存文件符号链接到~/.config/dunst/dunstrc解决了这个问题。

这是 pywal 的一个新功能，在打开此问题时不可用。

donovanglover 于 2018-10-25

❤10

嘿@GloverDonovan你介意举个例子吗？

annata83 于 2019-01-09

我将继续分享我从 Xresources 获取颜色信息的 hacky 方法，因为似乎没有人会做我所做的。

我将主要的 dunst 配置保留在其配置文件中，并在命令行参数中设置颜色。我使用一个名为xgetres的小程序查询 X 的颜色。

dunst -config ~/.config/dunst/dunstrc \
  -cb "$(xgetres background)" \
  -lb "$(xgetres background)" \
  -nb "$(xgetres background)" \
  -cf "$(xgetres foreground)" \
  -lf "$(xgetres foreground)" \
  -nf "$(xgetres foreground)" \
  -bf "$(xgetres foreground)" \
  -frame_color "$(xgetres foreground)"

这种方法的缺点是，如果 dunst 是由调用notify-send _before_ 的程序启动的，我手动启动它，它将以默认颜色启动，我必须手动重新启动它。

douglasrizzo 于 2020-07-15

👍2

@annata83这里是一个示例模板！如果您有默认评论，请注意：

    # The geometry of the window:
    #   [{{width}}]x{{height}}[+/-{{x}}+/-{{y}}]

您必须使用双 {} 转义{width}才能使 pywal 正常工作。

lulivi 于 2020-07-15

👀1 ❤1

我将继续分享我从 Xresources 获取颜色信息的 hacky 方法，因为似乎没有人会做我所做的。
我将主要的 dunst 配置保留在其配置文件中，并在命令行参数中设置颜色。我使用一个名为xgetres的小程序查询 X 的颜色。
dunst -config ~/.config/dunst/dunstrc \
  -cb "$(xgetres background)" \
  -lb "$(xgetres background)" \
  -nb "$(xgetres background)" \
  -cf "$(xgetres foreground)" \
  -lf "$(xgetres foreground)" \
  -nf "$(xgetres foreground)" \
  -bf "$(xgetres foreground)" \
  -frame_color "$(xgetres foreground)"
这种方法的缺点是，如果 dunst 是由调用notify-send _before_ 的程序启动的，我手动启动它，它将以默认颜色启动，我必须手动重新启动它。

谢谢！我能够稍微修改它以解决您提到的手动重启问题。

第一个问题是需要停止任何以前的 dust 实例。

第二个问题是在运行 dunst 时读取 Xresource 值引入了延迟，这将允许另一个程序在它被杀死和尝试重新启动之间再次启动 dunst（使用通知发送）。

我的版本通过首先获取 Xresources 值来解决这个问题，然后杀死任何 dunst 实例并同时重新启动它。见下文。

#!/bin/bash

# Get values from Xresources
config=~/.config/dunst/dunstrc
geometry_x=$(xgetres dunst.geometry-x)
geometry_y=$(xgetres dunst.geometry-y)
separator_height=$(xgetres dunst.sep-height)
padding=$(xgetres dunst.padding)
horizontal_padding=$(xgetres dunst.horiz-padding)
max_icon_size=$(xgetres dunst.max-icon-size)
frame_width=$(xgetres dunst.frame-width)
lb=$(xgetres dunst.low-background)
lf=$(xgetres dunst.low-foreground)
lfr=$(xgetres dunst.low-frame)
nb=$(xgetres dunst.normal-background)
nf=$(xgetres dunst.normal-foreground)
nfr=$(xgetres dunst.normal-frame)
cb=$(xgetres dunst.critical-background)
cf=$(xgetres dunst.critical-foreground)
cfr=$(xgetres dunst.critical-frame)

# Kill and running dunst instances and start
killall dunst;/usr/bin/dunst -config $config \
    -geometry "0x0-$geometry_x+$geometry_y" \
    -separator_height "$separator_height" \
    -padding "$padding" \
    -horizontal_padding "$horizontal_padding" \
    -max_icon_size "$max_icon_size" \
    -frame_width "$frame_width" \
    -lb "$lb" \
    -lf "$lf" \
    -lfr "$lfr" \
    -nb "$nb" \
    -nf "$nf" \
    -nfr "$nfr" \
    -cb "$cb" \
    -cf "$cf" \
    -cfr "$cfr"

balajsra 于 2021-02-27

👍1

此页面是否有帮助？

0 / 5 - 0 等级

Dunst: 外部资源颜色

最有用的评论

所有27条评论

相关问题