12
12
2020
28

一次失败的 KDE 尝试

前些天尝试了一下 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 改造成我需要的样子。

Category: Linux | Tags: KDE X Window 窗口管理器
12
12
2020
28

一次失败的 KDE 尝试

前些天尝试了一下 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 改造成我需要的样子。

Category: Linux | Tags: KDE X Window 窗口管理器
12
6
2020
2

i3 的 scratchpad 处理逻辑

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 里开了一堆图片需要局部对比时)
  • 有全屏窗口时不能显示浮动窗口(看视频无法临时使用浮动窗口查个单词啥的)
  • 切换窗口时,平铺窗口和浮动窗口是隔绝的(需要单独的快捷键来切换)
Category: Linux | Tags: X Window i3 窗口管理器
12
6
2020
2

i3 的 scratchpad 处理逻辑

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 里开了一堆图片需要局部对比时)
  • 有全屏窗口时不能显示浮动窗口(看视频无法临时使用浮动窗口查个单词啥的)
  • 切换窗口时,平铺窗口和浮动窗口是隔绝的(需要单独的快捷键来切换)
Category: Linux | Tags: X Window i3 窗口管理器
7
22
2019
6

fcitx 扩展:使用键盘粘贴选区(以及X选区原理科普)

之前的文章中介绍过,X Window 中有个很方便的名叫 PRIMARY 的「剪贴板」,选中即复制,中键即粘贴。

然而问题来了:我在输入的过程中需要之前选中的内容怎么办?又或者我的内容是通过 xsel、Vim 等程序以键盘的方式选中的,我还要继续打字,要怎么粘贴才比较流畅呢?

我之前的解决方案是 fcitx 自带的 fcitx-clipboard 扩展。启用之后可以按 Ctrl-; 来显示几条最近复制的内容。如果启用了的话,第一条、第三至最后,都来自常见的 CLIPBOARD 选区,而第二条(如果用了够久,第一条及本条有的话)是 PRIMARY 选区的内容。于是我只需要按 Ctrl-; 2 就可以粘贴了。

这么用了很久之后,我读到了一篇讲 X Window 选区是如何工作的文章。然后突然意识到一个问题:fcitx-clipboard 是什么时候请求选区内容的呢?

这里先科普一下好了。X Window 的每一个选区,是由某个窗口作为所有者持有的,并且在被请求时输出内容。「复制」的时候,内容并不会被存起来放在某处,而是窗口跟 X 服务器说,「我现在是这个选区的所有者了!」至于是哪个,取决于应用程序(及用户的操作)。通常用户明确的「复制」操作(Ctrl-C 快捷键、菜单项等)会使用 CLIPBOARD 选区,而只是选中内容的话,会使用 PRIMARY 选区。我还没有见到有程序使用别的选区的。

如果使用的是 PRIMARY 选区,这个时候,旧的所有者(如果存在的话)会失去选区。在 Vim / GVim 里,可视区域会由「Visual」高亮组变为「VIsualNOS」高亮组(在我的主题里就是变灰了),而多数终端,选中的区域会失去高亮。下一次,有程序想要「粘贴」PRIMARY 选区,就会跟 X 服务器讲,请把 PRIMARY 选区的内容,以某个指定的格式写到指定窗口的指定属性上。然后 X 服务器把请求传给选区所有者,选区所有者就去按要求写属性。当然选区所有者也可能会拒绝请求,比如它拥有的是文本而请求方想要图片。当然后来大家要粘贴的内容比较大了,于是就有了 INCR 机制来一点一点地传数据。

这样的流程,也可以解释,为什么我往 Telegram 里粘贴图片,GIMP 却莫名其妙地挂掉了……

所以啦,在一个程序里复制之后,退出那个程序,你就粘贴不出来东西啦。可这样岂不是很不方便?是啊,所以又有了剪贴板管理器。它们的工作原理我还没有研究,猜想是支持 SAVE_TARGETS 的话,就等着对方退出之前把内容传过来,不支持的话一复制就传过来。

fcitx-clipboard 是这么干的:选区一有变化,它就获取其纯文本格式的内容,符合一定条件的就存起来。所以,当我在 Vim 里用键盘不断进入可视模式选东西进行各种操作时,因为我设置了 clipboard=autoselect 选项,Vim 会不断地通告「我拥有 PRIMARY 选区啦!」「我这边的 PRIMARY 选区又更新啦!」结果就是,fcitx-clipboard 会不断地把我在 Vim 中选中的内容给拿过去。

就那么点数据,本地传来传去当然没啥问题。但是,当我通过 ssh 使用的时候,我发现我在 Vim 里每一次扩大可视区域都如此地艰难。不得已只好关了 autoselect 选项。当时我还以为就选点文本,怎么就这么慢呢,谁曾想到,每一次更新可视区域,fcitx-clipboard 都会把我选中的文本请求一份……

那么好吧,不用 fcitx-clipboard 了。于是问题又回到了原点:怎么通过键盘粘贴 PRIMARY 选区呢?用程序把鼠标移过去点中键是不行的,因为程序不会知道当前光标在哪里。通过 xdotool type 也行,但是这样一个个字地输入,而且还不仅仅是 ASCII,鬼晓得有多少程序跟 Minecraft 一样会处理不过来而丢字?而且,怎么判断当前是否是输入文本的状态也是个问题。所以我还是走输入法这条路了。

其实这事完成并不难,从肥猫的傲娇扩展开始改,照猫画虎地注册热键,然后请求选区,提交文本。可我遇到一个很奇怪的 bug:扩展加载了,但是热键不生效。为了调试这问题,我通过手机 termux ssh 连过来,tmux attach 上,然后用蓝牙键盘对着屏幕里那只由于 fcitx 被 gdb 停下来了因此从电脑收不到键盘事件的 tmux 调试好久,最终发现热键怎么没注册上,才找到配置文件里一处没有被更新到的 tsundere 字样……

这个扩展名叫 fcitx-paste-primary,源码放 GitHub 上了。Arch Linux 用户可以通过 AUR 或者 archlinuxcn 仓库安装 fcitx-paste-primary-git。

对了,差点忘了说,这个扩展「粘贴」的时候,只是把会被粘贴的文本提交给应用程序,程序并不会认为是真的粘贴,所以在一些需要区分的程序里会出现问题。比如 Vim 和 zsh,都会把来自 fcitx-paste-primary 的文本当作用户输入而非粘贴而可能造成问题。

Category: Linux | Tags: fcitx X Window X window
7
22
2019
6

fcitx 扩展:使用键盘粘贴选区(以及X选区原理科普)

之前的文章中介绍过,X Window 中有个很方便的名叫 PRIMARY 的「剪贴板」,选中即复制,中键即粘贴。

然而问题来了:我在输入的过程中需要之前选中的内容怎么办?又或者我的内容是通过 xsel、Vim 等程序以键盘的方式选中的,我还要继续打字,要怎么粘贴才比较流畅呢?

我之前的解决方案是 fcitx 自带的 fcitx-clipboard 扩展。启用之后可以按 Ctrl-; 来显示几条最近复制的内容。如果启用了的话,第一条、第三至最后,都来自常见的 CLIPBOARD 选区,而第二条(如果用了够久,第一条及本条有的话)是 PRIMARY 选区的内容。于是我只需要按 Ctrl-; 2 就可以粘贴了。

这么用了很久之后,我读到了一篇讲 X Window 选区是如何工作的文章。然后突然意识到一个问题:fcitx-clipboard 是什么时候请求选区内容的呢?

这里先科普一下好了。X Window 的每一个选区,是由某个窗口作为所有者持有的,并且在被请求时输出内容。「复制」的时候,内容并不会被存起来放在某处,而是窗口跟 X 服务器说,「我现在是这个选区的所有者了!」至于是哪个,取决于应用程序(及用户的操作)。通常用户明确的「复制」操作(Ctrl-C 快捷键、菜单项等)会使用 CLIPBOARD 选区,而只是选中内容的话,会使用 PRIMARY 选区。我还没有见到有程序使用别的选区的。

如果使用的是 PRIMARY 选区,这个时候,旧的所有者(如果存在的话)会失去选区。在 Vim / GVim 里,可视区域会由「Visual」高亮组变为「VIsualNOS」高亮组(在我的主题里就是变灰了),而多数终端,选中的区域会失去高亮。下一次,有程序想要「粘贴」PRIMARY 选区,就会跟 X 服务器讲,请把 PRIMARY 选区的内容,以某个指定的格式写到指定窗口的指定属性上。然后 X 服务器把请求传给选区所有者,选区所有者就去按要求写属性。当然选区所有者也可能会拒绝请求,比如它拥有的是文本而请求方想要图片。当然后来大家要粘贴的内容比较大了,于是就有了 INCR 机制来一点一点地传数据。

这样的流程,也可以解释,为什么我往 Telegram 里粘贴图片,GIMP 却莫名其妙地挂掉了……

所以啦,在一个程序里复制之后,退出那个程序,你就粘贴不出来东西啦。可这样岂不是很不方便?是啊,所以又有了剪贴板管理器。它们的工作原理我还没有研究,猜想是支持 SAVE_TARGETS 的话,就等着对方退出之前把内容传过来,不支持的话一复制就传过来。

fcitx-clipboard 是这么干的:选区一有变化,它就获取其纯文本格式的内容,符合一定条件的就存起来。所以,当我在 Vim 里用键盘不断进入可视模式选东西进行各种操作时,因为我设置了 clipboard=autoselect 选项,Vim 会不断地通告「我拥有 PRIMARY 选区啦!」「我这边的 PRIMARY 选区又更新啦!」结果就是,fcitx-clipboard 会不断地把我在 Vim 中选中的内容给拿过去。

就那么点数据,本地传来传去当然没啥问题。但是,当我通过 ssh 使用的时候,我发现我在 Vim 里每一次扩大可视区域都如此地艰难。不得已只好关了 autoselect 选项。当时我还以为就选点文本,怎么就这么慢呢,谁曾想到,每一次更新可视区域,fcitx-clipboard 都会把我选中的文本请求一份……

那么好吧,不用 fcitx-clipboard 了。于是问题又回到了原点:怎么通过键盘粘贴 PRIMARY 选区呢?用程序把鼠标移过去点中键是不行的,因为程序不会知道当前光标在哪里。通过 xdotool type 也行,但是这样一个个字地输入,而且还不仅仅是 ASCII,鬼晓得有多少程序跟 Minecraft 一样会处理不过来而丢字?而且,怎么判断当前是否是输入文本的状态也是个问题。所以我还是走输入法这条路了。

其实这事完成并不难,从肥猫的傲娇扩展开始改,照猫画虎地注册热键,然后请求选区,提交文本。可我遇到一个很奇怪的 bug:扩展加载了,但是热键不生效。为了调试这问题,我通过手机 termux ssh 连过来,tmux attach 上,然后用蓝牙键盘对着屏幕里那只由于 fcitx 被 gdb 停下来了因此从电脑收不到键盘事件的 tmux 调试好久,最终发现热键怎么没注册上,才找到配置文件里一处没有被更新到的 tsundere 字样……

这个扩展名叫 fcitx-paste-primary,源码放 GitHub 上了。Arch Linux 用户可以通过 AUR 或者 archlinuxcn 仓库安装 fcitx-paste-primary-git。

对了,差点忘了说,这个扩展「粘贴」的时候,只是把会被粘贴的文本提交给应用程序,程序并不会认为是真的粘贴,所以在一些需要区分的程序里会出现问题。比如 Vim 和 zsh,都会把来自 fcitx-paste-primary 的文本当作用户输入而非粘贴而可能造成问题。

Category: Linux | Tags: fcitx X Window X window
2
25
2017
17

中键的功能

鼠标中键,就是左键和右键之间的那个键啦。常见的鼠标上它在滚轮上。所以你知道了,滚轮是可以往下按的哦。如果是触摸板并且没有中键的话,可以配置双指点击来作为中键使用的(synclient ClickFinger2=3)。

中键具有以下好用的功能哦~(括号里是适用的场景)

  • 粘贴选择区,不用按复制和粘贴的快捷键了~不过选择区的寿命通常比较短,只适合快速的粘贴操作。另见 X Window 中的剪贴板一文。(Linux 桌面、macOS 终端、gpm)
  • 在后台新标签页打开链接(火狐、Google Chrome 等浏览器都支持)
  • 关闭标签页(基本上也是用于网页浏览器。我自己的 GVim 也支持)
  • 定位滚动条,可以快速地定位到开头、结尾,或者之前的位置。不需要拖来拖去的麻烦。可惜 GTK 3 里这个功能不好用的了。(GTK 2、Qt)
  • 移动画布(GIMP、Inkscape 等作图软件、GNOME 的文档查看器 Evince)

这只是比较通用的功能。我的 Awesome 还配置了使用中键关闭窗口呢(「关闭标签页」语义的扩展)。火狐的一些菜单项也支持中键点击,比如书签菜单,右键的「查看图像」菜单,比如前进/后退按钮,以及在它上边点击右键出来的历史记录项目。

总结一下中键的语义:

  • 在可以粘贴的地方,粘贴
  • 在打开对象时,打开新对象而不取代已有者
  • 在打开的对象本身上时,关闭之
  • 在可定位对象上,移动之
Category: Linux | Tags: linux X Window X window
2
25
2017
17

中键的功能

鼠标中键,就是左键和右键之间的那个键啦。常见的鼠标上它在滚轮上。所以你知道了,滚轮是可以往下按的哦。如果是触摸板并且没有中键的话,可以配置双指点击来作为中键使用的(synclient ClickFinger2=3)。

中键具有以下好用的功能哦~(括号里是适用的场景)

  • 粘贴选择区,不用按复制和粘贴的快捷键了~不过选择区的寿命通常比较短,只适合快速的粘贴操作。另见 X Window 中的剪贴板一文。(Linux 桌面、macOS 终端、gpm)
  • 在后台新标签页打开链接(火狐、Google Chrome 等浏览器都支持)
  • 关闭标签页(基本上也是用于网页浏览器。我自己的 GVim 也支持)
  • 定位滚动条,可以快速地定位到开头、结尾,或者之前的位置。不需要拖来拖去的麻烦。可惜 GTK 3 里这个功能不好用的了。(GTK 2、Qt)
  • 移动画布(GIMP、Inkscape 等作图软件、GNOME 的文档查看器 Evince)

这只是比较通用的功能。我的 Awesome 还配置了使用中键关闭窗口呢(「关闭标签页」语义的扩展)。火狐的一些菜单项也支持中键点击,比如书签菜单,右键的「查看图像」菜单,比如前进/后退按钮,以及在它上边点击右键出来的历史记录项目。

总结一下中键的语义:

  • 在可以粘贴的地方,粘贴
  • 在打开对象时,打开新对象而不取代已有者
  • 在打开的对象本身上时,关闭之
  • 在可定位对象上,移动之
Category: Linux | Tags: linux X Window X window
11
4
2015
23

从 slim 到 lightdm

从一开始使用 Arch Linux,我就选择了 slim 作为登录管理器。因为它轻量嘛,而且配合 Arch Linux 自己做的主题也挺漂亮的:

slim 登录界面

所以即使 slim 不再使用配置文件来指定有哪些桌面环境可用,改用无法指定顺序的 .desktop 文件,我只好告诉 pacman,不要升级 slim 了。

于是就这么用了很久,直到 lightdm 出世,直到 slim 所使用的托管网站关闭、停止开发,我也依然在用 slim。

直到有一天,那是在 systemd 开始使用用户级别的 session D-Bus 之后。我登出了会话,再次登入时,发现整个系统都不好了,因为 DBUS_SESSION_BUS_ADDRESS 环境变量没有被设置,导致程序找不到 session bus 而自动启动了一个。可我用户级别的 systemd 还在旧的 session bus 里呢,联系不上了。当然 tmux 里所使用的 session bus 也开始混乱了(我有让 tmux 从环境里更新各种 window 中的 DBUS_SESSION_BUS_ADDRESS 变量)。

究其原因,是因为 slim 没有正确地处理 sesssion。从 loginctl 及 systemd-cgls 可以看到,重新登录 slim 之后,进程并没有处在新的会话里,而是复用了旧的会话。

systemd 上,会话管理是 pam_systemd 来管理的,同时它会引入 DBUS_SESSION_BUS_ADDRESS 环境变量。PAM 会话是有一个 leader 进程的,它的结束标志着这个会话的结束(当然里边存活的进程还会继续存在)。比如文本终端登录用的 login,每一次登录都是一个新进程。比如 sshd,每个连接都是由单独的子进程来处理,PAM 会话也是那个时候打开的。然而 slim 却是在父进程里打开了 PAM 会话。于是 pam_systemd 一看,这个 session leader 怎么又要打开会话啦?报错:

8月 02 21:54:32 lilyforest slim[669]: pam_systemd(slim:session): Cannot create session: Already running in a session

所以,slim 下,只有第一次登录是正常的……

所以是时候换个跟得上时代的登录管理器了。那就 lightdm + GTK greeter 好了。

这个我以前也用过,不过没怎么配置所以背景一片漆黑,难看死了。这次制作了张背景图,在/etc/lightdm/lightdm-gtk-greeter.conf里配置一下

[greeter]
background=/usr/local/share/pixmaps/background.png

咦?还有头像?那就放一个~/.face好了。什么?lightdm 你没权限读取它?OK,给你权限:

setfacl -m u:lightdm:x ~
setfacl -m u:lightdm:r ~/.face

我的 HOME 目录的权限是 750,别人(other)进不来的,所以要给 lightdm x 权限。

最终的样子就是这样,也挺漂亮的,功能还挺全 :-)

lightdm 登录界面

Category: Linux | Tags: linux X Window systemd X window
11
4
2015
23

从 slim 到 lightdm

从一开始使用 Arch Linux,我就选择了 slim 作为登录管理器。因为它轻量嘛,而且配合 Arch Linux 自己做的主题也挺漂亮的:

slim 登录界面

所以即使 slim 不再使用配置文件来指定有哪些桌面环境可用,改用无法指定顺序的 .desktop 文件,我只好告诉 pacman,不要升级 slim 了。

于是就这么用了很久,直到 lightdm 出世,直到 slim 所使用的托管网站关闭、停止开发,我也依然在用 slim。

直到有一天,那是在 systemd 开始使用用户级别的 session D-Bus 之后。我登出了会话,再次登入时,发现整个系统都不好了,因为 DBUS_SESSION_BUS_ADDRESS 环境变量没有被设置,导致程序找不到 session bus 而自动启动了一个。可我用户级别的 systemd 还在旧的 session bus 里呢,联系不上了。当然 tmux 里所使用的 session bus 也开始混乱了(我有让 tmux 从环境里更新各种 window 中的 DBUS_SESSION_BUS_ADDRESS 变量)。

究其原因,是因为 slim 没有正确地处理 sesssion。从 loginctl 及 systemd-cgls 可以看到,重新登录 slim 之后,进程并没有处在新的会话里,而是复用了旧的会话。

systemd 上,会话管理是 pam_systemd 来管理的,同时它会引入 DBUS_SESSION_BUS_ADDRESS 环境变量。PAM 会话是有一个 leader 进程的,它的结束标志着这个会话的结束(当然里边存活的进程还会继续存在)。比如文本终端登录用的 login,每一次登录都是一个新进程。比如 sshd,每个连接都是由单独的子进程来处理,PAM 会话也是那个时候打开的。然而 slim 却是在父进程里打开了 PAM 会话。于是 pam_systemd 一看,这个 session leader 怎么又要打开会话啦?报错:

8月 02 21:54:32 lilyforest slim[669]: pam_systemd(slim:session): Cannot create session: Already running in a session

所以,slim 下,只有第一次登录是正常的……

所以是时候换个跟得上时代的登录管理器了。那就 lightdm + GTK greeter 好了。

这个我以前也用过,不过没怎么配置所以背景一片漆黑,难看死了。这次制作了张背景图,在/etc/lightdm/lightdm-gtk-greeter.conf里配置一下

[greeter]
background=/usr/local/share/pixmaps/background.png

咦?还有头像?那就放一个~/.face好了。什么?lightdm 你没权限读取它?OK,给你权限:

setfacl -m u:lightdm:x ~
setfacl -m u:lightdm:r ~/.face

我的 HOME 目录的权限是 750,别人(other)进不来的,所以要给 lightdm x 权限。

最终的样子就是这样,也挺漂亮的,功能还挺全 :-)

lightdm 登录界面

Category: Linux | Tags: linux X Window systemd X window

| Theme: Aeros 2.0 by TheBuckmaker.com