fcitx源代码及deb安装包 - PPA源已经建立，将会停止手工更新

[wangdu2002]

utf8版本的配置文件在~/.confg/fcitx-utf8/下面。。。

[zhydyhm]

今天突然发现fcita与inkscape没有冲突了，太高兴了，真爽

[lilydjwg]

今天突然发现fcita与inkscape没有冲突了，太高兴了，真爽

+2

[xybds]

我这里 新版的 fcitx 好像常和别的软件起冲突

3.62 版 没碰到。

[npnufn]

为什么楼主编译的文件体积这么大？我自己在archlinux里编译的必这小一半，就想取消记录模式，也可以在ubuntu中使用，但是fcitx-remote失效了。
编辑配置文件取消记录模式从没成功过

[npnufn]

还是fcitx-remote失效的问题，错误提示：

代码： 全选

fcitx-remote -o
Can't open socket /tmp/fcitx-soeckt-:0.0: No such file or directory

/tmp/存在文件

代码： 全选

fcitx-soeckt-:0

很显然，文件名不同。我自己编译的svn 365 utf8版同样存在这个问题。
初次登录是正常的，但是如果注销了再次登录或者kill掉进程重启fcitx就会出现问题，似乎是重启fcitx不会自己刷新

代码： 全选

fcitx-soeckt-:0 .0

这个文件。

[csslayer]

还是fcitx-remote失效的问题，错误提示：

代码： 全选

fcitx-remote -o
Can't open socket /tmp/fcitx-soeckt-:0.0: No such file or directory

/tmp/存在文件

代码： 全选

fcitx-soeckt-:0

很显然，文件名不同。我自己编译的svn 365 utf8版同样存在这个问题。
初次登录是正常的，但是如果注销了再次登录或者kill掉进程重启fcitx就会出现问题，似乎是重启fcitx不会自己刷新

代码： 全选

fcitx-soeckt-:0 .0

这个文件。

utf8分支刚刚修正了一下这个问题

原因是我通过XDisplayName函数获得名称，而实际发现XDisplayName直接获得环境变量DISPLAY的值，刚登录时是:0，之后又变成:0.0，所以fcitx使用前者，fcitx-remote使用后者，而重新启动fcitx之后就会使用:0.0，结果就又正确了。
现在是XOpenDisplay之后再通过DisplayString获得的名称，应该不会出现两个名称的现象了。

顺便去掉了TrayWindow里面的一行，我也不知道Qt源代码里面这句是干啥的（修改系统托盘参考的Qt源码），只会导致trayer，lxpanel产生一个多余空位。

[alpha.gu]

更新到r366，两个多星期前说的接下来的大修改，看起来到现在并没有导入进来，继续等。

[hcym]

366 - 继续等等

[npnufn]

更新到r366，两个多星期前说的接下来的大修改，看起来到现在并没有导入进来，继续等。

有这等事？难怪“沉寂”了这“许久”
不是说下个版本是4.0么？不会导入到3.6分支吧

[alpha.gu]

为什么楼主编译的文件体积这么大？我自己在archlinux里编译的必这小一半，就想取消记录模式，也可以在ubuntu中使用，但是fcitx-remote失效了。
编辑配置文件取消记录模式从没成功过

大哥，Arch现在是xz压缩啊，而且，PKGBUILD是直接分析makefile的，而deb的包压缩方式不是xz的，东西也放的比Arch多，当然要大了啊，又不是我故意弄大的。

[wangdu2002]

顶顶之。。。Fcitx开发组和Alpha.gu都辛苦了。。。

[npnufn]

为什么楼主编译的文件体积这么大？我自己在archlinux里编译的必这小一半，就想取消记录模式，也可以在ubuntu中使用，但是fcitx-remote失效了。
编辑配置文件取消记录模式从没成功过

大哥，Arch现在是xz压缩啊，而且，PKGBUILD是直接分析makefile的，而deb的包压缩方式不是xz的，东西也放的比Arch多，当然要大了啊，又不是我故意弄大的。

这个了解。
我指的当然是编译好的二进制文件了。我自己编译的 fcitx 这个二进制文件也是大概1.1M，而archlinux下编译的二进制文件却 500多K，编译其他程序也有类似现象，只是不知道为什么。
倒不是在意体积大小，而是虽然体积差一半，在arch下编译的fcitx却可以正常在Ubuntu中使用……

[sisisimg]

呵呵，终于弄好了

[alpha.gu]

为什么楼主编译的文件体积这么大？我自己在archlinux里编译的必这小一半，就想取消记录模式，也可以在ubuntu中使用，但是fcitx-remote失效了。
编辑配置文件取消记录模式从没成功过

大哥，Arch现在是xz压缩啊，而且，PKGBUILD是直接分析makefile的，而deb的包压缩方式不是xz的，东西也放的比Arch多，当然要大了啊，又不是我故意弄大的。

这个了解。
我指的当然是编译好的二进制文件了。我自己编译的 fcitx 这个二进制文件也是大概1.1M，而archlinux下编译的二进制文件却 500多K，编译其他程序也有类似现象，只是不知道为什么。
倒不是在意体积大小，而是虽然体积差一半，在arch下编译的fcitx却可以正常在Ubuntu中使用……

Arch是i686优化的，Ubuntu应该是386以上电脑都能用吧。
具体的我不清楚啊。