Show notification (aux string) when IM setting changes

[kanru]

Is your feature request related to a problem? Please describe.

Currently when toggling Eng/Chi mode we don't have very clear indication. Some implementation changes the tray-icon but on larger screen it's not very noticeable.

Describe the solution you'd like

We can use the aux string to show notifications to user, like 「切換為英文模式」 or 「切換為全形模式」

Describe alternatives you've considered

Maybe we can also consider to have the aux string sticky so it always shows current state like a floating panel.

Additional context

IBus API: https://ibus.github.io/docs/ibus-1.5/IBusPanelService.html#IBusPanelService-show-auxiliary-text

[wengxt]

I personally prefer this to be implemented as a callback function.

Fcitx implements such feature with system notification.

You could take a look at rime's API to have an idea about what I mean here: https://github.com/fcitx/fcitx5-rime/blob/a2585e950fd058eacba01071e0683653159098d0/src/rimeengine.cpp#L423 https://github.com/fcitx/fcitx5-rime/blob/a2585e950fd058eacba01071e0683653159098d0/src/rimeengine.cpp#L645

[kanru]

@wengxt that is an interesting idea. It is different from the current API design though. Currently it follows a repl kind of approach. The IM front end is expected to observe state change using each check API.

Currently notification is checked using the aux check API. I think if we introduce the callback style API we can consider applying it to other outputs as well.

Does rime use callbacks for everything?

[wengxt]

no, only for notification since its data loading is async with multi threading so it has to be a callback, though somehow it’s also used for internal option change. Though it’s not always handy since in fcitx engine I only send notifications triggered by key event since I feel it’s redundant to show such a popup when the change is coming from tray menu click.

So basically I have to write some extra code with a flag to check whether the notification is triggered during key processing, if flag==true, then show the notification.

I guess for chewing you may want to only show aux/notification when calling the handle* API, not the set* that modifies the state directly.

libskk / libkkc uses a gobject signal so the callback can be used to monitor e.g. if there’s candidate change / preedit change, while you can still use api to poll for the data change.

https://github.com/ueno/ibus-skk/blob/8a4ff24f3a7bed46a75f67164a9ec0c5d27b20a4/src/engine.vala#L130

This might be relevant to #500 if you want to take a similar approach for everything.

[kanru]

I guess for chewing you may want to only show aux/notification when calling the handle* API, not the set* that modifies the state directly.

This is a good point.

Callback based API sounds good but we need to think about issues like function reentrant and multi-threading.

For now I'm thinking to stick with current approach and explore callback based design post-1.0 deprecated API clean-up.