skim居然是kde注销时崩溃的罪魁祸首

Eong

就我所知道的来说，我不会责怪skim。但是我会放弃skim,使用其它程序代替，就这么简单。楼上恐怕一直误会我的意思。我已经说过绝不是贬低skim。
对于一个普通的用户来说，他也不会在乎到底是什么的问题，关键是问题怎么才能快速有效地解决。

fundawang

我没有误会你，我只是建议你将这个问题报告上去。

Eong

To fundawang兄，
我躲开这个bug,是因为我没有这样的能力、时间以及兴趣去解决这个bug,或者如果存在一个让我觉得方便的bug report体制，也许我会很乐意报告这个bug。
用户可以积极地帮助改进skim，但是用户并没有这个义务，做和不做取决于用户。

fundawang

可是这个问题不是skim造成的，而是 Qt 造成的。

Eong

呵呵，
你能证明是QT造成的么？
我不能证明是skim的问题，但是skim和kde或者是QT之间的冲突影响了我使用kde,不管最后应该是QT改进还是skim改进，我所关心的是我所使用的东西是否正常工作，不关心问题的根源，除非我必须从根本上解决它。
从一般的心态来说，用户对skim和kde的协调状况不清楚，kde作为一个大型的应用程序，用户会理所当然地认为是skim不能在kde环境与kde构件正常协同工作，而不是kde没有给skim提供一个正常协同工作的环境。

fundawang

当然可以证明是Qt的问题。通过比对Mandriva、SUSE和Gentoo的Qt包中的补丁就可以知道问题了，而且我这里还有Mandriva工程师的分析报告。

KDE是一个大型程序没有错，可kicker崩溃和它无关，也和skim无关。而是Qt的问题，而且还是Qt打包的问题，与上游的Trolltech也无关。

Eong

嗯，现在我了解他们之间的关系了。非常感谢你这么有耐心。
但是作为一个普通用户的我现在采用的解决措施，仍然是放弃skim，使用fcitx。
你有办法说服我回到skim么？

fundawang

我的目的不是要说服你继续使用skim，而是为了澄清一个事实。

不过，如果你不愿意报告bug的话，也许可以尝试其它发行版打包的Qt、KDE和skim 它们不会使得kicker崩溃

Eong

哈哈。。。。讨论结束了~

lilyerr

顶fundawang的专业精神。
致敬！！！