Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore

[grunt2 at laposte.net]

‌My im-config shows:

Current configuration for the input method:
 * Default mode defined in /etc/default/im-config: 'auto'
 * Active configuration: 'missing' (normally missing)
 * Normal automatic choice: 'ibus' (normally ibus or fcitx5)
 * Override rule: 'zh_CN,fcitx5:zh_TW,fcitx5:zh_HK,fcitx5:zh_SG,fcitx5'
 * Current override choice: '' (Locale='fr_FR')
 * Current automatic choice: 'ibus'
 * Number of valid choices: 1 (normally 1)
 * Desktop environment: 'GNOME'
The configuration set by im-config is activated by re-starting the system.
La sélection explicite n'est pas nécessaire pour permettre la configuration automatique si la sélection active est default/auto/cjkv/missing.

I'm using an Azerty French Keyboard, where the backtick is the grave accent on the 7 key (Alt + 7) https://en.wikipedia.org/wiki/AZERTY#/media/File:KB_France.svg‌
(I call it the backtick, because it's also the character I type for markdown code formatting like `myObject.Fcn()`. But maybe I give it a bad name?)

Whatever, I'm sure that typing the ` under my 7 key followed by an A should return an À, like it once did, and that it doesn't do that anymore.
And I am also sure that it doesn't do that anymore since the bug that happened and affected the dead keys, and that its fix isn't complete.

Regards,
Marc Le Bihan‌

De : "Simon McVittie" <smcv at debian.org>
A : "Marc Le Bihan" <grunt2 at laposte.net>,1072720 at bugs.debian.org,team at security.debian.org
Envoyé: vendredi 7 Juin 2024 14:37
Objet : Re: Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore
 
On Fri, 07 Jun 2024 at 13:12:52 +0100, Simon McVittie wrote:
> On Fri, 07 Jun 2024 at 04:50:47 +0200, Marc Le Bihan wrote:
> > * What exactly did you do (or not do) that was effective (or
> > ineffective)?
> > Typing the backtick followed by a wovel: `A
> >
> > * What was the outcome of this action?
> > `A
> >
> > * What outcome did you expect instead?
> > À
>
> What desktop environment, what keyboard layout and what input method
> are you using? And what application are you typing this into?

It would be helpful to run the "im-config" tool, and copy/paste the text
that it displays into a reply to this bug report. What I get in a test
virtual machine is:

Current configuration for the input method:
* Default mode defined in /etc/default/im-config: 'auto'
* Active configuration: 'missing' (normally missing)
* Normal automatic choice: 'ibus' (normally ibus or fcitx5)
* Override rule: 'zh_CN,fcitx5:zh_TW,fcitx5:zh_HK,fcitx5:zh_SG,fcitx5'
* Current override choice: '' (Locale='en_GB')
* Current automatic choice: 'ibus'
* Number of valid choices: 1 (normally 1)
* Desktop environment: 'GNOME'
The configuration set by im-config is activated by re-starting the system.
Explicit selection is not required to enable the automatic
configuration, if the active one is default/auto/cjkv/missing.

but your result is presumably different.

I attempted to reproduce this problem in a virtual machine with:

* Debian 12
* GNOME
* German keyboard layout (configured in Settings → Keyboard → Input Sources):
https://en.wikipedia.org/wiki/QWERTZ#/media/File:German-Keyboard-Layout-T2-Version1-large.png
* gnome-text-editor or Libreoffice Writer as the application

GNOME uses ibus as its input method for most languages, including English
and German. ibus is the input method that was affected by #1070745.

I was unable to reproduce the bug with this combination of settings:

When I press the key that would be printed with acute [´] and grave [`]
accents on a German keyboard (2 positions to the right of the [0] key),
the application displays the accent with an underline (acute accent
´ U+00B4 if I do not use Shift, or grave accent/backtick ` U+0060 if I use
Shift). When I press Shift+[A], the underlined accent gets replaced by
Á or À, as appropriate.

If I want to type `A with that keyboard layout, I have to press:
Shift+[`], Space, Shift+[A].

I do not regularly use keyboard layouts that include dead keys, but to
the best of my knowledge, what I described is the expected behaviour
for keyboard layouts that include dead keys. If you would have expected
something different, please describe it.

If this is not the result that you see, please describe what is different
about your system or how I can reproduce the problem.

Thanks,
smcv

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20240608/f7800388/attachment.htm>