Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#990316: Add GLFW_IM_MODULE=fcitx on ibus and fcitx5 to enable IME in kitty
1,143 views
Skip to first unread message
Yao Wei
Jun 25, 2021, 9:30:03 AM6/25/21
to
Package: im-config
Version: 0.46-1
Severity: wishlist
Hi,
As discussed in https://github.com/kovidgoyal/kitty/issues/469, adding
`GLFW_IM_MODULE=ibus` can enable IBus API connection in kitty terminal,
and thus enabling CJK input in that terminal emulator.
Not only in IBus, fcitx5 populates IBus API so setting the envvar to
`ibus` also works in fcitx5.
However, after some searching I found that the variable looks like
exclusively used in kitty, especially this envvar acts as a toggle in
kitty's source code:
https://github.com/kovidgoyal/kitty/blob/6179cfc6703af1b0682fdd14829280b8a228c167/glfw/ibus_glfw.c#L286
I am wondering whether it is okay to add that variable into im-config.
Best regards,
Yao Wei
Version: 0.46-1
Severity: wishlist
Hi,
As discussed in https://github.com/kovidgoyal/kitty/issues/469, adding
`GLFW_IM_MODULE=ibus` can enable IBus API connection in kitty terminal,
and thus enabling CJK input in that terminal emulator.
Not only in IBus, fcitx5 populates IBus API so setting the envvar to
`ibus` also works in fcitx5.
However, after some searching I found that the variable looks like
exclusively used in kitty, especially this envvar acts as a toggle in
kitty's source code:
https://github.com/kovidgoyal/kitty/blob/6179cfc6703af1b0682fdd14829280b8a228c167/glfw/ibus_glfw.c#L286
I am wondering whether it is okay to add that variable into im-config.
Best regards,
Yao Wei
Osamu Aoki
Jun 25, 2021, 10:20:03 AM6/25/21
to
Hi,
I assume you are talking post-bullseye upload.
On Fri, 2021-06-25 at 21:23 +0800, Yao Wei wrote:
> Package: im-config
> Version: 0.46-1
> Severity: wishlist
>
> Hi,
>
> As discussed in https://github.com/kovidgoyal/kitty/issues/469, adding
> `GLFW_IM_MODULE=ibus` can enable IBus API connection in kitty terminal,
> and thus enabling CJK input in that terminal emulator.
>
> Not only in IBus, fcitx5 populates IBus API so setting the envvar to
> `ibus` also works in fcitx5.
>
I don't know about kitty but this sounds very good idea.
I assume this is like fbterm like program on Linux console with a lot of features ...
nono ...this is run under X.
> However, after some searching I found that the variable looks like
> exclusively used in kitty, especially this envvar acts as a toggle in
> kitty's source code:
>
> https://github.com/kovidgoyal/kitty/blob/6179cfc6703af1b0682fdd14829280b8a228c167/glfw/ibus_glfw.c#L286
>
> I am wondering whether it is okay to add that variable into im-config.
I see this very low risk and good idea.
Send us pull request or patch.
Osamu
I assume you are talking post-bullseye upload.
On Fri, 2021-06-25 at 21:23 +0800, Yao Wei wrote:
> Package: im-config
> Version: 0.46-1
> Severity: wishlist
>
> Hi,
>
> As discussed in https://github.com/kovidgoyal/kitty/issues/469, adding
> `GLFW_IM_MODULE=ibus` can enable IBus API connection in kitty terminal,
> and thus enabling CJK input in that terminal emulator.
>
> Not only in IBus, fcitx5 populates IBus API so setting the envvar to
> `ibus` also works in fcitx5.
>
I assume this is like fbterm like program on Linux console with a lot of features ...
nono ...this is run under X.
> However, after some searching I found that the variable looks like
> exclusively used in kitty, especially this envvar acts as a toggle in
> kitty's source code:
>
> https://github.com/kovidgoyal/kitty/blob/6179cfc6703af1b0682fdd14829280b8a228c167/glfw/ibus_glfw.c#L286
>
> I am wondering whether it is okay to add that variable into im-config.
Send us pull request or patch.
Osamu
Gunnar Hjalmarsson
Nov 15, 2021, 9:30:03 AM11/15/21
to
Control: tag -1 patch
Thanks for your patch, Chen Shijie. As Osamu said, adding that variable
would be trivial and without a risk to affect other applications.
Reading <https://github.com/kovidgoyal/kitty/issues/469> makes me still
hesitate, though. If I understand it correctly, the principal kitty
developer has intentionally not enabled IME input by default due to
claimed efficiency issues and bugs.
im-config works the other way around. As soon as some input method
framework such as IBus or fcitx5 is installed, im-config sets the
related variables and launches the daemon. And it does so by default.
In the light of that, I'm wondering if letting im-config set
GLFW_IM_MODULE is the right thing to do.
--
Regards,
Gunnar Hjalmarsson
Thanks for your patch, Chen Shijie. As Osamu said, adding that variable
would be trivial and without a risk to affect other applications.
Reading <https://github.com/kovidgoyal/kitty/issues/469> makes me still
hesitate, though. If I understand it correctly, the principal kitty
developer has intentionally not enabled IME input by default due to
claimed efficiency issues and bugs.
im-config works the other way around. As soon as some input method
framework such as IBus or fcitx5 is installed, im-config sets the
related variables and launches the daemon. And it does so by default.
In the light of that, I'm wondering if letting im-config set
GLFW_IM_MODULE is the right thing to do.
--
Regards,
Gunnar Hjalmarsson
Osamu Aoki
Nov 18, 2021, 9:40:04 AM11/18/21
to
Hi,
On Mon, 2021-11-15 at 15:11 +0100, Gunnar Hjalmarsson wrote:
> Control: tag -1 patch
>
> Thanks for your patch, Chen Shijie. As Osamu said, adding that variable
> would be trivial and without a risk to affect other applications.
>
> Reading <https://github.com/kovidgoyal/kitty/issues/469> makes me still
> hesitate, though. If I understand it correctly, the principal kitty
> developer has intentionally not enabled IME input by default due to
> claimed efficiency issues and bugs.
I am not sure which comment are you talking...
> im-config works the other way around. As soon as some input method
> framework such as IBus or fcitx5 is installed, im-config sets the
> related variables and launches the daemon. And it does so by default.
Kitty seems to use library which can get key input from different source path. This
is just like GTK and Qt apps are. I am not sure what is "the other way around"?
> In the light of that, I'm wondering if letting im-config set
> GLFW_IM_MODULE is the right thing to do.
>
Anyway, we need to get feed back from Wei.
As I don't use kitty, I am not the best person to judge what should be the best
default. At least I now understand kitty seems to be a terminal program running on
wayland environment without using GTK nor Qt.
It looks to me kitty is neither GTK nor Qt, without explicit environment variable
setting to use ibus, it use dbus? or xim? . This is just like GTK and Qt apps
behave. So for wayland ready IM (ibus and fcitx5?) it may be right to set such
setting.
Tell us how this all fit together.
Regards,
Osamu
On Mon, 2021-11-15 at 15:11 +0100, Gunnar Hjalmarsson wrote:
> Control: tag -1 patch
>
> Thanks for your patch, Chen Shijie. As Osamu said, adding that variable
> would be trivial and without a risk to affect other applications.
>
> Reading <https://github.com/kovidgoyal/kitty/issues/469> makes me still
> hesitate, though. If I understand it correctly, the principal kitty
> developer has intentionally not enabled IME input by default due to
> claimed efficiency issues and bugs.
> im-config works the other way around. As soon as some input method
> framework such as IBus or fcitx5 is installed, im-config sets the
> related variables and launches the daemon. And it does so by default.
is just like GTK and Qt apps are. I am not sure what is "the other way around"?
> In the light of that, I'm wondering if letting im-config set
> GLFW_IM_MODULE is the right thing to do.
>
As I don't use kitty, I am not the best person to judge what should be the best
default. At least I now understand kitty seems to be a terminal program running on
wayland environment without using GTK nor Qt.
It looks to me kitty is neither GTK nor Qt, without explicit environment variable
setting to use ibus, it use dbus? or xim? . This is just like GTK and Qt apps
behave. So for wayland ready IM (ibus and fcitx5?) it may be right to set such
setting.
Tell us how this all fit together.
Regards,
Osamu
Gunnar Hjalmarsson
Nov 18, 2021, 10:30:06 AM11/18/21
to
On 2021-11-18 15:29, Osamu Aoki wrote:
> On Mon, 2021-11-15 at 15:11 +0100, Gunnar Hjalmarsson wrote:
>> Reading <https://github.com/kovidgoyal/kitty/issues/469> makes me
>> still hesitate, though. If I understand it correctly, the principal
>> kitty developer has intentionally not enabled IME input by default
>> due to claimed efficiency issues and bugs.
>
> I am not sure which comment are you talking...
https://github.com/kovidgoyal/kitty/issues/469#issuecomment-419406438
> On Mon, 2021-11-15 at 15:11 +0100, Gunnar Hjalmarsson wrote:
>> Reading <https://github.com/kovidgoyal/kitty/issues/469> makes me
>> still hesitate, though. If I understand it correctly, the principal
>> kitty developer has intentionally not enabled IME input by default
>> due to claimed efficiency issues and bugs.
>
> I am not sure which comment are you talking...
> I am not sure what is "the other way around"?
present — is launched and configured by default.
> So for wayland ready IM (ibus and fcitx5?) it may be right to set
> such setting.
GNOME desktop, but we defer to GNOME's mechanisms for launching and
configuring IBus.
> Tell us how this all fit together.
--
Cheers,
Gunnar
Osamu Aoki
Nov 18, 2021, 9:00:04 PM11/18/21
to
Hi,
\
Anyway, situation of enabling IM needs help from someone understanding GLFW related
backend keyboard input handling. The successful user seem to use "sway" for Desktop
management. Is there any other programs using similar backend.
If problem is happening with backend using xim, that is likely the situation just
like GTK. But this seems to indicate otherwise.
Anyway, those who seems having trouble setting up ibus or fcitx5 didn't set up
environment variable properly. There are too much noise. So we need feedback from
good tester reporting situation with versions involved (ibus, fcitx5, ...)
Current in testing are:
kitty 0.19.3-1
ibus 1.5.25-3
fcitx5 5.0.9-2
sway 1.5.1-2
(fcitx 1:4.2.9.8-3)
> > I am not sure what is "the other way around"?
>
> The purpose of im-config is to make sure that an IM framework — if
> present — is launched and configured by default.
>
> > So for wayland ready IM (ibus and fcitx5?) it may be right to set
> > such setting.
>
> Please remember that im-config doesn't do anything in case of IBus on a
> GNOME desktop, but we defer to GNOME's mechanisms for launching and
> configuring IBus.
Yes. I plan to keep it this way for GNOME.
Wei, Please let us know XDG_CURRENT_DESKTOP on the system you tested. What do you
get on sway system who try to use kitty?
\
On Thu, 2021-11-18 at 16:09 +0100, Gunnar Hjalmarsson wrote:
> On 2021-11-18 15:29, Osamu Aoki wrote:
> > On Mon, 2021-11-15 at 15:11 +0100, Gunnar Hjalmarsson wrote:
> > > Reading <https://github.com/kovidgoyal/kitty/issues/469> makes me
> > > still hesitate, though. If I understand it correctly, the principal
> > > kitty developer has intentionally not enabled IME input by default
> > > due to claimed efficiency issues and bugs.
> >
> > I am not sure which comment are you talking...
>
> https://github.com/kovidgoyal/kitty/issues/469#issuecomment-419406438
Hmmm...I see. This is worrying
> On 2021-11-18 15:29, Osamu Aoki wrote:
> > On Mon, 2021-11-15 at 15:11 +0100, Gunnar Hjalmarsson wrote:
> > > Reading <https://github.com/kovidgoyal/kitty/issues/469> makes me
> > > still hesitate, though. If I understand it correctly, the principal
> > > kitty developer has intentionally not enabled IME input by default
> > > due to claimed efficiency issues and bugs.
> >
> > I am not sure which comment are you talking...
>
> https://github.com/kovidgoyal/kitty/issues/469#issuecomment-419406438
Anyway, situation of enabling IM needs help from someone understanding GLFW related
backend keyboard input handling. The successful user seem to use "sway" for Desktop
management. Is there any other programs using similar backend.
If problem is happening with backend using xim, that is likely the situation just
like GTK. But this seems to indicate otherwise.
Anyway, those who seems having trouble setting up ibus or fcitx5 didn't set up
environment variable properly. There are too much noise. So we need feedback from
good tester reporting situation with versions involved (ibus, fcitx5, ...)
Current in testing are:
kitty 0.19.3-1
ibus 1.5.25-3
fcitx5 5.0.9-2
sway 1.5.1-2
(fcitx 1:4.2.9.8-3)
> > I am not sure what is "the other way around"?
>
> The purpose of im-config is to make sure that an IM framework — if
> present — is launched and configured by default.
>
> > So for wayland ready IM (ibus and fcitx5?) it may be right to set
> > such setting.
>
> Please remember that im-config doesn't do anything in case of IBus on a
> GNOME desktop, but we defer to GNOME's mechanisms for launching and
> configuring IBus.
Wei, Please let us know XDG_CURRENT_DESKTOP on the system you tested. What do you
get on sway system who try to use kitty?
Yao Wei
Nov 18, 2021, 10:00:03 PM11/18/21
to
I am currently using sway without desktop manager. I am able to use
fcitx5 on kitty in sway after setting GLFW_IM_MODULE=ibus, and if that
variable is unset the IM is not operable in kitty.
Regarding to the concern of the upstream developr, I don't observe
performance hit after setting the variable. The only question I am having
is that whether we should set that variable in im-config because that
seems to be only used in kitty and nowhere else.
The followings are the package versions I was testing with:
fcitx5 5.0.9-2
kitty 0.19.3-1
sway 1.5.1-2
Best regards,
Yao Wei
Osamu Aoki
Nov 19, 2021, 1:40:03 AM11/19/21
to
Hi,
Can you tell us XDG_CURRENT_DESKTOP under sway?
One thing I feel odd is "GLFW_IM_MODULE=ibus".
Why not like?
* GLFW_IM_MODULE=fcitx5
* GLFW_IM_MODULE=fcitx
The upstrean web site has confusing comments.
Does fcitx5 and ibus use compatible API?
Osamu
One thing I feel odd is "GLFW_IM_MODULE=ibus".
Why not like?
* GLFW_IM_MODULE=fcitx5
* GLFW_IM_MODULE=fcitx
The upstrean web site has confusing comments.
Does fcitx5 and ibus use compatible API?
Osamu
Yao Wei
Nov 19, 2021, 2:00:04 AM11/19/21
to
Hi,
On Fri, Nov 19, 2021 at 03:31:49PM +0900, Osamu Aoki wrote:
> Can you tell us XDG_CURRENT_DESKTOP under sway?
medicalwei@torchic:~$ echo $XDG_SESSION_DESKTOP
sway
> One thing I feel odd is "GLFW_IM_MODULE=ibus".
>
> Why not like?
>
> * GLFW_IM_MODULE=fcitx5
> * GLFW_IM_MODULE=fcitx
>
> The upstrean web site has confusing comments.
>
> Does fcitx5 and ibus use compatible API?
fcitx5 implements ibus dbus interface so fcitx5 is compatible with that
setup.
Also, GLFW in kitty only has implementation for ibus dbus interface, so
using values other than ibus does not work.
You can check by the code search:
https://github.com/kovidgoyal/kitty/search?q=GLFW_IM_MODULE
Best regards,
Yao Wei
On Fri, Nov 19, 2021 at 03:31:49PM +0900, Osamu Aoki wrote:
> Can you tell us XDG_CURRENT_DESKTOP under sway?
sway
> One thing I feel odd is "GLFW_IM_MODULE=ibus".
>
> Why not like?
>
> * GLFW_IM_MODULE=fcitx5
> * GLFW_IM_MODULE=fcitx
>
> The upstrean web site has confusing comments.
>
> Does fcitx5 and ibus use compatible API?
setup.
Also, GLFW in kitty only has implementation for ibus dbus interface, so
using values other than ibus does not work.
You can check by the code search:
https://github.com/kovidgoyal/kitty/search?q=GLFW_IM_MODULE
Best regards,
Yao Wei
Gunnar Hjalmarsson
Nov 19, 2021, 10:30:04 AM11/19/21
to
I played around a bit with kitty on Ubuntu (GNOME/wayland). I built
kitty with the attached patch applied, i.e. I removed the line which
checks the GLFW_IM_MODULE variable. The modified kitty package is
available at <https://launchpad.net/~gunnarhj/+archive/ubuntu/kitty>.
When using that package, I could input in kitty using either ibus or
fcitx5 without setting any extra environment variable.
On 2021-06-25 15:23, Yao Wei (魏銘廷) wrote:
> However, after some searching I found that the variable looks like
> exclusively used in kitty, especially this envvar acts as a toggle
> in kitty's source code:
>
> https://github.com/kovidgoyal/kitty/blob/6179cfc6/glfw/ibus_glfw.c#L286
Yes, it's a toggle, and that's apparently its only purpose.
In the light of these observations, I don't think we should let
im-config set GLFW_IM_MODULE.
Instead, provided that it's considered a good idea to make kitty ready
for ibus or fcitx5 by default, I think that a kitty patch similar to the
attached one is a better idea.
--
Best regards,
Gunnar Hjalmarsson
kitty with the attached patch applied, i.e. I removed the line which
checks the GLFW_IM_MODULE variable. The modified kitty package is
available at <https://launchpad.net/~gunnarhj/+archive/ubuntu/kitty>.
When using that package, I could input in kitty using either ibus or
fcitx5 without setting any extra environment variable.
On 2021-06-25 15:23, Yao Wei (魏銘廷) wrote:
> However, after some searching I found that the variable looks like
> exclusively used in kitty, especially this envvar acts as a toggle
> in kitty's source code:
>
Yes, it's a toggle, and that's apparently its only purpose.
In the light of these observations, I don't think we should let
im-config set GLFW_IM_MODULE.
Instead, provided that it's considered a good idea to make kitty ready
for ibus or fcitx5 by default, I think that a kitty patch similar to the
attached one is a better idea.
--
Best regards,
Gunnar Hjalmarsson
Gunnar Hjalmarsson
Nov 20, 2021, 7:10:04 AM11/20/21
to
Control: reassign -1 kitty 0.19.3-1
Control: retitle -1 Make IME support enabled by default in kitty
Control: tags -1 - moreinfo
X-Debbugs-Cc: debian-in...@lists.debian.org,jame...@debian.org
Hi again,
I have reassigned this bug from im-config to kitty.
@James: Does my idea in <https://bugs.debian.org/990316#59> make sense
to you?
--
Cheers,
Gunnar Hjalmarsson
Control: retitle -1 Make IME support enabled by default in kitty
Control: tags -1 - moreinfo
X-Debbugs-Cc: debian-in...@lists.debian.org,jame...@debian.org
Hi again,
I have reassigned this bug from im-config to kitty.
@James: Does my idea in <https://bugs.debian.org/990316#59> make sense
to you?
--
Cheers,
Gunnar Hjalmarsson
Osamu Aoki
Nov 20, 2021, 9:40:03 AM11/20/21
to
Hi,
Thanks Gunnar,
I actually tried kitty and read its manpage after recent exchanges.
This is very interesting terminal program indeed.
If I understand correctly, upstream chose to disable ibus feature if GLFW_IM_MODULE
is not set to ibus. So ibus is opt-in feature. Reverting that feature choice is one
option for Debian maintainer can do indeed. This is a risky path most maintainers
hesitate.
Since kitty has kitty.conf, a non-confrontational approach may be a patch to add one
configuration option in kitty.conf to enable ibus. So ibus support is still opt-in
feature. If James doesn't want to go along with Gunnar's suggestion, this may be a
alternative path forward.
Regards,
Osamu
I actually tried kitty and read its manpage after recent exchanges.
This is very interesting terminal program indeed.
If I understand correctly, upstream chose to disable ibus feature if GLFW_IM_MODULE
is not set to ibus. So ibus is opt-in feature. Reverting that feature choice is one
option for Debian maintainer can do indeed. This is a risky path most maintainers
hesitate.
Since kitty has kitty.conf, a non-confrontational approach may be a patch to add one
configuration option in kitty.conf to enable ibus. So ibus support is still opt-in
feature. If James doesn't want to go along with Gunnar's suggestion, this may be a
alternative path forward.
Regards,
Osamu
Gunnar Hjalmarsson
Nov 20, 2021, 10:10:03 AM11/20/21
to
On 2021-11-20 15:37, Osamu Aoki wrote:
> Since kitty has kitty.conf, a non-confrontational approach may be a
> patch to add one configuration option in kitty.conf to enable ibus.
> So ibus support is still opt-in feature. If James doesn't want to go
> along with Gunnar's suggestion, this may be a alternative path
> forward.
I also thought about using kitty.conf. Alternatively that would allow
> Since kitty has kitty.conf, a non-confrontational approach may be a
> patch to add one configuration option in kitty.conf to enable ibus.
> So ibus support is still opt-in feature. If James doesn't want to go
> along with Gunnar's suggestion, this may be a alternative path
> forward.
for an opt-out option.
In any case we seem to be agreed that this is a pure kitty matter.
--
Thanks!
Gunnar
James McCoy
Nov 20, 2021, 4:00:04 PM11/20/21
to
On Sat, Nov 20, 2021 at 11:37:14PM +0900, Osamu Aoki wrote:
> If I understand correctly, upstream chose to disable ibus feature if GLFW_IM_MODULE
> is not set to ibus. So ibus is opt-in feature. Reverting that feature choice is one
> option for Debian maintainer can do indeed. This is a risky path most maintainers
> hesitate.
Yeah, this isn't something I would patch.
> If I understand correctly, upstream chose to disable ibus feature if GLFW_IM_MODULE
> is not set to ibus. So ibus is opt-in feature. Reverting that feature choice is one
> option for Debian maintainer can do indeed. This is a risky path most maintainers
> hesitate.
> Since kitty has kitty.conf, a non-confrontational approach may be a patch to add one
> configuration option in kitty.conf to enable ibus. So ibus support is still opt-in
> feature.
a patch/PR to Kovid. I'm not familiar with IME topics, so I don't think
I would be in a good position to advocate for that.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Gunnar Hjalmarsson
Nov 20, 2021, 5:20:04 PM11/20/21
to
On 2021-11-20 21:53, James McCoy wrote:
> On Sat, Nov 20, 2021 at 11:37:14PM +0900, Osamu Aoki wrote:
>> If I understand correctly, upstream chose to disable ibus feature
>> if GLFW_IM_MODULE is not set to ibus. So ibus is opt-in feature.
>> Reverting that feature choice is one option for Debian maintainer
>> can do indeed. This is a risky path most maintainers hesitate.
>
> Yeah, this isn't something I would patch.
Fair enough. And given that, it would not be appropriate to bypass the
> On Sat, Nov 20, 2021 at 11:37:14PM +0900, Osamu Aoki wrote:
>> If I understand correctly, upstream chose to disable ibus feature
>> if GLFW_IM_MODULE is not set to ibus. So ibus is opt-in feature.
>> Reverting that feature choice is one option for Debian maintainer
>> can do indeed. This is a risky path most maintainers hesitate.
>
> Yeah, this isn't something I would patch.
restrain in Debian via im-config.
>> Since kitty has kitty.conf, a non-confrontational approach may be a
>> patch to add one configuration option in kitty.conf to enable ibus.
>> So ibus support is still opt-in feature.
>
> That sounds like a reasonable approach, if someone would like to
> propose a patch/PR to Kovid. I'm not familiar with IME topics, so I
> don't think I would be in a good position to advocate for that.
https://github.com/kovidgoyal/kitty/issues/3206
So maybe users who want IME support in kitty need to get used to set
that environment variable.
--
Regards,
Gunnar Hjalmarsson
Osamu Aoki
Nov 20, 2021, 9:50:03 PM11/20/21
to
Hi,
Here is my thought on my practical and non-invasive solution.
I guess the kitty upstream's negative impression on ibus/fcitx5 for dropped key
inputs comes from the well known ibus/fcitx5 daemon related problem using xim as the
communication protocol and probably not applicable if dbus is used to call ibus/fcitx
library. The upstream's latency concern with dbus may be negligible compared to how
fast we can type but it is true that adding any complication slows things.
So we better not to touch kitty code.
But kitty terminal displaying CJK-characters with millions of complicated shapes may
be the one benefit most by using GPU. So we as a distribution should offer easy
access to this feature at least as an opt-in feature.
Considering kitty is the only user of GLFW_IM_MODULE variable on Debian and it
shouldn't be turned on by default according to the upstream, I propose to add
following content as README.Debian in the Debian package of kitty.
----------
# Input Method support
You can enable input of non-Latin characters to the kitty terminal as follows:
1. Install required a set of input method program based on ibus or fcitx5
2. Place the following file named "kitty" in PATH
(e.g., ~/.local/bin or /usr/local/bin)
3. Meke "kitty" script an executable. (`chmod 755 kitty`)
---
#!/bin/sh -e
GLFW_IM_MODULE=ibus exec /usr/bin/kitty "$@"
---
fcitx5 uses the same communication protocol as ibus. So you use "ibus" even for
"fcitx5". Other input method infrastructure such as "fcitx" and "uim" are not
supported.
----------
For im-config, I think it is about time to kill upstream non-supported known broken
xim support by dropping to start daemon from im-config which sets how Debian behaves
as installed. xterm and rxvt may loose CJK input but we will get less bug report on
ill-configured modern GTK/Qt apps using xim.
Here is my thought on my practical and non-invasive solution.
inputs comes from the well known ibus/fcitx5 daemon related problem using xim as the
communication protocol and probably not applicable if dbus is used to call ibus/fcitx
library. The upstream's latency concern with dbus may be negligible compared to how
fast we can type but it is true that adding any complication slows things.
So we better not to touch kitty code.
But kitty terminal displaying CJK-characters with millions of complicated shapes may
be the one benefit most by using GPU. So we as a distribution should offer easy
access to this feature at least as an opt-in feature.
Considering kitty is the only user of GLFW_IM_MODULE variable on Debian and it
shouldn't be turned on by default according to the upstream, I propose to add
following content as README.Debian in the Debian package of kitty.
----------
# Input Method support
You can enable input of non-Latin characters to the kitty terminal as follows:
1. Install required a set of input method program based on ibus or fcitx5
2. Place the following file named "kitty" in PATH
(e.g., ~/.local/bin or /usr/local/bin)
3. Meke "kitty" script an executable. (`chmod 755 kitty`)
---
#!/bin/sh -e
GLFW_IM_MODULE=ibus exec /usr/bin/kitty "$@"
---
fcitx5 uses the same communication protocol as ibus. So you use "ibus" even for
"fcitx5". Other input method infrastructure such as "fcitx" and "uim" are not
supported.
----------
For im-config, I think it is about time to kill upstream non-supported known broken
xim support by dropping to start daemon from im-config which sets how Debian behaves
as installed. xterm and rxvt may loose CJK input but we will get less bug report on
ill-configured modern GTK/Qt apps using xim.
Gunnar Hjalmarsson
Nov 21, 2021, 10:10:04 AM11/21/21
to
On 2021-11-21 03:42, Osamu Aoki wrote:
> Considering kitty is the only user of GLFW_IM_MODULE variable on Debian and it
> shouldn't be turned on by default according to the upstream, I propose to add
> following content as README.Debian in the Debian package of kitty.
>
> ----------
> # Input Method support
>
> You can enable input of non-Latin characters to the kitty terminal as follows:
>
> 1. Install required a set of input method program based on ibus or fcitx5
> 2. Place the following file named "kitty" in PATH
> (e.g., ~/.local/bin or /usr/local/bin)
> 3. Meke "kitty" script an executable. (`chmod 755 kitty`)
>
> ---
> #!/bin/sh -e
> GLFW_IM_MODULE=ibus exec /usr/bin/kitty "$@"
> ---
>
> fcitx5 uses the same communication protocol as ibus. So you use "ibus" even for
> "fcitx5". Other input method infrastructure such as "fcitx" and "uim" are not
> supported.
> ----------
Yeah, such a wrapper is a convenient way to specify an environment
> Considering kitty is the only user of GLFW_IM_MODULE variable on Debian and it
> shouldn't be turned on by default according to the upstream, I propose to add
> following content as README.Debian in the Debian package of kitty.
>
> ----------
> # Input Method support
>
> You can enable input of non-Latin characters to the kitty terminal as follows:
>
> 1. Install required a set of input method program based on ibus or fcitx5
> 2. Place the following file named "kitty" in PATH
> (e.g., ~/.local/bin or /usr/local/bin)
> 3. Meke "kitty" script an executable. (`chmod 755 kitty`)
>
> ---
> #!/bin/sh -e
> GLFW_IM_MODULE=ibus exec /usr/bin/kitty "$@"
> ---
>
> fcitx5 uses the same communication protocol as ibus. So you use "ibus" even for
> "fcitx5". Other input method infrastructure such as "fcitx" and "uim" are not
> supported.
> ----------
variable for a specific application.
> For im-config, I think it is about time to kill upstream non-supported known broken
> xim support by dropping to start daemon from im-config which sets how Debian behaves
> as installed. xterm and rxvt may loose CJK input but we will get less bug report on
> ill-configured modern GTK/Qt apps using xim.
elaborate somewhere else? (This is no longer an im-config bug.)
--
Rgds,
Gunnar
0 new messages