search

rime / librime

Rime Input Method Engine, the core library
https://rime.im
BSD 3-Clause "New" or "Revised" License
3.37k stars 551 forks source link

[Leading to further discussion] Why can librime affect UI settings? #396

Closed WhiredPlanck closed 4 years ago

WhiredPlanck commented 4 years ago

Recently I found an article: https://zhuanlan.zhihu.com/p/187195412 In the comment section of this column, I saw a "interesting" thing:

图片.png

And this related commit: https://github.com/rime/librime/commit/dbb35c61295a5b089a588c94886ce720f834f2f4 What the ......!? Why can librime, a back-end, directly (and even decisively) affect the UI settings? Why? This obviously should be left to front-end management, why finally left to the back-end? Can't understand! (理解不能！） And there are many confusing mechanisms Not only I but also many users ask for a explanation.

WhiredPlanck commented 4 years ago

I have to admit that I wrote this issue with a little anger, but, many users and I DO think that it would be better to left to front-end to handle things like UI settings.

CoelacanthusHex commented 4 years ago

I think so too.

sih4sing5hong5 commented 4 years ago

And this related commit: dbb35c6

This code is for arrow keys. The vertical/horizontal layout is still controlled by UI. Like weasel

WhiredPlanck commented 4 years ago

And this related commit: dbb35c6

This code is for arrow keys. The vertical/horizontal layout is still controlled by UI. Like weasel

You are right. But still: why a back-end need to process the key pressing?

sih4sing5hong5 commented 4 years ago

And this related commit: dbb35c6

This code is for arrow keys. The vertical/horizontal layout is still controlled by UI. Like weasel

You are right. But still: why a back-end need to process the key pressing?

Arrow keys will change the state of librime, the dbb35c6 need know XP_Right represented. It is next candidate in _horizontal settings, or previous candidate in _vertical settings. It seems _horizontal and _vertical are private settings controlled by squirrel.

./SquirrelInputController.m:  Bool is_horizontal_mode = NSApp.squirrelAppDelegate.panel.horizontal;
./SquirrelInputController.m:  if (is_horizontal_mode != rime_get_api()->get_option(_session, "_horizontal")) {
./SquirrelInputController.m:    rime_get_api()->set_option(_session, "_horizontal", is_horizontal_mode);
CoelacanthusHex commented 4 years ago

In my understanding, librime is only responsible for returning candidates and waiting for the front-end to tell which one has been selected. Why does it involve the front-end UI and the placement of candidate words?

WhiredPlanck commented 4 years ago

In my understanding, librime is only responsible for returning candidates and waiting for the front-end to tell which one has been selected. Why does it involve the front-end UI and the placement of candidate words?

This is what I want to say, too. @sih4sing5hong5

sih4sing5hong5 commented 4 years ago

In my understanding, librime is only responsible for returning candidates and waiting for the front-end to tell which one has been selected. Why does it involve the front-end UI and the placement of candidate words?

This architecture is OK. In this architecture, every frontends need:

  1. Keep the state of the candidates.
  2. Reset the state, when pressing esc, commit candidate, cursor moving ... actions.
  3. Manipulate the eaten value returned to OS. This value tells OS, whether the input method detail with the key event. If not, OS must capture the key event, like caps lock, number lock, print screen, ...etc.

If the frontend knows all candidate, it can scroll candidates like macOS system input method. If you want this feature, just write a new selector in librime, you can archieve your goal and keep back compatibility with librime.

I think the architecture of librime selector is referencing fcitx or ibus framework.

WhiredPlanck commented 4 years ago

I think the architecture of librime selector is referencing fcitx or ibus framework.

Maybe you are right, but that is your "think", subjectively I don't quite believe that ......After all, as far as I know, the core library of fcitx (or fcitx5) doesn't affect the UI performance.

sih4sing5hong5 commented 4 years ago

I think the architecture of librime selector is referencing fcitx or ibus framework.

Maybe you are right, but that is your "think", subjectively I don't quite believe that ......After all, as far as I know, the core library of fcitx (or fcitx5) doesn't affect the UI performance.

Oh! There are two different things in the selector.

  1. The architecture, the candidate state controlled by the selector, maybe for fcitx.
  2. The _vertical and _horizontal config in the selector are private setting for squirrel only(only squirrel uses this string). It seems an UI API for squirrel. Maybe there are some clues in SquirrelInputController.m. 
    ./SquirrelInputController.m:  Bool is_horizontal_mode = NSApp.squirrelAppDelegate.panel.horizontal;
./SquirrelInputController.m:  if (is_horizontal_mode != rime_get_api()->get_option(_session, "_horizontal")) {
./SquirrelInputController.m:    rime_get_api()->set_option(_session, "_horizontal", is_horizontal_mode);

I think you are concerned about second one. You can trace why squirrel need this is_horizontal_mode valuable.

lotem commented 4 years ago

OP is angry because they cannot understand my code? I guarantee you, if they know code, it'll be super easy.

The code change https://github.com/rime/librime/commit/dbb35c61295a5b089a588c94886ce720f834f2f4 is not related to the disucussion on Zhihu, at all.

By the way, the feature Zhihu User was asking for has been implemented in Squirrel ~7 years ago: https://github.com/rime/squirrel/commit/316b34b8f7944fe1bc9829e4b8504d082731b43e and recorded in the release notes.

OP doesn't even understand what the dialog was about, and hurried to GitHub to "blame" what they thought was going on... Confusing. They simply have to learn one thing, as the Elder said, and stop being naïve.

CoelacanthusHex commented 4 years ago

The code change dbb35c6 is not related to the disucussion on Zhihu, at all.

In fact, I don't know this zhihu post until I found this issue. But I can't understand why these code about UI or the placement of candidate appear in back-end when I found this commit yesterday.

I think it important to make front-end and back-end do what they should do. As I said above, in my opinion, the code about UI or the placement of candidate should not be in the back-end code.

CoelacanthusHex commented 4 years ago

Since you have time to make this change, why not optimize memory cost of dict-compile or add some code to make librime load plugins?

lotem commented 4 years ago

Of couse librime cannot directly affect UI or any front-end behaviour. The library is always passively called by the front-end, giving the results for the query in return. Which part in the commit are you not clear that it's all doing back-end work?

Again, I advice that OP learn the very basics - the minimal CS knowledge and coding skills - until they are ready to know what to blame.

lotem commented 4 years ago

The code change dbb35c6 is not related to the disucussion on Zhihu, at all.

In fact, I don't know this zhihu post until I found this issue.

This is no issue. The code was great.

But I can't understand why these code about UI or the placement of candidate appear in back-end when I found this commit yesterday.

Because the back-end needs to know the necessary information from the front-end to answer the front-end's queries, which in this case, is "What will be the candidates when the User pressses Left or Right in this input method". To answer that, the engine has to know how User saw the previous candidates in order to understand the User's intention.

I think it important to make front-end and back-end do what they should do.

That's what is in the code.

As I said above, in my opinion, the code about UI or the placement of candidate should not be in the back-end code.

Those are not in the backend code. The code is not about manipulating UI. The code is purely building a model in the backend with information coming from the frontend - keyboard input is also such information - and with that, the model is able to answer the frontend's queries. You cannot have a backend that has zero knowledge of the frontend yet is able to answer questions about the frontend.

Look, I've boiled it down to the very basics. Yet most skills cannot be told. I know how to design an input method library so well, because I've seen too much.

lotem commented 4 years ago

Since you have time to make this change, why not optimize memory cost of dict-compile or add some code to make librime load plugins?

No, thanks. I have my own priorities.

WhiredPlanck commented 4 years ago

Of couse librime cannot directly affect UI or any front-end behaviour. The library is always passively called by the front-end, giving the results for the query in return. Which part in the commit are you not clear that it's all doing back-end work?

Again, I advice that OP learn the very basics - the minimal CS knowledge and coding skills - until they are ready to know what to blame.

我还是用中文说出来吧，以我的水平可能英语表达不出来。 也许是我的无知和幼稚，这条 issue 让大家见笑了。这里面的一些东西，肯定避免不了误会误解。如果说是我理解有误会，那么我感到很抱歉，非常对不起。但是我想说我开始的想法里有借这条 issue 去引出一些讨论的意味。

就我个人感觉，开发者和我们用户交流似乎很少。作为普通（初级或中级）用户，我们能知道也（可能）仅能知道 experience，我们有可能没法去理解 design，理解您的想法（至少源码层面上会是这样）。从体验上来说，我们确实感到了很多不满意。我们希望能更多地了解您是怎么想、怎么去实现的。也许这样我们才能更好地提出更针对性和更具体的意见和建议。

无论如何，都先非常感谢您本人能回答我的疑惑。: )

WhiredPlanck commented 4 years ago

上午我提出这条 issue 时，我的确是带着一些怒气的。但是想到我的水平，可能会造成一些误会（就像现在这样，最终可能显得我自己既无能又跳脚得很）。所以冷静下来，我的想法就和上一条 comment 一样。其实可能是一种广泛的非技术问题，我跑来 GitHub 来抱怨确实让人觉得有些 无事找事，不切重点，不符合氛围 。但我（们）依旧想借一个空间来表达想法，毕竟我认为这种方式您有更多机会来看到。我想让您知道，大家的不满是有些长久的（具体提过不短时间但依旧未实现的）、普遍的，甚至是挺迫切的。

引用 TG 用户交流群里几位小伙伴的话（他们看了这条 issue 里的 comments）：

Although we may not know the design of the input method very well, at least we know one thing, the user experience is not good, and this time it is just a fuse.

Users maybe don't know design, but know experience.

我衹看到氣話

使用 Rime 推荐发行版： AOSC OS 你永远不知道一个发行版帮上游填了多少坑……

......

这条 issue 本身的问题或许不再值得讨论下去。但，希望佛振先生能够更切实感受到我们的声音。 Best wishes.

lotem commented 4 years ago

Don't be upset if you cannot beat me in English. I learn Elder's words so well and faithfully follow His instructions on taking constant effort in foreign language study, as well as His practice in sharing knowledge with younger people.

「怒氣」……

技術牛不牛不清楚，你們有一個好，脾氣可真不小，聲音不絕於耳。只是問來問去的問題，太業餘了，有時荒謬。 還想弄個大新聞，就把我批判一番？ 你們要知道，寫OpenCC的大神BYVoid，比你們不知高到哪裏去了，我跟他談笑風生。

某曾遭遇過路怒，遭遇過佛棍誣我「謗佛」，還從未見過搬磚寫碼也致人狂怒的。 我寫碼爲樂，跟你關係大嗎。何以動氣？玩不轉，都怨別人不給你做？How dare you.

某主張，哪裏不滿，就做到滿意。帶上有說服力的設計和代碼實現來討論。切實感受，莫過於此。讓你們的聲音有助於完成真正有用的工作。

WhiredPlanck commented 4 years ago

我上午提出 issue 没多久就已经冷静下来过了，不过我当时觉得收不住这说出的话了...... 遭遇您的批评无可避免，我也不怕因此「丢假」。请您不要误会，可能是我的锅，但是我个人角度没有任何要「不讲理」、「诽谤」的初衷（开始时是有一点点，但绝没有要一直贯彻下去的意思）和「制造大新闻」 的最终目的。还请您原谅。

我寫碼爲樂，跟你關係大嗎。何以動氣？玩不轉，都怨別人不給你做？How dare you.

这一点我能理解，在我的学习生活中也有深刻体会。说白了今天，可以说是场由我开头，由我承担后果的「闹剧」。但是有时候现实是，我（非具体指代）觉得应该这样，但是大家觉得要怎样，然后就吵起来了，这种矛盾很普遍。

再次，如果我的鲁莽行为造成了您的不解甚至愤怒，我非常抱歉。「大新闻」真非我本意。我在那时只是想用自己的一种方式去解决 —— 即使不能解决，但也或许能有个回音 —— 问题罢了。

WhiredPlanck commented 4 years ago

技術牛不牛不清楚，你們有一個好，脾氣可真不小，聲音不絕於耳。只是問來問去的問題，太業餘了，有時荒謬。

还想就这条补充一点话。我个人而言，至少目前我确实是个水平上的「年轻人」，但是其实不是大家真的都没能力却都又喜欢嚷嚷。比如其实 trime 同文输入法有个 fork 在 QQ 群，是群友做的（不过不知为何不愿公开；另外考虑到 trime 和 rime 本体「负责人」不同，就没多提）。

「只是人总是习惯找一个带头的作为责任人而已……」，有的人认为某某事情应该去交给「上面那个人」去做，依赖上游一方（这可能是个非技术问题）。我不相信大家都没实力，但是哪怕是在开源社区，这种「责任感」（姑且这么形容）问题也并不总是扁平化的。 说话永远比实际付出更容易，即使自己有能力，在当下快节奏的环境下也无形驱使着人说的比做的快。也有的人单纯就是不想再另外造轮子，您也说您有自己的想法。这是我的看法。

但真的真的，这条 issue 是有点代大家说话的意思在里面。以我的感受，这可能只是一个导火索，或许 this is no issue。未来可能会有更激烈的声音。但是还是再次说明，我没有想要借着这些感受和其他用户的声音，把「诽谤」和「制造大新闻」作为最终目的。

WhiredPlanck commented 4 years ago

无论如何，这场讨论还是告一段落吧。非常感谢有您的回复。: )

sih4sing5hong5 commented 4 years ago

我上午提出 issue 没多久就已经冷静下来过了，不过我当时觉得收不住这说出的话了...... 遭遇您的批评无可避免，我也不怕因此「丢假」。请您不要误会，可能是我的锅，但是我个人角度没有任何要「不讲理」、「诽谤」的初衷（开始时是有一点点，但绝没有要一直贯彻下去的意思）和「制造大新闻」 的最终目的。还请您原谅。

There are a guideline for community communication in How to write the perfect pull request . Using positive language is helpful for the community.

「只是人总是习惯找一个带头的作为责任人而已……」，有的人认为某某事情应该去交给「上面那个人」去做， 但真的真的，这条 issue 是有点代大家说话的意思在里面。

Everyone need take responsibility for himself/herself. We can choose speaking out or suffering in silence. So I think more discussion with positive language is better.

大家的不满是有些长久的（具体提过不短时间但依旧未实现的）、普遍的，甚至是挺迫切的。

The librime is an open source library. If there are some valuable features for you, you try to raise funds to hire full-time/part-time engineers to achieve what you want. It's more efficiency than just blame.

WhiredPlanck commented 4 years ago

It's more efficiency than just blame.

Sometimes blaming is not the purpose, but expressing our attitude is.

Prcuvu commented 4 years ago

使用 Rime 推荐发行版： AOSC OS 你永远不知道一个发行版帮上游填了多少坑……

Sounds sweet, but we have never heard of anything from AOSC OS developers. ibus-rime has been relatively inactive for years. When any user of a certain Linux distribution comes up with patches, it is always helpful to start an issue at ibus-rime repository to let us know about their great ideas. RIME developers mostly work on macOS. It is unreasonable to check communities of every possible Linux distribution to collect patches regularly.

LEOYoon-Tsaw commented 4 years ago

I have to admit that I wrote this issue with a little anger, but, many users and I DO think that it would be better to left to front-end to handle things like UI settings.

You can do it if you are both capable and willing to, nothing is preventing you to contribute if you are not satisfied with my work.

WhiredPlanck commented 4 years ago

Sounds sweet, but we have never heard of anything from AOSC OS developers.

Hmm, some users have heard more than what I know. For that, I just a listener rather than a insider.

WhiredPlanck commented 4 years ago

nothing is preventing you to contribute

Some people (not me) have deep doubts about it.

nameoverflow commented 4 years ago

Why don't u just give a try?

example:

luna_pinyin.custom.yaml

patch:
  "style/horizontal": true

cangjie5.custom.yaml

patch:
  "style/horizontal": false

It works.

WhiredPlanck commented 4 years ago

Why don't u just give a try?

I have know this already. In fact, my own problem (i.e. the problem of UI settings) has been solved, and I will ask such a problem because I didn't understand it well (whether it is my lack of knowledge).

The reason why the code is said to be "relevant" is only because we only found that one in the recent commit history. In the subsequent discussion and explanation, we already knew that it was not really relevant.

It now appears that everyone's conflicts and concerns are not this problem itself.

eatradish commented 4 years ago

使用 Rime 推荐发行版： AOSC OS 你永远不知道一个发行版帮上游填了多少坑……

Sounds sweet, but we have never heard of anything from AOSC OS developers. ibus-rime has been relatively inactive for years. When any user of a certain Linux distribution comes up with patches, it is always helpful to start an issue at ibus-rime repository to let us know about their great ideas. RIME developers mostly work on macOS. It is unreasonable to check communities of every possible Linux distribution to collect patches regularly.

(I‘m AOSC OS (RIME) Maintainer)

Ironically, I just did some "anyone can do" work to improve the out-of-the-box experience of RIME.

like this: https://github.com/AOSC-Dev/rime-schema-manager and https://github.com/AOSC-Dev/aosc-os-abbs/blob/testing-proposed/extra-i18n/rime-luna-pinyin/autobuild/postinst . I hope to help maintainers of various Linux distros.