yong输入法新测试版发布

dgod

Post by puhongyi;1979850
我可以免费为你提供服务器空间来发布，帮这个输入法出一点点力。如果你需要的话，联系我，puhongyi(a)gmail.com

十分感谢，不过还是不麻烦您了，反正下载的人也不多，论坛抽风也是会好的

dgod

Post by hubert_star;1979857
不要用这个补丁

当时只是看在这个地方引起ooo的错误，我就去掉了release监视，当时打完这个补丁后使用了几天，发现有些功能还是要依赖于release的，比如切换英文输入等。

所以，这个补丁仅仅是临时解决方案，还是要等fcitx的官方来解决。

这问题属于ooo的bug，我不认为应该由fcitx来解决，即使加上这个补丁，在速度很慢的系统上，还是会出字母的。

现在的状况是打字慢点的话没问题，打快了出字母的情况就多起来，而那点速度，输入法程序显然处理得过来。很可能是ooo在那块有毛病。

hubert_star

我认为还是应该由输入法来解决这个问题

从操作上来看，确实速度再快，输入法也能处理过来，但掉字问题看上去好像输入法处理不过来。

当时非常奇怪的是，fcitx 918版没有这个问题，别的版本都有

dgod

输入法的程序逻辑决定了，即使处理得再慢，它即使拖慢整个系统，也不会中途把这个字母发回去。而像fcitx这样的xim输入法，如果输入法不主动把字母发回去，正常的程序中是不会出现在字母的。

问题可能是出在系统缓慢的时候，两个可能的原因。
1 有字词上屏的时候（ooo收到输入法发过来的字词，往文档中写），正巧有按键，ooo处理不了。
2 输入法没有处理完按键，又有新的按键过来的时候，ooo就把新来的按键给上屏了。假如ooo在处理输入的时候是多线程的话，可能就是这毛病了。

对于第一种情况，完全是ooo的问题，第二种情况，两者都有责任，但从统一的角度来说，应该是ooo来处理的。如果要从输入法来处理，在一个缓慢的系统上，总归有处理不过来的时候，linux上的输入法都是进程间通讯，有部分时间也不是输入法能控制的。

hubert_star

Post by dgod;1979860
十分感谢，不过还是不麻烦您了，反正下载的人也不多，论坛抽风也是会好的

一个小小的请求，能不能加上64位的版本

或者是公开源代码大家自己编译

我准备把yong放到arch的aur上

看了一下这个输入法，非常不错

如果同意的话，我的任务：

1 构建for arch的包，上传至aur，提供i686和x86_64版本

2 加入ibus的词库

dgod

64位版本，主要是我没有64位的环境（虚拟的64位环境实在是太慢了），源代码暂时不打算公开

不过我测试过，32位输入法可以在64位系统上运行，工作正常

对于有人打包，我是很高兴的

词库的话，可能还得考虑一下ibus的词库能不能在非自由软件上用，好像他们对此的要求非常严格。

另外能不能请教一下arch下输入法是怎么设置的，如果方便，我可以在7z包的yong-tool.sh里面加入对arch的支持。

hubert_star

在我的arch上，32位的程序需要 lib32兼容包才能运行，或者你编译的时候选择静态编译，不要用动态链接库，也能够避免32位和64位的问题。

而arch的输入法配置，简单来说就是在bash的profile里面加上环境变量就行，不需要额外etc里面的配置

ibus词库的问题，你的输入法是闭源的，但我做的是外挂包，这个外挂是开源的，跟你的输入法用什么协议没有关系。

如果信任我的话，我可以帮你编译，或者是给你开个帐号，你自己登上来编译也可以

dgod

输入法在64位上还要详细测一下才行，毕竟32位和64位还是有些兼容性问题（代码写得不好的话）。

上次我开个qemu虚拟机整了一下午才编译出一个来，我这两天再整一下，争取搞个64位版本出来。反正稳定版本的话，不需要太过频繁更新。

dgod

输入法在64位上还要详细测一下才行，毕竟32位和64位还是有些兼容性问题（代码写得不好的话）。

上次我开个qemu虚拟机整了一下午才编译出一个来，我这两天再整一下，争取搞个64位版本出来。反正稳定版本的话，不需要太过频繁更新。

hubert_star

好吧，等你消息