Losing the keyboard on F12

[Getafix]

@jh145: All of the below have been checked as 'buggy'.

LXLE 12.04 / 32-bit / Openbox
XMODIFIERS has the value @im=ibus and ibus version is ... ehm, well... due to incorrect O/S configuration, I couldn't get that.

Ubuntu 14.04 / 64-bit / Compiz
XMODIFIERS has the value @im=ibus and ibus version is 1.5.5

Fedora 22 / 64-bit / Gnome
XMODIFIERS has the value @im=ibus and ibus version is 1.5.10

The good news is that executing

Code: Select all

$ XMODIFIERS='' ~/GNUstep/Applications/Oolite/oolite

seems to tackle the issue for all three aforementioned systems.

I would like to have this tested by a Commander having a keyboard with accented letters (i.e. á, é, í, ó, ú, ü, etc.).
Do we get the same text input behavior, editing ship registration, with and without XMODIFIERS='' preceding the Oolite command?

[Getafix]

Just a final attempt to revive this, before marking as "Solved".

Is there anybody out there with a French, German or other non QWERTY keyboard layout that could check "Edit ship registration" with a new Jameson running Oolite as follows?

Code: Select all

$ XMODIFIERS='' ~/GNUstep/Applications/Oolite/oolite

[Norby]

I have "éáöüóűőúí" keys but XMODIFIERS already empty both under Debian and Mint so these keys does nothing in Oolite regardless of started normally or with your method. (All other programs can use these keys.)

[jh145]

I vote we modify the start script and wait for complaints. Specifically, if XMODIFIERS points to ibus, set it null, print a big warning to stderr, then start Oolite. Give this (or another relevant) thread id in the warning for feedback.

[Getafix]

@Norby
Many thanks for the crystal clear feedback.

@jh145
Changing the startup script universally to address such Linux distro-dependent caprice, is not suggested.
Furthermore, it would only address the case for oolite.org package installations. Oolite installations coming from packages downloaded from Linux repositories will still have the issue. Perhaps, if an elegant solution cannot be found, ignoring it, or just mentioning the manual workaround in a readme file, could also be an approach; violently assaulting F12, is not a frequently encountered behavior after all.

[jh145]

I encountered the problem plenty often enough without "violently assaulting" my keyboard. A single tap on F12 on startup, done quick enough (as I often did due to impatience), was sufficient to trigger keyboard lock-out.

I can't see the problem modifying the trunk nightly as I described. You'd quickly find out if it gave rise to a serious issue. By all means move the fix deeper into the code if the startup scripts are oolite.org-specific. Keeping the fix only in this thread or a README is a great way to effectively lose the work done up to this point, so please don't do that.