Ubuntu中文论坛

npnufn 写了：64位是自讨苦吃，毫无益处。10年没进展

pjincz 写了：

warmsun 写了：

pjincz 写了：

warmsun 写了：

pjincz 写了：

warmsun 写了：看了一下视频貌似也有光标跟随问题 文字框明显在左下角 唉 这么用法迟早眼睛要用斜了

？？？ 不好意思哈，能解释一下么？不是太明白。

输入法选字框永远在左下角，而不是跟着光标移动…

哦，你说的是这个问题啊，因为当年输入法代码系统相关的很厉害，迁移到linux下无法通过编译，也无法简单的翻译，就给屏蔽了。
做预输入支持是挺难的，做个输入框光标跟随应该没什么问题（不过也不敢打包票哈，比较相关经验）。
晚上找个空，我研究一下哈，看能不能给倒腾出一个。

提前感谢一个 永中这个问题一直都不解决 希望WPS更考虑用户体验

原本以为只是一个很简单的问题，随便加上输入法代码就OK了，结果坑爹，我加上了输入法代码死活就是不行，然后我可怜的晚上时间就这么壮烈牺牲了，阿门。
linux也真是有好处有坏处啊，坏处是，出了问题打死找不到人可以问。好处是，到处都是代码一个一个的读、找就行了。
然后我这个悲催的夜晚就陪ibus xim qt的源代码度过了，阿门。
（不过还有个额外收获就是把linux的输入法体系摸了个遍，以后自己系统再也不怕坑爹的linux输入法问题了，囧）。
原本改完后打算放个图就了事了，为了祭奠我逝去的夜晚，我决定放个视频上去。。。。。。。

视频来了：
http://v.youku.com/v_show/id_XMzY1OTc5ODYw.html

额外说明，我用的输入法是ibus，研究了一下，还是只能ibus支持输入法跟随，xim始终不行，即使是其他kde程序（例如kwrite）也不行。

囧啊，才发现竟然给启动封面泄露出去了。上帝，我有罪。。。。。。

mikeandmore 写了：

pjincz 写了：

shinery 写了：为什么只有32bit？不是在64bit系统下重新编译一遍就可以了么？

呵呵，不是这么简单的，32位系统64位系统对代码冲击非常大。特别是文件读写的代码。
就比如说下面的代码：

struct header
{
int width;
int height;
}
在32位下可以工作的很好，如果在64位下还用这个定义的话会死的很凄惨的。说不定还会破坏文件，这个事情是很恐怖的。
更加恐怖的是这个结构体，在windows下是8个字节，在linux下是16个字节，阿门。

1. Linux和Windows是LP64和LLP64，int不会变长。
2. packing问题。从c89到现在一直都存在，如果wps代码里没有固定的padding字段或者编译器packing attribute，就算不跨体系，也会出问题的。

所以…………把所有的long改成int应该就好了=w=

mikeandmore 写了：

pjincz 写了：

warmsun 写了：

pjincz 写了：

warmsun 写了：

pjincz 写了：

warmsun 写了：看了一下视频貌似也有光标跟随问题 文字框明显在左下角 唉 这么用法迟早眼睛要用斜了

？？？ 不好意思哈，能解释一下么？不是太明白。

输入法选字框永远在左下角，而不是跟着光标移动…

哦，你说的是这个问题啊，因为当年输入法代码系统相关的很厉害，迁移到linux下无法通过编译，也无法简单的翻译，就给屏蔽了。
做预输入支持是挺难的，做个输入框光标跟随应该没什么问题（不过也不敢打包票哈，比较相关经验）。
晚上找个空，我研究一下哈，看能不能给倒腾出一个。

提前感谢一个 永中这个问题一直都不解决 希望WPS更考虑用户体验

原本以为只是一个很简单的问题，随便加上输入法代码就OK了，结果坑爹，我加上了输入法代码死活就是不行，然后我可怜的晚上时间就这么壮烈牺牲了，阿门。
linux也真是有好处有坏处啊，坏处是，出了问题打死找不到人可以问。好处是，到处都是代码一个一个的读、找就行了。
然后我这个悲催的夜晚就陪ibus xim qt的源代码度过了，阿门。
（不过还有个额外收获就是把linux的输入法体系摸了个遍，以后自己系统再也不怕坑爹的linux输入法问题了，囧）。
原本改完后打算放个图就了事了，为了祭奠我逝去的夜晚，我决定放个视频上去。。。。。。。

视频来了：
http://v.youku.com/v_show/id_XMzY1OTc5ODYw.html

额外说明，我用的输入法是ibus，研究了一下，还是只能ibus支持输入法跟随，xim始终不行，即使是其他kde程序（例如kwrite）也不行。

囧啊，才发现竟然给启动封面泄露出去了。上帝，我有罪。。。。。。

作为输入法开发者。我肯定的表示。xim已经彻底被遗弃了。

源头是xlib里面的代码，已经开始对xim server发过去的包无视，然后会给xim client返回一些神奇的packet。
gtk里面的处理很特别，忘记了，但是会影响窗口切换。qt应该是无视掉这些packet。有时候造成光标跟随不一致，输入法该弹出没有弹出等等。

所以……走qtimmodule吧。那是正路。

mikeandmore 写了：

npnufn 写了：64位是自讨苦吃，毫无益处。10年没进展

拒绝使用32位Kernel的飘走。软件有些没办法，上multilib。但是能64最好64.

32 bit x86是个坑爹的体系结构。

pjincz 写了：

mikeandmore 写了：

npnufn 写了：64位是自讨苦吃，毫无益处。10年没进展

拒绝使用32位Kernel的飘走。软件有些没办法，上multilib。但是能64最好64.

32 bit x86是个坑爹的体系结构。

~_~ x64更是一个坑爹的体系啊。。。。。。。

pjincz 写了：

mikeandmore 写了：

pjincz 写了：

shinery 写了：为什么只有32bit？不是在64bit系统下重新编译一遍就可以了么？

呵呵，不是这么简单的，32位系统64位系统对代码冲击非常大。特别是文件读写的代码。
就比如说下面的代码：

struct header
{
int width;
int height;
}
在32位下可以工作的很好，如果在64位下还用这个定义的话会死的很凄惨的。说不定还会破坏文件，这个事情是很恐怖的。
更加恐怖的是这个结构体，在windows下是8个字节，在linux下是16个字节，阿门。

1. Linux和Windows是LP64和LLP64，int不会变长。
2. packing问题。从c89到现在一直都存在，如果wps代码里没有固定的padding字段或者编译器packing attribute，就算不跨体系，也会出问题的。

所以…………把所有的long改成int应该就好了=w=

呵呵，刚刚上网去查了一下，竟然是我记忆错了哈，very sorry。
那这样的话，我过几天弄个64位系统试试。

lhw828 写了：这帖子看到后来，竟然不知所云了， 很多大神一样的词汇，搞得我不知所措。

guokw 写了：pjincz,金山能不能也顺便出一个输入法？？？就是王永民最新做的那个标准五笔字型。

还有，现在飞思卡尔的codewarrior，microchip公司的mplab x也支持linux了，很多人可以转到linux下开发嵌入式控制系统了，能不能也出一个金山词霸呀，在 linux下的，我们非常需要.这样可以将买windows操作系统的钱省下来买金山词霸for linux