[2018.6.25]fcitx把openbox弄死的不完美凑合解决方法(欢迎提供更好方法)

讨论openbox,awesome,FVWM等WM
科学之子
帖子: 2229
注册时间: 2013-05-26 6:58
系统: Debian 9
送出感谢: 833 次
接收感谢: 30 次

Re: [2016.5.11,04:54]fcitx把openbox弄死的解决方法,但部分程序无法使用fcitx?

#46

帖子 科学之子 » 2017-09-01 23:20

"XMODIFIERS=@im=fcitx"也能凑合的方法:

代码: 全选

#!/bin/sh
ENVIRON=$(xargs -0a  /proc/$(pgrep -u $(whoami) -x openbox)/environ)
OPENBOX_COMMAND=$(xargs -0a  /proc/$(pgrep -u $(whoami) -x openbox)/cmdline)
pkill -SIGKILL -u $(whoami) -x openbox
env -i ${ENVIRON} ${OPENBOX_COMMAND} &
我在Debian 9 的LXDE上测试过这个脚本
用这个脚本就可以很轻松的在tty重启openbox,重启之后的openbox其环境变量和参数和重启前相同.
jinjiachen
帖子: 2095
注册时间: 2012-12-16 15:43
系统: debian
送出感谢: 8 次
接收感谢: 27 次

Re: [2017.9.1]fcitx把openbox弄死的不完美凑合解决方法(欢迎提供更好方法)

#47

帖子 jinjiachen » 2017-09-04 13:07

我也再用fcitx和openbox,不过不去重启不知道有没有大家说的问题,同样是archlinux+openbox+fcitx,之前的系统完全没问题,现在重装了下,发现有延迟现象,在想为什么不用ibus :What
科学之子
帖子: 2229
注册时间: 2013-05-26 6:58
系统: Debian 9
送出感谢: 833 次
接收感谢: 30 次

Re: [2017.9.1]fcitx把openbox弄死的不完美凑合解决方法(欢迎提供更好方法)

#48

帖子 科学之子 » 2017-09-04 13:26

jinjiachen 写了:我也再用fcitx和openbox,不过不去重启不知道有没有大家说的问题,同样是archlinux+openbox+fcitx,之前的系统完全没问题,现在重装了下,发现有延迟现象,在想为什么不用ibus :What
ibus 跟firefox一起有问题,会卡CPU
而且我机器配置老旧,ibus-pinyin 是用 python 写的,感觉应该不如fcitx流畅(不过卡CPU应该不是python自身原因)
记得以前装过一次archlinux,好像archlinux的ibus-pinyin版本比较新,不存在卡CPU的问题.

延迟现象指的是什么呢?
jinjiachen
帖子: 2095
注册时间: 2012-12-16 15:43
系统: debian
送出感谢: 8 次
接收感谢: 27 次

Re: [2017.9.1]fcitx把openbox弄死的不完美凑合解决方法(欢迎提供更好方法)

#49

帖子 jinjiachen » 2017-09-06 17:16

科学之子 写了:
jinjiachen 写了:我也再用fcitx和openbox,不过不去重启不知道有没有大家说的问题,同样是archlinux+openbox+fcitx,之前的系统完全没问题,现在重装了下,发现有延迟现象,在想为什么不用ibus :What
ibus 跟firefox一起有问题,会卡CPU
而且我机器配置老旧,ibus-pinyin 是用 python 写的,感觉应该不如fcitx流畅(不过卡CPU应该不是python自身原因)
记得以前装过一次archlinux,好像archlinux的ibus-pinyin版本比较新,不存在卡CPU的问题.

延迟现象指的是什么呢?
就是ctrl+space后,要过段时间才有反应,打字也是,并不只是在切换的时候,同样的硬件同样的系统,只是重装了下,就有不同的现象,重复性有点差
科学之子
帖子: 2229
注册时间: 2013-05-26 6:58
系统: Debian 9
送出感谢: 833 次
接收感谢: 30 次

Re: [2017.9.1]fcitx把openbox弄死的不完美凑合解决方法(欢迎提供更好方法)

#50

帖子 科学之子 » 2017-09-06 19:38

jinjiachen 写了:
科学之子 写了:
jinjiachen 写了:我也再用fcitx和openbox,不过不去重启不知道有没有大家说的问题,同样是archlinux+openbox+fcitx,之前的系统完全没问题,现在重装了下,发现有延迟现象,在想为什么不用ibus :What
ibus 跟firefox一起有问题,会卡CPU
而且我机器配置老旧,ibus-pinyin 是用 python 写的,感觉应该不如fcitx流畅(不过卡CPU应该不是python自身原因)
记得以前装过一次archlinux,好像archlinux的ibus-pinyin版本比较新,不存在卡CPU的问题.

延迟现象指的是什么呢?
就是ctrl+space后,要过段时间才有反应,打字也是,并不只是在切换的时候,同样的硬件同样的系统,只是重装了下,就有不同的现象,重复性有点差
"同样的系统",arch更新很快,相隔几天(甚至几小时)一些包就可能有不同版本.
确定版本也是相同的吗?好像arch官方有回滚机制用于对付这种新版本没法用的情况.
科学之子
帖子: 2229
注册时间: 2013-05-26 6:58
系统: Debian 9
送出感谢: 833 次
接收感谢: 30 次

Re: [2017.9.1]fcitx把openbox弄死的不完美凑合解决方法(欢迎提供更好方法)

#51

帖子 科学之子 » 2018-05-26 17:41

"XMODIFIERS=@im=fcitx"也能凑合的方法(重启脚本改进了一下):

代码: 全选

#!/bin/bash
#ENVIRON=$(xargs -0a  /proc/$(pgrep -u $(whoami) -x openbox)/environ)
mapfile -d '' ENVIRONS  </proc/$(pgrep -u $(whoami) -x openbox)/environ
#OPENBOX_COMMAND=$(xargs -0a  /proc/$(pgrep -u $(whoami) -x openbox)/cmdline)
mapfile -d '' COMMAND </proc/$(pgrep -u $(whoami) -x openbox)/cmdline

pkill -SIGKILL -u $(whoami) -x openbox
while  ! pgrep -u $(whoami) -x openbox ;do
#env -i ${ENVIRON} ${OPENBOX_COMMAND} &
env -i "${ENVIRONS[@]}" "${COMMAND[@]}" &
sleep 1
done
实测发现有些时候openbox会启动失败,所以延时1秒再次检测一次,如果没有启动就再次启动.

Sat May 26 17:56:34 CST 2018:
方法来自: https://unix.stackexchange.com/a/424320/259284
另外可以配合xbindkeys来绑定这个脚本,这样openbox死了也不用切换到tty上重启了.
工具名称来自: https://unix.stackexchange.com/a/445356/259284
头像
九天星
帖子: 1317
注册时间: 2007-07-14 20:45
送出感谢: 67 次
接收感谢: 37 次

Re: [2018.5.26]fcitx把openbox弄死的不完美凑合解决方法(欢迎提供更好方法)

#52

帖子 九天星 » 2018-05-26 21:49

vickycq, 好久不见!! :em11 :em11 :em11
开源、共享、自由

微信号非公众号:xfiles_sky

用手机点击这里有奇迹发生,其他无效
头像
尚目目
帖子: 44
注册时间: 2012-06-19 23:06
送出感谢: 0
接收感谢: 0

Re: [2018.5.26]fcitx把openbox弄死的不完美凑合解决方法(欢迎提供更好方法)

#53

帖子 尚目目 » 2018-05-26 21:51

好久不见,大家。

Ubuntu --> Arch --> Gentoo,现在我在 Debian sid 安家了。
科学之子
帖子: 2229
注册时间: 2013-05-26 6:58
系统: Debian 9
送出感谢: 833 次
接收感谢: 30 次

Re: [2018.5.26]fcitx把openbox弄死的不完美凑合解决方法(欢迎提供更好方法)

#54

帖子 科学之子 » 2018-06-25 20:16

代码: 全选

#!/bin/sh

#echo "1" >>~/my_openbox_log
while true ; do
#openbox "$@"
openbox --config-file $XDG_CONFIG_HOME/openbox/lxde-rc.xml $@
done
写了个守护脚本, openbox 无响应时用 xbindkeys 绑定的快捷键来结束死掉的 openbox
如果是在LXDE环境下使用的话,就把这个脚本设置为window manager,这样重新启动后的openbox也可以继承LXDE相关的环境变量.
个人实测感觉这个方法比51楼的更稳定,51楼的重启在某些情况下让仍会失效.

另外其实 lxsession 本身就有对 window manager 进程的守护功能,但不知道为什么 "pkill -9 $(whoami) openbox" 稍微多几次 lxsession 对 window manager 的守护就像不存在一样了.
把 window manager 换成这个脚本之后不论 "pkill -9 $(whoami) openbox" 多少次 都能成功守护 openbox
回复

回到 “窗口管理器”