Ubuntu中文论坛

pjincz 写了：

cavendish 写了：

pjincz 写了：

月下叹逍遥 写了：大小怎么样？依赖多么？

大小约80mb (仅wps wpp， et因为进度问题跟不上)
依赖方面，qt依赖什么，我们就依赖什么。
另外由于一些客观原因，我们的qt库是自带的，不能使用标准qt库。
（因为我们扩充了qt库很多功能，例如路径渐变等，官方qt版本已经冻结了特征，但是我们没有这些特征又无法工作）。

对库的修改，可否开放？
另外是否把feature request提交到5.0了呢？

我们对库的修改完全是本着公开的原则的，但是由于现在一些现状（比如说不知道该放哪之类的问题，也没有相关的站点）因此没有外部下载链接。
（但是只要有人索要，我们不会拒绝的。PS：虽然我们也买了Qt商业授权，原则上是可以不公开的。）
另外如果可以的话，我们希望这些特征被合并回qt，这样也能减少我们的维护负担。

zhcj 写了：

xep007 写了：这个问题不是以前解决了吗。只要在工具-》选项-》视图里去掉“使用硬件加速”不就行了吗。

确实如此！！！还真不知道有这个选项。不过表格丢失呢？
在xep007提示下，修改设置后，在libreoffice中显示如下（比前面的要强多了）：

snap41.png

wth0911 写了：

zhcj 写了：

xep007 写了：这个问题不是以前解决了吗。只要在工具-》选项-》视图里去掉“使用硬件加速”不就行了吗。

确实如此！！！还真不知道有这个选项。不过表格丢失呢？
在xep007提示下，修改设置后，在libreoffice中显示如下（比前面的要强多了）：

snap41.png

将表格设置为显示边框，LO认为你这个表格的设置是不显示边框

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）也不行。

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

zhcj 写了：

snap12.png

这是libreoffice的幻灯片效果

snap15.png

这是永中的幻灯片效果
不知道wps幻灯片的效果如何？

guokw 写了：http://www.ultraedit.com/downloads/uex.html

能和ultraedit 一样选择在某个操作系统下的安装程序就好了

zhanshime 写了：

zhcj 写了：

snap12.png

这是libreoffice的幻灯片效果

snap15.png

这是永中的幻灯片效果
不知道wps幻灯片的效果如何？

作为一个菜鸟,看来你应该对libreoffice是几乎一无所知,而你所提的问题,只要你搜一下就会解决,啥都不懂就乱发帖,给libreoffice的对比贴在网络上造成了很大的影响,希望你能专门发个道歉贴,宣扬国产应该,但不能这么误解libre
可能你是无心的,但影响挺大,希望你正视

枫叶饭团 写了：WPS如果用自己的非标准库的话，那就是说我不用在机子上装标准QT库了吧~

pjincz 写了：

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

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

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