夏娜完结纪念

(无太多剧透,可放心食用)

入宅这么长时间投入最多的是夏娜和Type-Moon,在还只有精品堂和珊瑚的年代,一直收夏娜的小说到16卷。16卷的结尾是一个让人纠结的结尾,当年的bbs上有个Shana的ID的签名档里面是16卷的片段,那时还没收小说……难以想象是怎样的情节发展才出现了这样的场景。

“我,会歼灭你。”

少年和少女都为了各自的信念而战斗着。

整部灼眼的夏娜其实只是少年和少女的成长史而已,而且没有落入以往烂尾的结局,简单来说不是“少年和少女继续这样幸福的生活下去了”,而是“少年为了和少女生活在一起而发生的故事”。

最近准备把当年的神一般的“内蒙古人民出版社”的轻小说逐渐都换成天闻角川的(效率看起来是一月一卷……勉强属于有生之年系列的中文版了,大概明年年初可以收到中文版的结局吧?)。于是前几天重温了新买到的前三卷。

我是经常会重新看过买过的书的,大概总是能发现一些新的东西。大概是处于某种懒得拿挤在一起的书的原因,夏娜我确实没有怎么重新看过。所以这基本上是几年来头次重新看夏娜的小说。

文艺青年式的“没有当年看书的心境”这种事情从来就不会发生在我等普通二逼青年身上。我更容易从曾经的书中找到不一样的感动。现在回过来看当初的故事,两个人笨拙的从认识到互相理解,相爱的故事有时经常让我想起从前的事。

悠二和夏娜恋爱终于有了有了Happy Ending,真是可喜可贺可喜可贺。我也要向着我的Happy Ending更加努力了。

Posted in 日志 | 7 Comments

My CMake Tutorial 5

这篇是教你如何用cmake和pkg-config搅基。

关于这个系列的宗旨,就是用我写过的项目里面用的那屁点CMake给大家看看,有些技巧我可能还自鸣得意,很有和大家分享的冲动。你想要找以前的文章,就去点下分类里面的cmake就好。

cmake 内置了 pkgconfig支持,想要用的话只需要

find_package(PkgConfig)

里面内置的命令是这样的

pkg_check_modules(LIBPINYIN "libpinyin >= 0.5.0")

前面是变量名的前缀,一般来说会生成以下变量 <VAR>_FOUND,<VAR>_INCLUDE_DIRS,<VAR>_LIBRARY_DIRS,<VAR>_LIBRARIES。

这就是通常的用法,非常的简单。

以下是我常用的trick之一,实际上是用了一个内部命令,不过实在太好用了。

_pkgconfig_invoke("libpinyin" LIBPINYIN EXECPREFIX "" "--variable=exec_prefix")

简单来说,就是在pkgconfig的文件中经常会有定义一些变量,不过不幸的是CMAKE并没有直接获得这些变量的方法,于是就用了以上的手段。

具体参数是,pkgconfig配置名,变量前缀,变量名,空字符串,pkgconfig参数。

这样就可以顺利得到LIBPINYIN_EXECPREFIX这样的变量名啦。

 

Posted in cmake | Tagged | 5 Comments

My CMake Tutorial 4

这篇的目的是教你 CMake 如何和 Qt 搅基。

总所周知的是,CMake和Qt自古就搅基搅的很深,CMake自带的find_package脚本其实蛮少,不过其中确绝对会有 Qt 的和KDE的,即使所引用的KDE的cmake脚本其实在KDE Libs里面。

说是介绍,其实主要是介绍一些在QtMacro.cmake里面的宏,cmake的自带脚本都在 /usr/share/cmake-<version>/Modules 下面,可以自行查看。

在开始之前,先来说说Qt的moc。Qt的信号和槽的机制其实大部分是靠代码生成的,Qt自带了一个名为moc的工具,负责解析C++的源文件,并且生成相关的代码。moc是meta object compiler 的缩写,关于moc都干了什么可以自己放狗去搜。

qt4_wrap_cpp(<varname> <header file(s)>)

用来把头文件生成moc文件,并且对应的文件名写到<varname>里面去。

这样你可以在增加target的时候直接使用<varname>和你的cpp文件,这样就可以一起编译了。

当然对于KDE来说,有更方便的automoc,这里按下不表。

Qt DBus

DBus 的接口是通过xml文件指定的,qt也提供了按照DBus的introspect的xml文件直接生成代码的方法,具体来说有两边,一个是adaptor,一个是interface。adaptor是作为实现dbus那一方的,而interface则是调用dbus那一方的。

https://github.com/fcitx/kcm-fcitx/blob/master/src/CMakeLists.txt

例如这里

QT4_ADD_DBUS_INTERFACE(kcm_SRCS
    org.fcitx.Fcitx.InputMethod.xml
    org.fcitx.Fcitx.InputMethod
)

最后就会生成 org.fcitx.Fcitx.InputMethod.h 这个文件,然后直接include就可以直接使用这个类啦。

类似的adaptor则是相当于注册服务的那一方。

Posted in cmake | Tagged | 3 Comments

坑:QCloud

https://github.com/csslayer/qcloud

Posted in Linux | 2 Comments

做个 Free Lancer 式的 KDE 开发者

开发总是蛮难的一件事情,尤其是当你面对着一个非常大的项目的时候,例如KDE。

经常会有人问到:“啊,我懂一点Qt,也懂C++,然后也挺闲的,想要给KDE开发点什么,但是不知道该干什么。”

这种问题在邮件列表上时有出现,经常一个回答就是,嗯,去找点Bug来修吧。其实对于常驻的开发者们来说,这个回答是十分make sense的,因为他们也不了解你的热情究竟如何,但是修复个Bug,即使你将来失去兴趣很快离开了,也不致于导致留下了一些无人维护的代码。修复个Bug,和写个新功能带来的成就感可是没法比的。

那么如何给自己一些动力呢?那就来修复你讨厌的Bug吧!或者找一些你喜欢的小功能来实现。我的KDE开发之路是从kimpanel开始的,话说回来,我对于界面的原生程度是无比执着的,也导致了我很喜欢kimpanel这个小东西,不过之前的作者已经离开很久了(由于他个人原因),也有很多Bug没有修复。于是我借着机会把它给重写了。当然为了进行提交,我顺带还申请了KDE的开发用的账号。

这个账号的权限可是不老小的,可以对KDE的任意代码进行修改,于是从这里开始我偶尔就会找一些小问题来解决一下。当然最好还是采用Reviewboard,因为你对于其他的项目的了解并不一定太深,让主要维护者来review一下总是好的。不过偶尔我也会干点直接提交的事情,如果我十分确定的话。

总之概括起来的话……当年Linux的评价就是有无数的眼睛盯着代码,于是偶尔自己也可以成为这样的眼睛啰。了解了更多的代码之后也可以方便自己加入到开发中去。

Posted in KDE | Tagged | 4 Comments