No text input in non native NS/NX apps

[pcardona34]

Hi Sergii,

I launched Chromium web browser from the Terminal.app.
There was a GS menu and AppIcon.

But when I tried to type text in the web browser window (URL bar, text fields) nothing was typed. So the web browser is useless.
I needed to use an alternate OS to type this issue.

[trunkmaster]

Can't reproduce it. Works for me.

[pcardona34]

I better understand the context that produce the issue: it is related to locale.
The text input is correct within the native NS applications: Terminal, TextEdit... But not with the other graphic applications.

How to reproduce:

• Your locale is en_US.UTF-8.
• If You choose an English keyboard Layer (i.e.: English (US)) in the Preferences, You should be able to input text in all context, but it is QWERTY.
• But if You choose up a French keyboard Layer (i.e.: French, alt, French,AZERTY), no input in xedit, xterm, etc.
• The LANGUAGE default up in Preferences is not modifying this issue.

On the same machine, before installing NeXTspace, I tried the input in X context and it worked fine. So it seems like an issue related to Workspace/Wmaker and the locale.

[trunkmaster]

Got it, another locale issue. Thanks, i'll see what can I do.

[trunkmaster]

I better understand the context that produce the issue: it is related to locale. The text input is correct within the native NS applications: Terminal, TextEdit... But not with the other graphic applications.

How to reproduce:

* Your locale is `en_US.UTF-8`.

* If You choose an English keyboard Layer (i.e.: `English (US)`) in the `Preferences`, You should be able to input text in all context, but it is QWERTY.

* But if You choose up a French keyboard Layer (i.e.: `French, alt`, `French,AZERTY`), no input in `xedit, xterm, etc`.

Works for me. I've added new layout in "Keyboard Preferences", "Layouts" section the "French, AZERTY". Try to type in xterm: if I type q on my ANSI keyboard a displayed in xterm. It works with system locales: en_US.UTF-8 and uk_UA.UTF-8 (set by localectl).

* The `LANGUAGE` default up in `Preferences` is not modifying this issue.

Unlike the "Keyboard Preferences -> Layouts" settings (changes X11 configuration) "Language" setting in "Localization Preferences" changes only the behavior of GNUstep applications.

On the same machine, before installing NeXTspace, I tried the input in X context and it worked fine. So it seems like an issue related to Workspace/Wmaker and the locale.

Have you changed keyboard model (Keyboard Preferences->Model)? I use "Generic 105-key PC".

[pcardona34]

Well, I did again the way to reproduce the issue and I must precise some steps:

1. We set default LANG as 'en_US.UTF-8': # localectl set-locale en_US.UTF-8

2. You must then:

• Log out (Workspace) and also stop Login.app: # systemctl stop display-manager.service;
• Log out (console) and log in again.
• Now You can see that the "$LANG" setting is the same with locale and localectl listing. It would'nt until that.
• Restart Login.app: # systemctl start display-manager.service and log in again in the Workspace...

3. Well, in the Keyboard Preferences add two layouts: an 'English (X)' one and another: 'French', 'Spanish'...

4. Push the 'English' Layout at the top of the Layouts list.

5. Open an X apps (xterm, xedit...) and note that You can input text.

6. If You keep the same X app window opened, and You push up now the other Layout ('French', etc.) at top, You can note that the input is still available: it is a kind of inheritance of the Input property.

7. Now, close the X app window, and open a new one, with already the 'French' Layout at top: now You should note that the input is no more available. And because this input is lost there, even You push at top now the 'English' Layer, You won't get the input. The lost input property is also inherited.

---

The following test should be now to set locale $LANG = fr_FR.UTF-8 to improve the hypothesis of a LANG context dependency for the input available property of the Layout, but it is not yet possible due to the issue: #451 .

[pcardona34]

To complete the previous message, I also could get this warning after X org closed:
The KEYBOARD keymap compiler (xkbcomp) reports:

Warning: Multiple definitions of the FOUR_LEVEL_KEYPAD key type
Earlier definition ignored
Errors from xkbcomp are not fatal to X server

And then usual message of xinit...

It is like a bad assumption about the keyboard mapping is disabling the system Xorg keyboard setting. Maybe a conflict with keyboard setting from the NX Preferences ?

[pcardona34]

Hi Sergii,
I think I can give You a better view of a kind of inconsistancy with the 'keyboard preferences' in NEXTSPACE.
In the same time:

• Localectl 'x11 Layout' says: fr (French Layout)
• Layout Switcher in the Workspace Icon is one step late and shows the previous selected Layout in 'Keyboard Preferences/Layout': Fr(ench) while the present one is 'Spanish'.
• setxkbmap -print -verbose says: Layout 'us'...

The fact is, either the Layout is in Terminal (according with 'Keyboard Preferences') in other X11-apps (xterm, xedit...) the Layout seems to ever be 'us'. So the only time we could input text with those apps is when Layout 'us' has been choosen also in 'Keyboard Preferences' and then
herited in 'Terminal'.

Also, in the left up Terminal, You can see some error message:

'Could'nt interpret _XKB_RULES_NAMES property' which is followed by 'Use defaults: rules - 'base' model - 'pc105' laout 'us''

[pcardona34]

P.S.: My context is the latest build from sources under Debian 12.10 (arm64, pi400)

[pcardona34]

Because there is not a native GNUstep Web Browser, we need to use a wrapped or xembedded one, so this is harmful bug which could prevent non English native users to adopt NEXTSPACE. Hope We can find the way to fix it.

[trunkmaster]

@pcardona34 I'm non-English speaker and have no problem on using X applications. I have no problem on using "105-key PC" keyboard with English and Ukrainian layouts.
Probably it's a case with non-standard keyboard layout like you have.

[pcardona34]

Please, Sergii, consider with attention what I have shown two weeks ago (see the above comment with the screenshot): this is not an exotic layer issue, but an issue in the way the 'Preferences App' is falling with a sticky 'us' layout when You try to change it.

[pcardona34]

Maybe another clue:

This is in the RPI OS default Desktop (DESKTOP_SESSION=LXDE-pi):

patrick@pi400:~ $ setxkbmap -print
xkb_keymap {
xkb_keycodes { include "evdev+aliases(azerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+fr(oss)+inet(evdev)" };
xkb_geometry { include "pc(pc105)" };
};

Note the 'evdev' key word both at the 'xkb_keycodes ' and 'xkb_symbols' lines.

And now, within NEXTSPACE:

patrick@pi400next:~ $ setxkbmap -print
Couldn't interpret _XKB_RULES_NAMES property
Use defaults: rules - 'base' model - 'pc105' layout - 'us'
xkb_keymap {
xkb_keycodes { include "xfree86+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+us+inet(pc105)" };
xkb_geometry { include "pc(pc105)" };
};

Note the 'evdev' word is not there.

And because of the '_XKB_RULES_NAMES property' error, it seems none of all the setxkbmap settings are applied then.

If I try to force these settings produced by setxkbmap -print with the following setting file: 'clavier.txt' (removing the warning above):

xkb_keymap {
xkb_keycodes { include "xfree86+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+us+inet(pc105)" };
xkb_geometry { include "pc(pc105)" };
};

And with this command:

cat clavier.txt | xkbcomp - $DISPLAY

Then many symbols are lost, like the direction keys, etc.

lost_symbols.txt

Hope this could help to understand the issue.
I confirm this issue also on my MacBook Pro Intel with French AZERTY layout and also within all my virtual machines under debian 12 (aarch64 and amd64 ones).

[pcardona34]

Hello Sergii,

Same issue under 'Fedora 41' (server Edition), so it is not a 'debian' specific issue. As I did before, the test was:

• In Terminal.app: I can see the keymap seems to be correct, inherited from OS settings (localectl).
• But within xedit (X11 app) launched from Terminal.app : no input.

About the hardware hypothesis: the keyboard of the 'pi400' is connected to the SOC with an internal USB 2.0 port. It is a Holtek made, like lsusb give the info:

Bus 001 Device 004: ID 04d9:0007 Holtek Semiconductor, Inc. Raspberry Pi Internal Keyboard

If it was a hardware issue, it should not work even in Terminal.app, but it does.

And because, the same issue happens even on my well known Intel MacBook Pro, I think it is not a matter of odd hardware consideration.

Maybe the source of the issue is related to the way the OS is set up before I install NEXTSPACE on. In my case, I always started from a minimal setup (a lite OS or a server image) and maybe something obvious is missing related to the X11 setup. Could You please describe the prerequisite about this: how do you set up your OS before ?