ˊ_>ˋ yyc 你效率太低啦……
https://github.com/fcitx/fcitx/tree/wayland
小鸟，没看到什么意思？难道是在说那个编辑器的故事？
_(:3」∠)__
看来wayland支持快出来了，不知道什么时候最终用户才能切换到pure waylandˊ_>ˋ。话说最近想读fcitx的源码，结果被vim的taglist以及ctags的配置和用法弄得心烦意乱，自己果然还是太菜了……
@Boild 用IDE去哪那么多破事……
突然，想到，为什么我没见过一种中文输入法是像英文补齐一般自然呈现的呐。
@jiero 什么意思？
@csslayer 果然还是输入法面板感觉怪怪的，但果然希望的完全融合（候选项目跟随）是太困难，如果是主题色调（取自正在文本输入的背景）探测会不会好些。
另外我在思考：横排时，侯选项内容跟在编号之后。这好不好？
OCR功能需求？或者更镶入。
想多了。打住，躺床上然后跳起。
@jiero ……说话前你自己脑内 play 一下……
@jiero 1. 候选框的跟随是几百年前就有了的 2. 颜色的话, 先不说技术上的问题 2.1. 用当前的背景跟现在正在输入的文本框里面的内容混在一起, 而且不同程序有不一样的背景, 感觉上只会让人找候选框 / 看清候选框里的内容变得困难. 2.2 另外还有单行输入框 / 候选框大小超出输入框范围的情况, 甚至有的输入法的跟复杂的界面需求 3. 横排的时候现在候选内容不就是跟在编号之后么? 4. 这跟 OCR 啥关系 (且不说技术问题…) 获取背景颜色还差不多吧….. 想不那么唐突的话, 用个带背景模糊的淡色主题输入框 (比如说默认的 kimpanel) 不就挺好
@yyc
同行跟随，意思就是好像补全一般直接文本内。 如果看候选框内内容困难，看文本内容也同样困难？ 候选内容应该在编号之前吧。
@jiero 本来 preedit 不就已经干你要的这个事情了，我不知道你在纠结什么，想解释清楚请画图。
编号是为了提示应该按哪个，一般编号占的位置已经足够小，在视线扫过去的时候就可以显示了。
提建议不要想当然，自己改代码然后耍个几天再下结论。
后面是输入框 『一气呵成还不得要领』 http://i.imgur.com/n0Rzlti.jpg 嗯，我还没学代码。
@jiero 太宽的时候出了屏幕怎么办？太宽了超过了当前输入框的大小怎么办？（实现上没法知道当前输入框有多大）拼音长度大于3比汉字长呢？在屏幕顶端打字显示不了拼音呢？微软拼音输入法的那个新体验模式在出bug的时候和你的图有那么点像，实际用起来几乎没法用，随便就因为输入框而挡到正在输入的字了。
把编号写在后面实在是太糟糕的设计，违反正常直觉，稍微好点的办法是省略第一个的编号。
@jiero 对于我看的出来的几点 1. 标号放到后面 表示那个标号是给人选的, 我好想没听说过什么东西 (在从左到右写的语言中) 有把标号放在右边的习惯 2. 省略第一个标号 没觉得这个有啥特别的 3. 改变选字框跟被输入位置/预编辑文本之间的相对位置 两个里面选字框都放在了被输入的文本的后面, 除了让选字框更容易超出边界以外没看出来啥优势 4. 你的选字框用谁的颜色? 现在的界面的预编辑就是”自然呈现”的. 甚至在大部分的时候(没有手误和非常用词的时候)都是完全不需要看选字框的. 你这两个里面都完全省掉了预编辑. 如果说选字框想用输入框的颜色 (首先这是几乎不可能的不用想了)后面的文字看起来会非常不突出. 如果用自己的颜色, 没看出来这哪里”自然”了.
唯一需要所谓的 “自然呈现” 的是输入的结果, 在选字之前这就应该指的是输入法认为的最可能的输入的结果, 也就是第一个候选词. 而最 “自然” 的 “呈现” 的唯一方式是通过客户端的支持用预编辑嵌入到输入文本里面. 所以说现在的界面已经做到了将最需要 “自然呈现” 的东西 “自然” 的 “呈现” 出来. 拼音 (或者其它的直接输入结果) 和选字列表虽然我不好说哪个更重要一点, 但是拼音本身一般是不可能占据太大的空间的 (相对于选字结果来说), 所以说优先吧拼音放在离光标最近的地方可以让两者都处在方便看到的地方. 至于这个输入框的位置, 对于拼音来说, 放在当前输入文字的正上 / 下放对于横排的语言来说是最自然的 (方便对比). 而选字列表自然就是放在那个的旁边, 具体位置当然各个输入法的实现有细微的差别不过个人感觉差别不大. 就实现来说, 如果被输入程序能支持绘制复杂的候选列表当然会显得 “自然”, 不过这个选字框本来就不是个 “自然” 的东西 (没有个自然的整合的地方), 各个带有补全的程序除了确信当前光标下面没有东西的以外 (命令行补全) 也没有一个是在输入框里面整合候选列表的, 加上让客户不必要的添加更多的输入法支持只会增加 bug 没有在这方面为了只有坏处的整合减少稳定性的必要.
@csslayer 出了屏幕自动换到第二行，高度不够自动变换拼音到下面。拼音只是提示输入。 我似乎是把 正在输入的字 移动到了输入框内，这就是我说的自然的意思。
编号放后面违反直觉，糟糕？视觉诱导不够？我的测试 距离或提示符更能 将序号和候选项目联系在一起。 ch yi 差异 1・ 创意 2・ 初一 3・ 拆以 4・ 衬衣 5・
从左到右读，首先想到的是不是我要得字，然后是什么号。那么是放在后面才是正常的思维顺序或者直觉顺序。
@jiero 想法是即使是美好的现实是残酷的，说你违反直觉你应该去想想世界上其他文档是不是都把标号放在前面，特立独行并不一定能带来最好的效果。讲话也一般都是讲，第一，XXXXX，第二，XXXXX。
话说fcitx正在输入的字实际上现在不也已经显示在输入框里面了吗……你到底有没有用fcitx啊。
以及你那个模式在输入当中插入文字就会变成糟糕的设计。因为光标前后其实都有字，你把你的输入框放在那里的话就会盖住光标位置后面的字。而查看同一行是比较common的需求。
@jiero P.S. 候选框嵌入到输入框里面难看清的意思是难以跟正文区分. 输入框里的文本看起来困难是当然的! (否则就没必要有搜索功能了) 从没有高亮的文本找个字当然是非常困难的, 至少比从一个突出显示的窗口中找困难的多. 换句话说, 不管是输入法的候选词列表还是任何自动补全需要的都是在一个不影响当前输入的突出并且尽可能贴近当前光标的位置显示一个明显的候选列表, 如果 “自然呈现” 了就完全没有意义了.
@yyc ˊ_>ˋ preedit 可以背景高亮……（默认也是用下划线的啦）
@csslayer 这跟 preedit 高亮有啥关系…. 我说的应该只是preedit的位置是最自然的 + 候选列表需要高亮 (于是没有嵌入的意义)
@csslayer
平时的流程： 看到 1. 我是*， 思维返回 选1。 1. *定理 ；我就去 1. 找 *定理。 以上是输入法和平时导航的差异吗？ 看句子末尾，看标点吗？看菜单，先看后面的价格，还是你会喊菜号？——取决于你将数字当成什么，哪种反应快或者识别度高。 看书的目录，页码是在前还是在后？你先找分段号还是页码？ 序号看作什么作用是这里的分歧： 平时说先看标号？你是将用标号作为内容（比如标题）寄存，迅速找到那个位置。输入时正好反过来不是？ 平时文章我大多用无序排列，统计一下无序列表的多还是有序列表的多？这里序号仅仅是标记，选择号码不牵扯多少逻辑顺序。
插入时是看后面是比较common的需求，如果，只是如果，我的意思一直是输入框能把后面的文本推开。
做事，总有依据不同观点的观点：“在输入当中插入文字就会变成糟糕的设计。”preedit放入了输入框，确实带不来修改使用上的便捷性。临事终有所取舍。支持了鼠标中键粘贴，就不能中键移动画面。
@jiero 1、现实是并非所有程序都支持 preedit，没有preedit就不能推开后面的文字 2、把后面的文字推开也并非完美，相反正好违背了你所谓的自然，因为你把候选就放在了后面的字的前面。而后面的候选并非都是你要插入的字。
菜单把价格靠右本身的意义我能想到的有 1、方便比较菜价，2、把菜价和菜名分开使人在点菜的时候不会更加关注菜价……
章节就更明显了，让一个人去查的时候别人告诉他第几章第几节，而不会告诉他第几页，因为页码是无意义额数字，而章节号是有意义的（整体书的逻辑顺序，在目录中连续排列）。在查找章节的时候更不需要关注其他章节的页码。 候选词横向排列的话可能每个词的长短不一，不能按照物理上的距离直接跳过标号判断到底是第几个词，因此反而是必要的。
嗯。还是人视角不同，当专注输入需要输入的文字时，我一般不看前后。
关于编号前后 … 我怎么见到人们很少说章节号，都是看页码。。。根本不需要在意是哪个章节，到了看到那一页就知道了。。。
@yyc 候选列表需要高亮，目前就是高亮的，我没明白是何种差异。对比都亮了和都没亮？
需要和正文区分有好多视觉元素可用，怎样做先不说。。。
@jiero 那我就奇怪了, 你一个劲的说个自己都说不清楚的”自然呈现”到底是啥?? 看起来跟输入框里面的文字一样还是不一样??? 不一样的话跟现在有区别么???? 一样的话你还想让人看清么?????
yyc 问题，还没说方案，我感觉不自然，焦点都进入输入法了。好吧，中文输入一直是这样的。淡化算是设计角度。
那么就是不一样，但感觉一样。
不一样：仍然千种可能干重方式产生区别。一样的话，可以用其他元素分清。比如 ・放两字之间，输入框上或下的拼音或者拼音。
@jiero 不要干讲，拿记事本画笔在截图的基础上截图画mockup 模拟上面提到的多个场景下的输入。 想要说服我们就拿出行动来，我们现在的态度依然是彻底反对。
嗯，融入看来做不到。因为，必须选字，字体大小方面无法控制。
至于放前还是放后。。。这个真的口说，加实验比画图重要。。。 http://i.imgur.com/NXSNlXQ.png
能指导下哪里的代码是负责这个功能的？代码不懂，但是这个应该只是看懂英文就能改的。
@jiero 嵌入输入框就是你懂机器码也改不了 classicui 的话在这里[1], 是不是看的懂英文就能改我是不知道了
[1] https://github.com/fcitx/fcitx/blob/master/src/ui/classic/InputWindow.c
嗯。也是找到这个文件，确实不懂如何更改。
@jiero 我真的闲得没事了。说这实话，真盲打的话，其实不在乎候选框什么的。别的码没怎么学过，五笔的话，如果一直盯着预编辑，候选框什么的，别说一分钟120字，连一分钟30字都困难。其实一般写文章，不是倚马千言的那种，一分钟超过60字是很困难的，因为你要斟酌字句。不过输入还是要快一点的，因为输入慢下来会打断思路。
问题是，就算你的新界面可能增加输入的速度，但是，对多数用户来说，就是不友好的。当然所的输入法，至少是默认都用这样子界面的时候，改成你那样子只能让用户困惑。而且，假如你一分钟只能击键不到60下，你觉得，你真的在乎那点可能省下的时间吗？假如你真的在乎时间，为什么不去学速记呢？
另外，理论上，只要前两个字符离得足够近，前后顺序其实是没有关系的。因为经过很短暂的训练后，人脑是会自动略掉这点不同的。
最后，我推荐你把输入法的候选框调成垂直排列。
@csslayer 我觉得这位有这样的胡思乱想，可能是因为fcitx在通过不同的色彩交错区别候选词时，序号的颜色号后一个候选词一样，而没跟与其对应的候选词保持一致。但很奇怪他给的图片里，他的fcitx又不是那样的。
@pingz 嗯，你是闲着没事了。
感觉是标点 . 现在做视觉导向，如果取消掉 变 1 ** 2 ** 3 ** 肯定乱了。 如果不用标点那么 1** 2** 3** 或者 **1 **2 **3
请问什么时候才能把Google Code那边的Issue 637（OpenCC的-c参数问题）做一下，一直等这个功能很久了……
@Anon ˊ_>ˋ 简单来说我不想做……如果一个词的转换之后的读音和原来不同的话就很难控制你到底输入的内容是什么
你打服务器 结果出来的是 伺服器 ，我觉得是难以接受的。更别提如果两个词的字数不一样了。
特别是你要是分别打 服 务 器 三个字出来的还是服务器
@csslayer 但是在OpenCC官网的在线转换功能里面有个“地域用词转换”的选项，单独关掉就没问题了啊？
@jiero 编号位置的问题：
也许你想当然的认为顺着视线走的方向就是最“自然”的，其实根本不是这个样子，有时候直觉顺序恰恰就不是线性的。对于从左往右写的文字，直觉情况下，阅读某一个候选项时，眼睛其实默默的做了两件事情：第一，定位到候选项的第一个字；第二，往右读——但不是一个字一个字地读，这是一个关键问题。一般人都不会逐字读完一个候选项，而是瞥一眼大概 + 脑补来判断是不是自己需要的东西，哪怕对于单字都是直接瞄一下粗略外形就判断了，所以当你差不多知道这个候选项是什么东西的时候，视线并没有移到最右边，甚至可能根本就原地不动，但这时大脑已经认为选项读完了，于是直接切换为解决下一个问题的模式，就是确定要按哪个数字，所以眼睛就会开始寻找这个数字。正是因为直觉中“列表”的编号在第一个字的左边，所以视线此时就会条件反射地迅速跳到第一个字再往左一点的位置，而且不管候选项多长，视线总是可以瞬间回到那个点，这是因为大脑在潜意识中已经知道这个位置在哪里，所以就直接跳过去了。可是如果编号在右边的话，鉴于候选项长短不一，导致大脑其实并不知道他的确切位置究竟是在哪里，于是视线就只能往右扫而不能直接跳，因为乱跳的话会漏过那个编号，这个过程真心是很慢的。况且由于存在编号在左边的直觉，自然也要费点力气克服条件反射，那就更坑爹了。
顺便说下，我一直是把默认的五候选改成三候选的，这种情况下完全可以连编号都不要，因为人对位置的粗略概念就是左、中、右，正好三个位置，而且三个候选差不多正好符合视线宽度。个人觉得三候选情况下把首选项放中间并配合首选项颜色标记会更好——貌似这个是当初拼音加加的设计？另外 kimpanel 的编号颜色问题，我也确实觉得有点不合适。
每个人都是看自己的习惯。实际看来细微差异是有的。
跳读不会过编号，左右方案都是用空格分隔候选项。
虽然短句我是可以从右向左读（irc习惯各种东西放右面）编号是啥我多数没看，因为 空格大概就是了。 寻找的时候，我确实经常做减法。因为很多情况第一个字是相同的，我真的是跳读，第二个字开始看。根本编号靠近的就是下一个，所以要 减一。
测试何不测试？
我还是没懂到哪些代码定义这个。
@csslayer 之前没@到你，一直到现在都没见有答复，现在你怎么看？
Your email address will not be published. Required fields are marked *
Comment *
Name *
Email *
Website
Save my name, email, and website in this browser for the next time I comment.
Δ
This site uses Akismet to reduce spam. Learn how your comment data is processed.
小鸟，没看到什么意思？难道是在说那个编辑器的故事？
_(:3」∠)__
看来wayland支持快出来了，不知道什么时候最终用户才能切换到pure waylandˊ_>ˋ。话说最近想读fcitx的源码，结果被vim的taglist以及ctags的配置和用法弄得心烦意乱，自己果然还是太菜了……
@Boild 用IDE去哪那么多破事……
突然，想到，为什么我没见过一种中文输入法是像英文补齐一般自然呈现的呐。
@jiero 什么意思？
@csslayer
果然还是输入法面板感觉怪怪的，但果然希望的完全融合（候选项目跟随）是太困难，如果是主题色调（取自正在文本输入的背景）探测会不会好些。
另外我在思考：横排时，侯选项内容跟在编号之后。这好不好？
OCR功能需求？或者更镶入。
想多了。打住，躺床上然后跳起。
@jiero ……说话前你自己脑内 play 一下……
@jiero
1. 候选框的跟随是几百年前就有了的
2. 颜色的话, 先不说技术上的问题
2.1. 用当前的背景跟现在正在输入的文本框里面的内容混在一起, 而且不同程序有不一样的背景, 感觉上只会让人找候选框 / 看清候选框里的内容变得困难.
2.2 另外还有单行输入框 / 候选框大小超出输入框范围的情况, 甚至有的输入法的跟复杂的界面需求
3. 横排的时候现在候选内容不就是跟在编号之后么?
4. 这跟 OCR 啥关系 (且不说技术问题…) 获取背景颜色还差不多吧….. 想不那么唐突的话, 用个带背景模糊的淡色主题输入框 (比如说默认的 kimpanel) 不就挺好
@yyc
同行跟随，意思就是好像补全一般直接文本内。
如果看候选框内内容困难，看文本内容也同样困难？
候选内容应该在编号之前吧。
@jiero 本来 preedit 不就已经干你要的这个事情了，我不知道你在纠结什么，想解释清楚请画图。
编号是为了提示应该按哪个，一般编号占的位置已经足够小，在视线扫过去的时候就可以显示了。
提建议不要想当然，自己改代码然后耍个几天再下结论。
后面是输入框 『一气呵成还不得要领』 http://i.imgur.com/n0Rzlti.jpg
嗯，我还没学代码。
@jiero 太宽的时候出了屏幕怎么办？太宽了超过了当前输入框的大小怎么办？（实现上没法知道当前输入框有多大）拼音长度大于3比汉字长呢？在屏幕顶端打字显示不了拼音呢？微软拼音输入法的那个新体验模式在出bug的时候和你的图有那么点像，实际用起来几乎没法用，随便就因为输入框而挡到正在输入的字了。
把编号写在后面实在是太糟糕的设计，违反正常直觉，稍微好点的办法是省略第一个的编号。
@jiero
对于我看的出来的几点
1. 标号放到后面
表示那个标号是给人选的, 我好想没听说过什么东西 (在从左到右写的语言中) 有把标号放在右边的习惯
2. 省略第一个标号
没觉得这个有啥特别的
3. 改变选字框跟被输入位置/预编辑文本之间的相对位置
两个里面选字框都放在了被输入的文本的后面, 除了让选字框更容易超出边界以外没看出来啥优势
4. 你的选字框用谁的颜色?
现在的界面的预编辑就是”自然呈现”的. 甚至在大部分的时候(没有手误和非常用词的时候)都是完全不需要看选字框的. 你这两个里面都完全省掉了预编辑. 如果说选字框想用输入框的颜色 (首先这是几乎不可能的不用想了)后面的文字看起来会非常不突出. 如果用自己的颜色, 没看出来这哪里”自然”了.
唯一需要所谓的 “自然呈现” 的是输入的结果, 在选字之前这就应该指的是输入法认为的最可能的输入的结果, 也就是第一个候选词. 而最 “自然” 的 “呈现” 的唯一方式是通过客户端的支持用预编辑嵌入到输入文本里面. 所以说现在的界面已经做到了将最需要 “自然呈现” 的东西 “自然” 的 “呈现” 出来. 拼音 (或者其它的直接输入结果) 和选字列表虽然我不好说哪个更重要一点, 但是拼音本身一般是不可能占据太大的空间的 (相对于选字结果来说), 所以说优先吧拼音放在离光标最近的地方可以让两者都处在方便看到的地方. 至于这个输入框的位置, 对于拼音来说, 放在当前输入文字的正上 / 下放对于横排的语言来说是最自然的 (方便对比). 而选字列表自然就是放在那个的旁边, 具体位置当然各个输入法的实现有细微的差别不过个人感觉差别不大. 就实现来说, 如果被输入程序能支持绘制复杂的候选列表当然会显得 “自然”, 不过这个选字框本来就不是个 “自然” 的东西 (没有个自然的整合的地方), 各个带有补全的程序除了确信当前光标下面没有东西的以外 (命令行补全) 也没有一个是在输入框里面整合候选列表的, 加上让客户不必要的添加更多的输入法支持只会增加 bug 没有在这方面为了只有坏处的整合减少稳定性的必要.
@csslayer 出了屏幕自动换到第二行，高度不够自动变换拼音到下面。拼音只是提示输入。
我似乎是把 正在输入的字 移动到了输入框内，这就是我说的自然的意思。
编号放后面违反直觉，糟糕？视觉诱导不够？我的测试 距离或提示符更能 将序号和候选项目联系在一起。
ch yi
差异 1・ 创意 2・ 初一 3・ 拆以 4・ 衬衣 5・
从左到右读，首先想到的是不是我要得字，然后是什么号。那么是放在后面才是正常的思维顺序或者直觉顺序。
@jiero 想法是即使是美好的现实是残酷的，说你违反直觉你应该去想想世界上其他文档是不是都把标号放在前面，特立独行并不一定能带来最好的效果。讲话也一般都是讲，第一，XXXXX，第二，XXXXX。
话说fcitx正在输入的字实际上现在不也已经显示在输入框里面了吗……你到底有没有用fcitx啊。
以及你那个模式在输入当中插入文字就会变成糟糕的设计。因为光标前后其实都有字，你把你的输入框放在那里的话就会盖住光标位置后面的字。而查看同一行是比较common的需求。
@jiero
P.S.
候选框嵌入到输入框里面难看清的意思是难以跟正文区分.
输入框里的文本看起来困难是当然的! (否则就没必要有搜索功能了) 从没有高亮的文本找个字当然是非常困难的, 至少比从一个突出显示的窗口中找困难的多. 换句话说, 不管是输入法的候选词列表还是任何自动补全需要的都是在一个不影响当前输入的突出并且尽可能贴近当前光标的位置显示一个明显的候选列表, 如果 “自然呈现” 了就完全没有意义了.
@yyc ˊ_>ˋ preedit 可以背景高亮……（默认也是用下划线的啦）
@csslayer 这跟 preedit 高亮有啥关系…. 我说的应该只是preedit的位置是最自然的 + 候选列表需要高亮 (于是没有嵌入的意义)
@csslayer
平时的流程：
看到 1. 我是*， 思维返回 选1。
1. *定理 ；我就去 1. 找 *定理。
以上是输入法和平时导航的差异吗？
看句子末尾，看标点吗？看菜单，先看后面的价格，还是你会喊菜号？——取决于你将数字当成什么，哪种反应快或者识别度高。
看书的目录，页码是在前还是在后？你先找分段号还是页码？
序号看作什么作用是这里的分歧：
平时说先看标号？你是将用标号作为内容（比如标题）寄存，迅速找到那个位置。输入时正好反过来不是？
平时文章我大多用无序排列，统计一下无序列表的多还是有序列表的多？这里序号仅仅是标记，选择号码不牵扯多少逻辑顺序。
插入时是看后面是比较common的需求，如果，只是如果，我的意思一直是输入框能把后面的文本推开。
做事，总有依据不同观点的观点：“在输入当中插入文字就会变成糟糕的设计。”preedit放入了输入框，确实带不来修改使用上的便捷性。临事终有所取舍。支持了鼠标中键粘贴，就不能中键移动画面。
@jiero
1、现实是并非所有程序都支持 preedit，没有preedit就不能推开后面的文字
2、把后面的文字推开也并非完美，相反正好违背了你所谓的自然，因为你把候选就放在了后面的字的前面。而后面的候选并非都是你要插入的字。
菜单把价格靠右本身的意义我能想到的有 1、方便比较菜价，2、把菜价和菜名分开使人在点菜的时候不会更加关注菜价……
章节就更明显了，让一个人去查的时候别人告诉他第几章第几节，而不会告诉他第几页，因为页码是无意义额数字，而章节号是有意义的（整体书的逻辑顺序，在目录中连续排列）。在查找章节的时候更不需要关注其他章节的页码。
候选词横向排列的话可能每个词的长短不一，不能按照物理上的距离直接跳过标号判断到底是第几个词，因此反而是必要的。
@csslayer
嗯。还是人视角不同，当专注输入需要输入的文字时，我一般不看前后。
关于编号前后
… 我怎么见到人们很少说章节号，都是看页码。。。根本不需要在意是哪个章节，到了看到那一页就知道了。。。
@yyc 候选列表需要高亮，目前就是高亮的，我没明白是何种差异。对比都亮了和都没亮？
需要和正文区分有好多视觉元素可用，怎样做先不说。。。
@jiero
那我就奇怪了, 你一个劲的说个自己都说不清楚的”自然呈现”到底是啥?? 看起来跟输入框里面的文字一样还是不一样??? 不一样的话跟现在有区别么???? 一样的话你还想让人看清么?????
yyc 问题，还没说方案，我感觉不自然，焦点都进入输入法了。好吧，中文输入一直是这样的。淡化算是设计角度。
那么就是不一样，但感觉一样。
不一样：仍然千种可能干重方式产生区别。一样的话，可以用其他元素分清。比如 ・放两字之间，输入框上或下的拼音或者拼音。
@jiero 不要干讲，拿记事本画笔在截图的基础上截图画mockup
模拟上面提到的多个场景下的输入。
想要说服我们就拿出行动来，我们现在的态度依然是彻底反对。
嗯，融入看来做不到。因为，必须选字，字体大小方面无法控制。
至于放前还是放后。。。这个真的口说，加实验比画图重要。。。
http://i.imgur.com/NXSNlXQ.png
能指导下哪里的代码是负责这个功能的？代码不懂，但是这个应该只是看懂英文就能改的。
@jiero
嵌入输入框就是你懂机器码也改不了
classicui 的话在这里[1], 是不是看的懂英文就能改我是不知道了
[1] https://github.com/fcitx/fcitx/blob/master/src/ui/classic/InputWindow.c
嗯。也是找到这个文件，确实不懂如何更改。
@jiero 我真的闲得没事了。说这实话，真盲打的话，其实不在乎候选框什么的。别的码没怎么学过，五笔的话，如果一直盯着预编辑，候选框什么的，别说一分钟120字，连一分钟30字都困难。其实一般写文章，不是倚马千言的那种，一分钟超过60字是很困难的，因为你要斟酌字句。不过输入还是要快一点的，因为输入慢下来会打断思路。
问题是，就算你的新界面可能增加输入的速度，但是，对多数用户来说，就是不友好的。当然所的输入法，至少是默认都用这样子界面的时候，改成你那样子只能让用户困惑。而且，假如你一分钟只能击键不到60下，你觉得，你真的在乎那点可能省下的时间吗？假如你真的在乎时间，为什么不去学速记呢？
另外，理论上，只要前两个字符离得足够近，前后顺序其实是没有关系的。因为经过很短暂的训练后，人脑是会自动略掉这点不同的。
最后，我推荐你把输入法的候选框调成垂直排列。
@csslayer 我觉得这位有这样的胡思乱想，可能是因为fcitx在通过不同的色彩交错区别候选词时，序号的颜色号后一个候选词一样，而没跟与其对应的候选词保持一致。但很奇怪他给的图片里，他的fcitx又不是那样的。
@pingz
嗯，你是闲着没事了。
感觉是标点 . 现在做视觉导向，如果取消掉 变 1 ** 2 ** 3 ** 肯定乱了。
如果不用标点那么 1** 2** 3** 或者 **1 **2 **3
请问什么时候才能把Google Code那边的Issue 637（OpenCC的-c参数问题）做一下，一直等这个功能很久了……
@Anon ˊ_>ˋ 简单来说我不想做……如果一个词的转换之后的读音和原来不同的话就很难控制你到底输入的内容是什么
你打服务器 结果出来的是 伺服器 ，我觉得是难以接受的。更别提如果两个词的字数不一样了。
特别是你要是分别打 服 务 器 三个字出来的还是服务器
@csslayer
但是在OpenCC官网的在线转换功能里面有个“地域用词转换”的选项，单独关掉就没问题了啊？
@jiero 编号位置的问题：
也许你想当然的认为顺着视线走的方向就是最“自然”的，其实根本不是这个样子，有时候直觉顺序恰恰就不是线性的。对于从左往右写的文字，直觉情况下，阅读某一个候选项时，眼睛其实默默的做了两件事情：第一，定位到候选项的第一个字；第二，往右读——但不是一个字一个字地读，这是一个关键问题。一般人都不会逐字读完一个候选项，而是瞥一眼大概 + 脑补来判断是不是自己需要的东西，哪怕对于单字都是直接瞄一下粗略外形就判断了，所以当你差不多知道这个候选项是什么东西的时候，视线并没有移到最右边，甚至可能根本就原地不动，但这时大脑已经认为选项读完了，于是直接切换为解决下一个问题的模式，就是确定要按哪个数字，所以眼睛就会开始寻找这个数字。正是因为直觉中“列表”的编号在第一个字的左边，所以视线此时就会条件反射地迅速跳到第一个字再往左一点的位置，而且不管候选项多长，视线总是可以瞬间回到那个点，这是因为大脑在潜意识中已经知道这个位置在哪里，所以就直接跳过去了。可是如果编号在右边的话，鉴于候选项长短不一，导致大脑其实并不知道他的确切位置究竟是在哪里，于是视线就只能往右扫而不能直接跳，因为乱跳的话会漏过那个编号，这个过程真心是很慢的。况且由于存在编号在左边的直觉，自然也要费点力气克服条件反射，那就更坑爹了。
顺便说下，我一直是把默认的五候选改成三候选的，这种情况下完全可以连编号都不要，因为人对位置的粗略概念就是左、中、右，正好三个位置，而且三个候选差不多正好符合视线宽度。个人觉得三候选情况下把首选项放中间并配合首选项颜色标记会更好——貌似这个是当初拼音加加的设计？另外 kimpanel 的编号颜色问题，我也确实觉得有点不合适。
每个人都是看自己的习惯。实际看来细微差异是有的。
跳读不会过编号，左右方案都是用空格分隔候选项。
虽然短句我是可以从右向左读（irc习惯各种东西放右面）编号是啥我多数没看，因为 空格大概就是了。
寻找的时候，我确实经常做减法。因为很多情况第一个字是相同的，我真的是跳读，第二个字开始看。根本编号靠近的就是下一个，所以要 减一。
测试何不测试？
我还是没懂到哪些代码定义这个。
@csslayer 之前没@到你，一直到现在都没见有答复，现在你怎么看？