最近买的最满意的笔记本

其实就是这个 Thinkpad X1 yoga 了。在这之前,其实也经历了不少笔记本……

最早最早的联想天逸……忘了型号。Gateway I43…Asus Zenbook UX31E,Dell XPS 13 老版本,Ideapad yoga 2 pro,Surface Pro 4……回想起来会觉得太败家了……幸好 Surface Pro 4 是卖了个  6 折回血。

总之之前的都各有各的问题。最早的当然都是沉啦。后来就有了超级本,就不想回到砖头了。

Asus 的问题是妈逼电源线插头太脆弱了,老断啊,断了买了新电源再断,感觉哪天就要被电死了。

Dell 没买一个月换了主板……虽然之后就一直用了,后来给老婆用去了用到现在,但是 wifi 似乎也是有毛病的,而且分辨率是比较惨的 1366×768,之前的 asus 是 1600×900 都能看出明显差距了。

所以后来为了分辨率和屏幕弄了 yoga 2 pro,基本是不错,不过蓝牙和 wifi 同时使用网速网络质量都会大幅下降,家里路由器距离远一些就会经常突发慢到暴走。

后来一时鬼迷心窍看了 M$ 发布会之后想要 SP4。Surface Pro 4 主要是驱动问题,严重的问题……M$ 去掉了待机,然而 Linux 不支持 connected standby,但是换用休眠经常唤醒不能。另外就是 wifi 经常时不常死掉, https://bugzilla.kernel.org/show_bug.cgi?id=109681 最开始我汇报到今天都一年多了……一个小时就要重启电脑也是受不了的。

然后,终于让我遇见了 Linux 驱动都没问题的……这台 Thinkpad X1 yoga。wifi 没问题,wwan 没问题,触摸屏没问题,笔也没问题,待机没问题 ´_>` 这么多年就没遇见这么一个没问题的电脑了。感觉之前都活着什么样的地狱里面……

Posted in Linux | Tagged , , , | 5 Comments

DLNA 大法好,蓝牙转发大法也好

笔记本上的视频懒得四处复制了再看,于是 DLNA 拯救你,ps3 media server 一开,找个播放器看就是了…最简易的方案,用 VLC 就好,Android,Sailfish (也是 Android 的 App 啦,毕竟能跑的程序相对有限),Linux 都可以。

因为平时还抢了老婆的 iPhone 用…所以 iPhone 上也费劲找了个播放器。而且果然是付费的靠谱…否则解码都成问题…

耳机只能配两个设备,自己手机一个,笔记本一个,想换配对设备还要进配对模式重新搞,怎么办…iPhone 蓝牙转发到笔记本上……于是就这么凑合着连了三个设备。

不过延迟就比较悲剧,凑合用呗。反正都是为了方便床上看……

Posted in Linux | 4 Comments

休闲玩家的「口袋妖怪·走」的入门心得

总之 Pokémon Go 也是开服几天了,赶时髦玩了一玩,总之是勾引宅男出门锻炼的好游戏。这游戏的教学系统不可谓不烂,进去之后几天下来走了不少弯路,那么记录一下也许可以帮助其他人。

1、精灵捕捉

你以为的 pokemon go 是这样的:

CnPyrCjWYAAYfOa

其实是这样的:

CnNBjtPUEAAstJL

但是不要小看拉达和波波。游戏中等级是十分重要的,升级的途径是获得经验。而获得经验的途径有以下几种:

  • 捕捉精灵(100exp + 10exp 取决于扔球姿势)
  • 获得新精灵图鉴(500exp)
  • 对战(胜利一次好像是100?)
  • 进化(500exp)
  • pokestop(50exp)

进化需要获得这个精灵家族的糖果,糖果的获得方式是:

  • 捕捉(3)
  • 孵化(10-25,可能取决于种类)
  • 放走(说明是传送给博士,1)

拉达进化需要 25,比比鸟进化需要 12。而进化比雕需要 50。想要刷经验的话,拼命捕捉波波和拉达就可以获得大量经验,可不要忽视了。

对战获得的经验其实不是非常可持续性,因为并没有自动回血/复活这样的设定。

另外坐在原地是几乎不可能刷新精灵的,除非周围有人用 lure module 或者自己使用吸引精灵的道具。

我曾经尝试原地并使用吸引精灵的道具,30分钟的时间内只有 4 只,lure module 我坐在原地刷新则奇快。

2、道具

pokestop 刷新时间其实极短(几分钟),找到有多个 pokestop 聚集的地点可以快速刷道具和经验。

hp 0 只能复活,然而这时如果对气绝的精灵使用 power up 则会增加 hp 反而直接活过来,则不能使用复活药回血。复活药回血有时更加划算(50% hp),精灵血多(hp > 40)的时候优先复活,否则优先升级。

3、对战

打不过就跑是很重要的,即使跑了也可以获得经验,而不用浪费 hp 在打不过的精灵上。

4、技能

我查了半天才发现必杀技能是长按释放(未测试)。攻击需要使用加藤鹰之指拼命点屏幕。每种技能频率好像不同,有些频率快的技能(大概多是低攻击力的?)需要拼命点屏才能获得高伤害。闪避躲必杀可能才比较划算。

精灵进化之后技能是会再随机刷新的!获得好技能的未进化精灵大概毫无意义!

技能选择上要注意属性!

5、属性

精灵肯定有个体值差异,并且会影响最大 CP,目前和体重之间的关系不明。然而需要注意的是最大的 CP 也和你自己等级挂钩,所以拼命升级也是很重要的。

不要浪费 Stardust 在低初始 CP 的精灵上,Stardust 是稀缺资源。高初始 CP 的精灵在你高等级之后十分容易刷出。

6、选择精灵

拉达属性实在不够看……比雕还不错,算是初期易于获得的精灵之一,可以容易刷到 500 CP 去战一场。

7、等级的影响

  • 精灵出现种类?似乎有些精灵在我低等级时并不出现。
  • CP 最大值(升一级可以多 power up 1-2 次)
  • 升级赠送道具
  • 野生精灵 CP (我现在很少见到 10 CP 的了……)

8、对战

捡软柿子打,不要浪费 HP 在打不过的人上。例如你有 500 CP 的精灵 1只,其他 5 只都是低 CP,道馆有 200 和 800 的。你打败 200 的就能降低 1000 道馆的进度。每 4000 进度增加一个人。也就是说踢出去一个人,你之后要打的精灵数量就减少。对于我这种当单机玩的人来说是一种节省药品的方式。

刷自己阵营的道馆的空位也可以使用类似方式节省药。占领道馆位置才能刷 20 小时一次的游戏币和 Stardust。

9、阵营选择

本地急冻鸟阵营人最多,从外形上其实可以预测吧,我推测世界上其他地方也是类似…选择人多的还是人少的就见仁见智了。

Posted in 日志 | Tagged | Leave a comment

One bad API in sd-bus

I’m using sd-bus to develop the dbus part for fcitx5, because I’d like to seamlessly support kdbus in the future. (Don’t argue with me about bsd or sth else right now, for now I don’t care about that.)

But one api of sd-bus obviously blows up my mind.

https://github.com/systemd/systemd/blob/09541e49ebd17b41482e447dd8194942f39788c0/src/systemd/sd-bus.h#L428

typedef int (*sd_bus_track_handler_t) (sd_bus_track *track, void *userdata);
int sd_bus_track_new(sd_bus *bus, sd_bus_track **track, sd_bus_track_handler_t handler, void *userdata);

So basically, it’s a wrapper around NameOwnerChanged dbus signal. And let you get notification about when the service disappears (only disappears, yeah).

And it also has capability to track more than one service name by using.

int sd_bus_track_add_sender(sd_bus_track *track, sd_bus_message *m);
int sd_bus_track_remove_sender(sd_bus_track *track, sd_bus_message *m);
int sd_bus_track_add_name(sd_bus_track *track, const char *name);
int sd_bus_track_remove_name(sd_bus_track *track, const char *name);

And you are able to query which name is being tracked via:

unsigned sd_bus_track_count(sd_bus_track *track);
const char* sd_bus_track_contains(sd_bus_track *track, const char *names);
const char* sd_bus_track_first(sd_bus_track *track);
const char* sd_bus_track_next(sd_bus_track *track);

So far so good, yeah?

But if you pay attention to the prototype of sd_bus_track_handler_t, you’ll notice that you won’t be able to get the tracked service name when this handler being called.

Which means you simply can’t use it to track more than one service name, because you can’t distinguish which service actually exits.

If I checked all existing usages of sd_bus_track in systemd, they imply that my impression is correct.

So obviously “tracking multiple name” functionality is totally useless.

So here, this is a good example about how this api should looks like: http://doc.qt.io/qt-5/qdbusservicewatcher.html .

For my own use case, I’ll go back to write my own service tracker with other sd-bus api.

Posted in fcitx development, Linux | Tagged , | Leave a comment

RFC: a new solution to Input Method + Keyboard Layout

This is not related to KDE itself, but I’d like to hear some opinion from keyboard layout users, especially from those who use more than one keyboard layout.

Right now I’m designing a new feature for fcitx (for people who doesn’t know it, it’s an input method framework under Linux), currently called “input method group”. The goal of this feature is to solve the conflict between keyboard layout and input method (mostly conceptually) . It can also solve some other problem, but the original goal is about keyboard layout.

Before I introduce the feature, I’d like to talk about the problem itself first.

People need to type their own language with their keyboard. For most latin character based languages, keyboard layout is a good solution to them, because the number of different characters in their language is small enough to be handled by the keyboard (26 * (1..2)). But in CJK world (Chinese, Japanese, Korean), number of characters are so large (especially for Chinese, number of characters in Chinese is over thousand) that each character can’t be simply mapped to a key on the keyboard. So people invent input method, which basically maps a sequence of key to a limited number of characters and people can select from it.

But if we re-think about the keyboard layout itself, it can actually be considered as a very simple kind of input methods. The only difference is that the mappings from “keys” to “characters” in keyboard layout is much simpler than those in CJK input method. And that’s why keyboard layouts are handled as input method in modern OS, like windows and mac OSX, and ibus/fcitx nowadays.

It looks so far so good, until you remember that keyboard are not only used to type text. Suppose you want to type French and German, and you add them as your input methods. But hey, French layout is azerty and German is qwertz. Your favorite “Ctrl+Z” for undo is at the different position on the keyboard! If you add Chinese pinyin into consideration, it will be even more messed up. Not to mention if you want to use Dovrak layout with Pinyin and but pinyin is forced you to US layout on Windows.

Though keyboard layout can be considered as an input method, it’s actually a mapping from physical keys to virtual keys (and to characters). And regular CJK input method is a mapping from virtual keys to characters. So they should be able to composed arbitrary to serve user’s own need (e.g. Pinyin + Dovrak).

And we previously had a user provided one of his scenerio:

* Kain(fake name, you know) has two keyboards. One is laptop built-in with US layout, which he will use at  home. Another is a usb keyboard, but it’s in fr layout (key printing).
* He usually use Pinyin and Mozc to type Chinese and Japanese.

He want to automatically switch layout when he’s using different keyboard. While X/wayland doesn’t provide “per physical keyboard” layout (I don’t think “real” per physical keyboard layout is useful though, since you’ll still only use one physical keyboard at a time.), I’d like to support such use case and that’s why I invent the concept of “input method group”.

Basically a input method group contains a list of input methods, and has a layout. This layout will be the actual “system” layout. It affects all the hotkey bindings for your desktop. And for Kain’s use case

His configuration will look like this:
* Default group (us layout):
* Keyboard (default), Pinyin, Mozc
*
* Alternative group (fr layout):
* Input methods are the same as default.

And we can listen to udev event, once the keyboard is plugged in, automatically switch to group fr and he can happily type with fr layout.

For regular CJK user, they can stick to one group. For regular keyboard layout users who want old fashion keyboard layout like setup, they can use different groups with single “keyboard” input method.

And I’d also like to support multiple layout based input method in same group. With help with xkbcommon, this can be actually done. So you can have “Keyboard (US English)” and “Keyboard (Arabic)” in same group, but your system layout will always be US layout even you’re using “Keyboard (Arabic)” to type.

And I think it can also help users who only use some specific language at work and another language at home. And I think is fit quite well with KDE’s activities, e.g. bind different activities with specific input method group. After all, if you want 3 different input methods, but only two of them at a time, it would be easier to switch input method between 2 instead of 3.

What do you think of it? I’d like to make this feature supports the needs of both keyboard layout users and input method users. Do you have any other use case related that you want to share?

Posted in KDE, Linux | Tagged | 11 Comments