依云's Blog

前些天尝试了一下 KDE 桌面环境，不过实在是没能用下去。

首先要说的是，KDE 桌面确实漂亮，非常养眼。设置项也挺多，可定制性还是挺不错的。只可惜问题同样很多。

首先是显示器缩放的问题。受限于 X11，KDE 只能设置一下全局的缩放比例。所以我们只好缩放显示器显示的画面。不幸的是，一向相当体贴的 KDE 此时却笨笨的，在使用 xrandr 设置好之后需要重启 plasmashell 来使其获取 xrandr 的设置更新：

kquitapp5 plasmashell && kstart5 plasmashell

KDE 的设置项很多，分门别类地在「设置」应用程序中集中列出来，然而问题也由此产生：同时只会显示一个「设置」窗口。也就是说，我配置快捷键时，想去窗口管理器那边看一看，调整一点选项，就必须放弃我当前打开的快捷键视图，放弃我键入的搜索词，并且选择「应用」或者「放弃」更改，才能切换到另一个「设置」组件中去。即使从 krunner 里打开某个组件的设置，它也会找到并更新已有的窗口。

我知道 Windows 10 也是这么个「单任务」设置的风格。可 Windows 10 也没有这么多可以设置的地方呀。后来获知有个命令可以打开单独组件的设置窗口。很不方便。它被隐藏起来的原因是这种窗口不能返回到组件列表界面，会让用户困惑。可是，为什么我不能同时打开「设置」的不同组件的多个窗口？单独组件的窗口会让用户困惑，那就不要用单独组件的窗口就好了嘛。

KDE 桌面还有个问题：启动特别慢。登录进入界面要好久，启动一个程序，它的图标也要跳好久窗口才会出现。不知道它在干什么。我甚至怀疑它是为了展示启动动画而故意推迟界面的显示。

KDE 有提供丰富的桌面部件。我往副显示器上放了一些系统状态的监视器——CPU、磁盘、网络啥的。然后问题来了：我凑齐了四个部件刚好形成2x2的网格，可是我要怎么对齐它们呢？并没有对齐的选项，也没有吸附的功能。在我找到它使用的配置文件并手动修改之前，我只能用肉眼瞅。可计算机不就是用来做这种人不擅长而机器擅长的事情的吗？

终端我还是用 GNOME Terminal，因为有些特性（比如超链接）只有它支持。但又出现问题了：它启动之后，pin 它的任务图标，或者通过任务栏图标创建新实例均会失败。把它 pin 到任务栏上，需要从主菜单的右键菜单里操作。即使这样，启动之后终端窗口还是会位于新的图标，旧图标还是不对应任何窗口。后来查了一下，GNOME 的东西都没有主动支持启动通知，导致 KDE 很多时候只能猜测，而这次它猜错了。解决的办法是给 GNOME Terminal 的 .desktop 文件加上正确的 StartupWMClass 项。这其实不是 KDE 的问题，但也没办法。KDE 不想为别人擦屁股，GNOME 不在意自己的软件在别的桌面上的可用性。

不过 Qt 写的 flameshot 我就不知道是怎么回事了。具体情况不记得了，反正就是显示异常。好像是全黑吧。我没来得及 debug 这个。

最后，让我决定放弃 KDE 的点来了：我设置不了我需要的窗口管理快捷键。

切换窗口，默认是 Alt-tab 的那个，我好不容易在「快捷键」设置里找到了添加更多快捷键的方式，但我发现除了 Alt-tab，我自定义的都不能连续切换窗口。按一下，切换一下，然后就切不动了，只能放开快捷键。后来了解到这是设置更新方面的问题，kwin_x11 --replace一下就有效了。

切窗口其实问题不大。问题大的是切显示器屏幕。两个功能：一、把焦点切到另一个屏幕；二、把当前窗口移到另一个屏幕上。

前者可以勾选「分隔屏幕焦点」选项，然后调整一下「阻止盗取焦点」的级别。我也不知道这个级别都是啥意思。「无」我能理解，「低」「中」「高」「终极」都是些啥？反正调整一下，确实可以把窗口焦点切换到另一个屏幕去了，除了鼠标不会跟着过去！另外测试过程中，有时候焦点会丢失——我不知道当前什么窗口获得了焦点，也不知道接下来谁会获得焦点。比 Mac OS X 里焦点跑到一个窗口也没有的 Finder 上还要神秘。

不过这个倒是可以自己写个脚本解决：使用 xrandr 获取屏幕的大小和位置，通过 X 的接口获取鼠标的位置并通过 Xtest 扩展来移动它，然后再用某个 X 的接口去设置窗口焦点——完全绕过 KDE 的功能。

然后我被另一个问题难住了——我怎么把窗口移到另一个屏幕上并且把焦点也移过去呢？使用文档匮乏的 kwin script 是可以把窗口移过去，然后我没能找到移动鼠标光标的 API。通过 X 是可以移窗口的同时移鼠标，但是我拿不到带窗口装饰的窗口位置信息。kwin 有一个 getWindowInfo 的 D-Bus 接口，但是它接收的那个 UUID 参数，我没找到获取的方法。

总结一下，KDE 对快捷键的支持并没有想像的那么好，尤其是多显示器的支持。快捷键的设置是通过图形界面来操作的，虽然直观但是对于大量快捷键的管理来说非常困难。而对于大显示器来说，通过快捷键来管理窗口是十分必要的——因为我更难肉眼找到我的鼠标光标去了哪里。

接下来，我打算一边忍受着 Awesome 3.5.9 的旧与 bug，一边尝试将 i3 改造成我需要的样子。

i3 有个东西叫「scratchpad」，和我在 Awesome 里用的 run_or_raise 功能有些类似。

我的需求是某些浮动窗口可以「招之即来，挥之即去」。上次尝试切换 i3 遇到的一大麻烦就是，我经常从终端里启动图形界面的程序，而启动完之后我得手动给我的终端找个地方放着。i3 不支持最小化，也只有十个带数字快捷键、可以快速访问的工作区，所以 scratchpad 很重要，但是它的行为我有些捉摸不定。

首先是 move scratchpad 这个命令。它会把当前 con（窗口或者容器）浮动、取消全屏，然后移到一个叫 __i3_scratch 的不显示的工作区。

然后是 scratchpad show 命令（动词放后边了）。如果没有指定条件，它有如下复杂的处理逻辑：

• 检查当前窗口是不是去过 scratchpad。如果是，就把它丢回去。
• 否则检查当前工作区是否有另外的 scratchpad 窗口。如果有，就给它焦点。
• 否则检查其它工作区是否有另外的 scratchpad 窗口。如果有，就把它移过来。
• 否则把 __i3_scratch 里最久没有「见到光」的窗口移过来。

如果指定了条件，那么这样检查匹配的窗口：

• 如果窗口不曾去过 scratchpad，什么也不做。
• 否则如果窗口去过 scratchpad 并且在当前工作区，就隐藏它。
• 否则就把它移过去。

总结一下，就是「回去，或者回来」。虽然动作的名字叫「show」，但其实是一个类似于 toggle 的功能。它的麻烦之处在于：如果你有多个去过 scratchpad 的窗口，你很难控制出现的是哪个窗口。一个绕过这个问题的办法是，总是带条件地使用 scratchpad。另一个小麻烦是：没有办法在匹配的窗口已经显示的时候，不要把它隐藏掉——有时候我只是习惯性地呼叫我的终端，而不看它是不是已经在我面前了。

对于浮动窗口，i3 有很多奇怪的限制，或者说是未实现：

• 不支持最小化
• 浮动窗口也不能显示在平铺窗口之下（加上上一条，就是没办法暂时藏起来）
• 不支持最大化（手动调整窗口大小无法自动适配显示器大小，也没有「恢复」一说）
• 不支持显示在最上层（当你在 GIMP 里开了一堆图片需要局部对比时）
• 有全屏窗口时不能显示浮动窗口（看视频无法临时使用浮动窗口查个单词啥的）
• 切换窗口时，平铺窗口和浮动窗口是隔绝的（需要单独的快捷键来切换）

GitHub 用户页有个 calendar，花花绿绿的甚是好看。不过，经常一不小心断掉了几十天的 steak 着实可惜，特别是用了私有仓库之后，自己看，有贡献，可别人看不到那些私有贡献的呀。其实要维持 steak 也不难，一个小小的提交就足够了——只要我知道我今天还没 push 什么公开的东西的时候。

当然啦，写个脚本天天推个无意义的更新挺容易的，但那样就没有乐趣了不是吗？一天快结束的时候发封邮件提示一下自己不错，但可能已经来不及了。而且这种事情还是随意点好，太刻意了就不好玩了，所以不需要那么强的提醒。弄一个简单的指示器在 Awesome 面板上正好。

效果图（指示器在右上角）：

如果这天没有贡献（公开的提交或者 issue 等），那么这只 Octocat 就会失去色彩（变成灰度图）。

代码已上传至 myawesomerc 仓库。以下是实现细节：

首先，创建一个显示图片的 widget：

-- {{{ GitHub contribution indicator
github_contributed = awful.util.getdir("config") .. "/image/github_contributed.png"
github_not_contributed = awful.util.getdir("config") .. "/image/github_not_contributed.png"
github_widget = wibox.widget.imagebox()
function update_github(has_contributions)
    if has_contributions then
        github_widget:set_image(github_contributed)
    else
        github_widget:set_image(github_not_contributed)
    end
end
update_github(false)
-- }}}

-- 在 wibox 中添加这个 widget，需要放到正确的地方：
right_layout:add(github_widget)

函数update_github是给外部脚本用的。不可在 Awesome 配置里直接发起 HTTP 请求，会阻塞的！

当然，还要准备前两行代码提到的图片。从这里下载 Octocat 的图片，并做成彩色和灰度小图：

convert -resize 48x48 -background white -alpha remove Octocat.png github_contributed.png
convert -resize 48x48 -background white -alpha remove -colorspace Gray Octocat.png github_not_contributed.png

把图片放到相应的地方。然后写个脚本来更新这个指示器的状态，也就是获取数据之后再通过 awesome-client 调用update_github函数了。

#!/bin/bash -e

github_contributed () {
  count=$(curl -sS "https://github.com/users/$USER/contributions" | grep -oP '(?<=data-count=")\d+' | tail -1)
  [[ $count -gt 0 ]]
}

get_display () {
  if [[ -n "$DISPLAY" ]]; then
    return
  fi

  pid=$(pgrep -U$UID -x awesome)
  if [[ -z "$pid" ]]; then
    echo >&2 "awesome not running?"
    exit 1
  fi

  display=$(tr '\0' '\n' < /proc/"$pid"/environ | grep -oP '(?<=^DISPLAY=).+')
  if [[ -z "$display" ]]; then
    echo >&2 "can't get DISPLAY of awesome (pid $pid)"
    exit 2
  fi

  export DISPLAY=$display
}

get_display

if github_contributed; then
  s='true'
else
  s='false'
fi

echo "update_github($s)" | awesome-client

GitHub calender 目前是个 SVG 图片，位于https://github.com/users/用户名/contributions。

awesome-client 需要设置正确的DISPLAY环境变量才可以使用。这里使用pgrep取当前用户的 awesome 进程里的DISPLAY变量值。ps命令不太好用，不能同时指定多个条件。

万事俱备，只需要拿 cron 或者 systemd.timer 定时跑跑这个脚本就可以啦～

2015年3月14日更新：update_github脚本改用 Python 实现了，更好的错误处理（不会因为网络问题而认为今天没有贡献了），也改用当前日期而非 GitHub calender 的最后一个方块。更新后的脚本在 GitHub 上。

稍微了解一点类 UNIX 系统的进程管理的都知道，当一个进程的父进程死亡之后，它就变成了孤儿进程，会由进程号 1 的 init 进程收养，并且在它死亡时由 init 来收尸。但是，自从使用 systemd 来管理用户级服务进程之后，我发现 systemd --user 管理的进程总是在它之下，即使进程已经 fork 了好几次。systemd 是怎么做到的呢？

对一个软件的实现有不懂的想了解当然是读它的源码了。这种东西可没有另外的文档，因为源码本身即文档。当然之前我也 Google 过，没有得到结果。在又一个全新的源码树里寻寻觅觅一两天之后，终于找到了这个：

        if (arg_running_as == SYSTEMD_USER) {
                /* Become reaper of our children */
                if (prctl(PR_SET_CHILD_SUBREAPER, 1) < 0) {
                        log_warning("Failed to make us a subreaper: %m");
                        if (errno == EINVAL)
                                log_info("Perhaps the kernel version is too old (< 3.4?)");
                }
        }

原来是通过prctl系统调用实现的。于是去翻 prctl 的 man 手册，得知PR_SET_CHILD_SUBREAPER是 Linux 3.4 加入的新特性。把它设置为非零值，当前进程就会变成 subreaper，会像 1 号进程那样收养孤儿进程了。

当然用 C 写不好玩，于是先用 python-cffi 玩了会儿，最后还是写了个 Python 模块，也是抓住机会练习一下 C 啦。有个 python-prctl 模块，但是它没有包含这个调用。

#include<sys/prctl.h>
#include<Python.h>

static PyObject* subreap(PyObject *self, PyObject *args){
  PyObject* pyreaping;
  int reaping;
  int result;

  if (!PyArg_ParseTuple(args, "O!", &PyBool_Type, &pyreaping))
    return NULL;
  reaping = pyreaping == Py_True;

  Py_BEGIN_ALLOW_THREADS
  result = prctl(PR_SET_CHILD_SUBREAPER, reaping);
  Py_END_ALLOW_THREADS

  if(result != 0){
    return PyErr_SetFromErrno(PyExc_OSError);
  }else{
    Py_RETURN_NONE;
  }
}

static PyMethodDef mysysutil_methods[] = {
  {"subreap", subreap, METH_VARARGS},
  {NULL, NULL}    /* Sentinel */
};

static PyModuleDef mysysutil = {
  PyModuleDef_HEAD_INIT,
  "mysysutil",
  "My system utils",
  -1,
  mysysutil_methods,
  NULL, NULL, NULL, NULL
};

PyMODINIT_FUNC PyInit_mysysutil(void){
  PyObject* m;

  m = PyModule_Create(&mysysutil);
  if(m == NULL)
    return NULL;
  return m;
}

编译之后，

>>> import mysysutil
>>> mysysutil.subreap(True)

然后开子进程，不管它 fork 多少次，都依然会在这个 Python 进程之下啦。

但是，这样子不太好玩呢。如果我登陆之后所有启动的子进程都在一个进程之下不是更有意思么？于是我打上了 Awesome 的主意，因为它支持运行任意的 Lua 代码嘛。于是我又给这个 prctl 调用弄了个 Lua 绑定。最终的版本如下：

#include<lua.h>
#include<lualib.h>
#include<lauxlib.h>

#include<sys/prctl.h>
#include<sys/wait.h>
#include<errno.h>
#include<string.h>
#include<signal.h>

static int l_setsubreap(lua_State * L){
  int reap;
  if(lua_isboolean(L, 1)){
    reap = lua_toboolean(L, 1);
  }else{
    return luaL_argerror(L, 1, "not a boolean");
  }
  if(prctl(PR_SET_CHILD_SUBREAPER, reap) != 0){
    return luaL_error(L, "prctl failed: %s", strerror(errno));
  }
  return 0;
}

static int l_ignore_SIGCHLD(lua_State * L){
  signal(SIGCHLD, SIG_IGN);
  return 0;
}

static int l_reap(lua_State * L){
  int pid, st;
  pid = waitpid(-1, &st, WNOHANG);
  lua_pushinteger(L, st);
  lua_pushinteger(L, pid);
  return 2;
}

static const struct luaL_Reg l_lib[] = {
  {"setsubreap", l_setsubreap},
  {"reap", l_reap},
  {"ignore_SIGCHLD", l_ignore_SIGCHLD},
  {NULL, NULL}
};

int luaopen_clua(lua_State * L){
  lua_newtable(L);
  luaL_setfuncs(L, l_lib, 0);
  return 1;
}

除了调用 prctl 外，还增加了显式忽略 SIGCHLD 信号，以及非阻塞地调用 waitpid 收割单个僵尸进程的函数，因为 Awesome 本身没处理子进程退出，我一不小心弄出了好几个僵尸进程……对了，那个 waitpid 要注意给弄成非阻塞的，不然一不小心就会出问题。

用的时候就是这样子，可以写到rc.lua里，也可以在 awesome-client 里调用：

package.cpath = package.cpath .. ';/home/lilydjwg/scripts/lua/cmod/?.so'
clua = require('clua')
clua.setsubreap(true)
clua.ignore_SIGCHLD()

最终，我的进程树成了这样子：

可以看到，由 Awesome 启动的进程已经全部待在 Awesome 进程树之下了。systemd --user 是由 PAM 启动的，所以不在 Awesome 树下。但是，那些 dbus 的东西和 gconfd-2、at-spi 之类的是怎么回事呀……

Awesome 用户们，你们有没有觉得 Awesome 那个 naughty 组件的通知很丑？

这样子是不是好一些？

Linux 的桌面通知机制是使用 D-Bus 通信的。所以，要换个桌面通知的流程如下：

1. 让旧的桌面守护进程释放对应的 D-Bus 目的地名；
2. 运行新的桌面守护进程。

首先安装个新的通知守护进程，比如我安装的xfce4-notifyd。

阅读 Awesome 的naughty.lua代码之后，发现 Awesome 其实能够「慷慨」地释放org.freedesktop.Notifications这个通知用的地址的：

$ awesome-client
awesome#return dbus.release_name("session", "org.freedesktop.Notifications")
   boolean true

使用awesome-client告诉 Awesome 执行这条语句，释放这个 D-Bus 目的地址。返回true就表示执行成功了。如果喜欢的话，当然可以把这句写到rc.lua里去。

其实做到这一步就可以了。在需要时 D-Bus 会自动激活 xfce4-notifyd 的进程。当然也可以手动运行：

$ /usr/lib/xfce4/notifyd/xfce4-notifyd

还可以使用xfce4-notifyd-config命令来进行简单的配置哦。当然，这个替换对于从 Awesome 脚本里直接调用 naughty 不起效的。

从上边的图片可以看到，XFCE 的通知支持按钮的，Awesome 不支持这个。不过，它们都支持类似这种<span color="blue">蓝色文字</span>的 Pango 文本标记语法。

要换回使用 Awesome 来显示通知的话，先关掉其它通知守护进程，然后让 Awesome 告诉 D-Bus 它要来处理这个地址上的消息：

awesome# return dbus.request_name("session", "org.freedesktop.Notifications")
   boolean true

最后来吐槽一下 C 公司的notify-osd，就是 Ubuntu 上默认那个看上去不错的黑框框。它不支持 Pango 文本标记也就罢了，不能同时显示多条通知只能一个个地来也就罢了，像 fcitx 这样往通知上放点按钮你猜会怎么着？——

竟然出来个夺取窗口焦点的弹框……

GIMP一启动就有三个窗口，一个显示图像的，一个工具箱，一个图层什么的。工具箱和图层这些虽然被Awesome自动判为浮动窗口了，但因为显示图像的主窗口是最大化，所以它们经常被图像窗口遮住。将这两个窗口置顶是最简单的办法，但是不太完美。这样它们也会遮住诸如我的浮动终端之类的窗口。

既然是高可配置的Awesome，当然不是没有办法让它们乖乖听话。于是翻翻手册，在我的 rc.lua 里又加了如下代码：

-- {{{2 for GIMP
client.add_signal("focus", function(c)
  if c.class and c.class == 'Gimp-2.6' then
    for _, i in ipairs(c:tags()) do
      for _, j in ipairs(i:clients()) do
        if j.role and (j.role == 'gimp-toolbox' or j.role == 'gimp-dock') then
          j.above = true
        end
      end
    end
  end
end)
client.add_signal("unfocus", function(c)
  if c.class and c.class == 'Gimp-2.6' then
    for _, i in ipairs(c:tags()) do
      for _, j in ipairs(i:clients()) do
        if j.role and (j.role == 'gimp-toolbox' or j.role == 'gimp-dock') then
          j.above = false
        end
      end
    end
  end
end)

这样在 GIMP 的窗口获得焦点时就把那两个窗口置顶，失去焦点时再取消置顶。不过令我有些不解的是，不能给单个的client对象添加信号处理。