After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 736667 - gnome-shell should not limit the length of InputMode properties to 2 characters
gnome-shell should not limit the length of InputMode properties to 2 characters
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
3.10.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2014-09-15 10:13 UTC by Mike FABIAN
Modified: 2021-07-05 14:24 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Mike FABIAN 2014-09-15 10:13:04 UTC
gnome-shell-3.10.4-8.fc20.x86_64

When initializing the indicator label, no particular limit is
enforced for the length of “shortName”:

    /usr/share/gnome-shell/ui/status/keyboard.js:714

    const InputSource = new Lang.Class({
        Name: 'InputSource',

        _init: function(type, id, displayName, shortName, index) {
            this.type = type;
            this.id = id;
            this.displayName = displayName;
            this._shortName = shortName;
            this.index = index;

            this._menuItem = new LayoutMenuItem(this.displayName, this._shortName);
            this._menuItem.connect('activate', Lang.bind(this, this.activate));
            this._indicatorLabel = new St.Label({ text: this._shortName });

            this.properties = null;
        },
    [...]

But when updating the indicator label because of the property “InputMode”,
the text is ignored when it is longer then 2 characters:

    /usr/share/gnome-shell/ui/status/keyboard.js:714
    
    _buildPropSubMenu: function(menu, props) {
        if (!props)
            return;

        let radioGroup = [];
        let p;
        for (let i = 0; (p = props.get(i)) != null; ++i) {
            let prop = p;

            if (!prop.get_visible())
                continue;

            if (prop.get_key() == 'InputMode') {
                let text;
                if (prop.get_symbol)
                    text = prop.get_symbol().get_text();
                else
                    text = prop.get_label().get_text();

                if (text && text.length > 0 && text.length < 3)
                    this._currentSource.indicatorLabel.set_text(text);
            }
    [...]

This is a bit inconsistent.

ibus-typing-booster for example uses the symbol “en-GB” for British English
which is 5 characters long and displayed fine (ibus-typing-booster
does not use an “InputMode” property).

But the most recent version of ibus-table uses an “InputMode”
property and for the non-Chinese tables it sets the symbol
to  “'☑' + symbol” when the input method is active and
“'☐' + symbol” when the input method is in direct keyboard mode.
So this works only when “symbol” is no longer than 1 character.
But some tables have slightly longer symbols, e.g. translit has
the symbol “Ya” and translit-ua has the symbol “Yi”.

I think “☑Ya”/“☐Ya” is still reasonably short and should be allowed,
especially if such symbols are allowed during initialization.

So could the check “text.length < 3” be removed? Or at least a somewhat
longer value like “text.length < 6” be used?
Comment 1 Matthias Clasen 2014-09-15 10:49:01 UTC
I don't think input methods should cheat by putting control-like characters into their display name. If it is important to display information about 'keyboard mode', that should be handled by the shell, not in this way.
Comment 2 GNOME Infrastructure Team 2021-07-05 14:24:36 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.