Re: Patched ibus version

[Eberhard Beilharz <eb1@sil.org>]

Now it's 7 weeks later and nothing has happened since then. There have been no further comments from upstream on either the issue nor the PR.

I contacted Mike Fabian a few times but didn't get any response from him.

> With that said, as long as it's just an
>         opt-in, and you can guarantee that it does not affect other
>         engines by default, I suppose we can carry a Debian patch as a
>         last resort.
>         
>       
      Yes, it is opt-in. It should not affect any of the existing
      engines. The patch sets an additional flag in the capabilities,
      and checks an additional bit (`IBUS_PREFILTER_MASK`) in the modifier state. If the bit is set
        (which will only be done by an engine that decides to use this
        new flag) it basically ignores the `IBUS_IGNORED_MASK` flag
          and sends the key press back to the engine (instead of the
          client app).

I can't guarantee that it doesn't affect other engines since I don't know what bugs they have that will show up with these changes. But if they are implemented properly and according to the widespread best practices they won't be affected. A scenario where they would be affected would be if they would compare hard coded values for the modifier state instead of  using the masks that ibus defines.

To sum up - I'm confident that it won't affect other engines.

So I guess this means I should prepare a patch and upload a new ibus version to mentors? Or what's the procedure?

Thanks,
    Eberhard

Gunnar Hjalmarsson wrote on 2023-12-14 21:09:

> On
>       2023-12-14 20:19, Shengjing Zhu wrote:
>       
> > On Fri, Dec 15, 2023 at 2:28 AM Eberhard
> >         Beilharz <eb1@sil.org>
> >         
> >         wrote:
> >         
> > > Keyman requires a patched version of
> > >           ibus to function properly in
> > >           
> > >           all cases. The unpatched ibus version doesn't always output
> > >           
> > >           characters in the correct sequence if the ibus engine uses
> > >           
> > >           backspace to delete a character. This is the case with apps
> > >           that
> > >           
> > >           don't support surrounding text, like Chromium, and for engines
> > >           that
> > >           
> > >           can't use pre-edits, like Keyman.
> > >           
> > >           
> > >           This bug is documented in ibus bug #2539 and a suggested fix
> > >           is in
> > >           
> > >           PR #2440. However, the upstream maintainer won't accept the
> > >           fix
> > >           
> > >           because he doesn't see the need for it nor does he have a
> > >           different
> > >           
> > >           solution (other than suggesting to rewrite Keyman and use
> > >           
> > >           pre-edits, which is not possible for the languages that Keyman
> > >           
> > >           supports).
> > >           
> > >           
> > >           Would it be possible to include the patch in the Debian
> > >           package? In
> > >           
> > >           that case I'd create a Debian issue and attach the patch.
> > >           
> > >           
> > >           Otherwise I would create a new package that is compatible with
> > >           ibus
> > >           
> > >           but contains the fix.
> > >           
> > >           
> > >           Ibus issue: https://github.com/ibus/ibus/issues/2539
> > >           
> > >         
> >         
> >         IMO it's too early to ask downstream to decide the choice. The
> >         last
> >         
> >         comment from upstream is 2 weeks ago and no further response
> >         from
> >         
> >         you. Could you be more patient with upstream to elaborate your
> >         
> >         problem?
> >         
> >       
>       
>       I can agree that you ask a bit prematurely. One idea is that you
>       ask Mike Fabian to look at it. He maintains e.g. ibus-m17n and
>       ibus-typing-booster, and should be aware of the special needs of
>       Asian scripts.
>       
>       
>       With that said, as long as it's just an opt-in, and you can
>       guarantee that it does not affect other engines by default, I
>       suppose we can carry a Debian patch as a last resort.
>       
>       
>

Attachment: OpenPGP_0xE9140597606020D3.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature