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 ?

[FuryOusFrank]

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 ?

I made a minimal install in Debian 12 using the French Canadian language and layout (fr_CA) before installing NEXTSPACE. I launched once the Xserver to try writing in xterm. It worked with the proper layout. I proceeded to install NEXTSPACE from source.

Afterwards, I lost the ability to write in xterm. Like you, if I switch to the US keyboard from the preferences panel, I gain the ability to write in xterm. The proper French Canadian layout ("French (Canada), intl.", known as "ca multix"), which is available in Debian, is shown in the Enable layouts subsection if it was set up before the installation of NEXTSPACE. There is a French (Canada) keyboard layout in the Add layout chooser, but the Multilingual variant is not available there.

Changing the layout after xterm was launched, from US to "French (Canada), intl." , allows typing with the proper layout.

[FuryOusFrank]

My temporary solution is a launcher script that sets the keyboard to us for a couple of seconds before setting the keyboard to French Canadian (multilingual). At this point, the keyboard definition is hardcoded, but a better script could allow the selection of a layout and be included in a GNUstep wrapper.

#!/bin/bash

# Force 'us' xkbmap
setxkbmap us

# Launch application in background
"$@" &

# Wait
sleep 2

# Switch to ca multix xkbmap
setxkbmap -layout ca -variant multix -model pc105

[pcardona34]

Hello FuryOusFrank,

Thank you for the clue: I could type this comment under NEXTSPACE and chromium launched with this bash script:

#!/bin/bash
 
# Force 'us' xkbmap
setxkbmap us
 
# Launch application in background
"$@" &

# Wait
sleep 2

# Switch to French xkbmap
setxkbmap -layout fr -model pc105

Although it fixes a part of the issue, it is not all solved:

• Using this work around, I am lacking the direction keys (left, right, up, down) and so no history command... To get those again, I must set again the layout within the Preferences.app.

• I think this is an issue related to setxkbmap.

[FuryOusFrank]

Hi. You're right.

Although it fixes a part of the issue, it is not all solved:

• Using this work around, I am lacking the direction keys (left, right, up, down) and so no history command... To get those again, I must set again the layout within the Preferences.app.
• I think this is an issue related to setxkbmap.

setxkbmap doesn't solve everything. xkbcomp is better (arrows are working), but I still loose the ability to use dead keys (^+ letter).

Also, since "ca (multix)" is not one of the options in Keyboard Preferences, it gets removed from the Enabled Layouts. If have to edit NXGlobalDomain to put it back. I don't have this issue on my other system which uses the "ca" keyboard without any variant.

Here's a new script. Not perfect, but a little more useful.

#!/bin/bash

# Command to launch
COMMAND="$*"

# Keyboard backup
BACKUP_FILE="/tmp/xkb-layout.bak"
echo "Saving current XKB config"
xkbcomp "$DISPLAY" "$BACKUP_FILE"

# Setting keyboard to 'us'
echo "Setting layout to 'us'"
setxkbmap us

# Command launching
echo "Launching: $COMMAND"
bash -c "$COMMAND" &

# Wait 2 seconds
sleep 2

# Restore previous layout
echo "Restoring original XKB layout"
xkbcomp "$BACKUP_FILE" "$DISPLAY"</pre>```

[pcardona34]

Hi @FuryOusFrank, thank you for this great enhancement:

• Now my French alt (fr-oss variant) layout is working with all the keys within the X11 apps and I get the layout back within NEXTSPACE without any change afterward: successfully tested with xedit, chromium.

• The only case still not working is when an X11 app is xembedded in a GNUstep wrapper like it does within gs-webbrowser.app by Ondrej Florian; in this case, it is chromium within a GNUstep wrapper, which provides url services, use of pastboard...

[D4yvid]

The issue can be reproduced with the Portuguese (Brazillian) layout too.

[D4yvid]

I was testing with xev, and when i type something in the window, it receives this sequence when i press a key (using a non-US layout):

KeymapNotify
FocusOut
FocusIn
<and repeats for each key pressed>

When i use a US layout (English (US)), i receive this instead:

KeyPress
KeyRelease
<and repeats for each key pressed>

If i run xev on xinitrc directly, i get the same result as the layout being English (US). I'm attaching three xev.log files, xev.log (xev in xinitrc without WM), xev.nextspace.log (xev with Portuguese (Brasil) layout) and xev.nextspace.uslayout.log (xev with the US layout):

xev.log

xev.nextspace.log

xev.nextspace.uslayout.log

I hope this can help fix the issue, i'm trying to read the source code but it's a little confusing for me.

@trunkmaster

[D4yvid]

https://github.com/trunkmaster/nextspace/blob/b4b491e85ad3021fa0591f780775dd211c616ec4/Applications/Workspace/WM/event.c#L1447-L1450

If i place an else case in this if statement, xev receives an KeyPress event, but i don't know if it's the right place to put this code. Also, all other events from the non-US keyboard layout also are sent, and i cannot send an KeyRelease event here, so it's broken even with this else statement.

The else statement:

} else {
  // Non GNUstep application
  XSendEvent(dpy, wwin->client_win, True, KeyPress, event);
}

[trunkmaster]

nextspace/Applications/Workspace/WM/event.c

Lines 1447 to 1450 in b4b491e if (wwin && wwin->flags.is_gnustep) { XSendEvent(dpy, wwin->client_win, True, KeyPress, event); } return;

If i place an else case in this if statement, xev receives an KeyPress event, but i don't know if it's the right place to put this code. Also, all other events from the non-US keyboard layout also are sent, and i cannot send an KeyRelease event here, so it's broken even with this else statement.

The else statement:

} else { // Non GNUstep application XSendEvent(dpy, wwin->client_win, True, KeyPress, event); }

It's strange if it works. The purpose of the original code is for GNUstep applications only. It's for the case when key press with modifier occured but no configured shortcuts in window manager found. No need to send key press to non-GNUstep applications - it works as is - and this is how original Window Maker code works.

[trunkmaster]

I've tried to reproduce bug with this setup

Works as expected - I have input in both GNUstep and non-GNUstep applications with all listed layouts.

[D4yvid]

I've tried to reproduce bug with this setup

Works as expected - I have input in both GNUstep and non-GNUstep applications with all listed layouts.

The issue appears only when you create a new window with a modified keyboard layout (non-US), the newly created window will not have input (if it's non-GNUstep application, if it's a native NS/NX app it will work just fine)

I don't know if it's a issue on my side, i even compiled NEXTspace on WSL to test and still doesn't work as expected with the Portuguese (Brazillian) layout

[D4yvid]

I was not able to upload directly to GitHub, so i uploaded a video on YouTube for showing the issue: https://www.youtube.com/watch?v=JiVPwmJqa8k

[trunkmaster]

@D4yvid thanks for video explanation. First of all I've noticed strange thing that you even not able to set layout in Preferences. It works fine for me. Second, you're using setxkbmap at the first step - what for?

And the most important - I still can't reproduce the issue.

I have an idea: try to add "English (US)" as the topmost layout in "Enabled Layouts" as on my screenshot. I suspect that issue appears when non-english layout is the first (or only) configured layout.

[pcardona34]

Hello Sergii, hello everybody,

Using the tip above: 'English (US)' layout at top, and switching to French with <Cmd+Space>: so the 'FR' indice is showing now on the top icon of the Dock; I was able then to enter and save French text in Xedit, then typing this comment within chromium web-browser started from the same Terminal.

This might be pinned up, maybe to the wiki? Or an Alert Panel could be shown when somebody put down the default 'English (US)' in the 'enabled Layouts' list.

I shall test also if this way is persistent after a new login and with a wrapped X app.

[pcardona34]

• After a new login, the switch is not persistent. Well, <Cmd+Space> is needed again.

• More serious:

1. After the switch to French, The <AltGr> modifier does not function: so missing: @ ♯ and so on.
2. None of the variants I tried are functional: so I can switch to 'French' only, not to 'French,Alt' (missing œ Œ) nor to French,AZERTY-AFNOR... etc.

[D4yvid]

@D4yvid thanks for video explanation. First of all I've noticed strange thing that you even not able to set layout in Preferences. It works fine for me. Second, you're using setxkbmap at the first step - what for?

The problem with the Preferences app is actually a WSL issue that i've never seen before, it only happens on WSL. The setxkbmap ran at the beginning was just to test if the command existed, when executed without arguments, it doesn't do nothing (I even typed ç characters to indicate non-US layout)

And the most important - I still can't reproduce the issue

Weird.... i'll try building a VM image where the problem can be reproduced so you can test!

I have an idea: try to add "English (US)" as the topmost layout in "Enabled Layouts" as on my screenshot. I suspect that issue appears when non-english layout is the first (or only) configured layout.

When "English (US)" is on the top of the list of configured layouts, all works as expected, at least on my older tests on a Debian 12 system, but as stated by @pcardona34, you need to change the keyboard using the keybinding.

When i finish the VM image, i'll attach it here so you can test it properly! @trunkmaster

[D4yvid]

• After a new login, the switch is not persistent. Well, <Cmd+Space> is needed again.

  • More serious:

  1. After the switch to French, The <AltGr> modifier does not function: so missing: @ ♯ and so on.

  2. None of the variants I tried are functional: so I can switch to 'French' only, not to 'French,Alt' (missing œ Œ) nor to French,AZERTY-AFNOR... etc.

This also happens if you use Portuguese (Brazillian) - tested on a new install of Debian 12 Bookworm