OISInput.cfg: input text fields don't work

Problems and solutions for installing or running FreeOrion, including discussion of bugs if needed before posting a bug report on GitHub. For problems building from source, post in Compile.

Moderator: Oberlus

Message
Author
Apo
Space Squid
Posts: 89
Joined: Fri Apr 19, 2013 4:10 pm

OISInput.cfg: input text fields don't work

#1 Post by Apo »

Hi,

this is Debian bug #719496 http://bugs.debian.org/719496

Apparently some users can't edit input fields in FreeOrion and type the path of a sound file or the name of a new save game. It appears the reason for that are the default values in OISInput.cfg which override or circumvent system default values for a particular desktop environment like razor-qt or Xfce.

I already asked some questions about OISInput.cfg here:

viewtopic.php?f=28&t=7678

I can't reproduce this issue on my system (I tested the game on Gnome 3, Xfce, razor-qt and a pure window manager setup with Openbox). Though I believe those users that something doesn't work as expected.

A solution seems to be to disable or comment out all Linux related lines in OISInput.cfg or to set x11_keyboard_grab to true (works only for one user). Hence I'd like to propose the following:

OISInput.cfg is installed into the RootDataDir. On Linux/Unix systems this is the wrong place for editable configuration files. The file should be installed either to /etc/freeorion (global) or to ~/.freeorion (per user). I suggest to comment out all Linux related lines in OISInput.cfg by default and let the desktop environment handle mouse and keyboard input requests as far as possible. If problems occur the user can still tweak OISInput.cfg at the aforementioned location. I would prefer the user's HOME directory.

To achieve this, It is necessary to modify client/human/chmain.cpp line 287.

What are your thoughts?

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: OISInput.cfg: input text fields don't work

#2 Post by adrian_broher »

Others, what is the OIS variant in the repository? The history tells me that is was added with Ogre 1.8. It can't be OIS 1.3 because the source tree is completely different (or it was 'adapted').
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: OISInput.cfg: input text fields don't work

#3 Post by Geoff the Medio »

adrian_broher wrote:...what is the OIS variant in the repository?
As the commit logs state, it was the latest revision of OIS I could find at the time of commit 5192, probably from here. Vezzra then modified the OSX code slightly a few weeks later.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: OISInput.cfg: input text fields don't work

#4 Post by Geoff the Medio »

I suggest to comment out all Linux related lines in OISInput.cfg by default and let the desktop environment handle mouse and keyboard input requests as far as possible. [...] If problems occur the user can still tweak OISInput.cfg at the aforementioned location.
Seems reasonable, if it works for most people with the default settings.
OISInput.cfg is installed into the RootDataDir. On Linux/Unix systems this is the wrong place for editable configuration files. The file should be installed either to /etc/freeorion (global) or to ~/.freeorion (per user). [...] I would prefer the user's HOME directory.
I have no opinion on where such files should go.
To achieve this, It is necessary to modify client/human/chmain.cpp line 287.
If you put it in an preprocessor block just for Linux, that's probably fine.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: OISInput.cfg: input text fields don't work

#5 Post by Dilvish »

Apo wrote:A solution seems to be to disable or comment out all Linux related lines in OISInput.cfg or to set x11_keyboard_grab to true (works only for one user).
commenting out the Linux lines leaves the default values at
mouse_grab=true; grabKeyboard = true; hideMouse = true
which (edit: at least the two grabs) seem like terrible values to me, and I can't believe the majority of users would prefer them. In order to escape the keyboard and mouse grab in order to resize the FO screen or switch to another app, you have to alt-tab, which at least for me very often leaves the FO cursor doubled up in a confusing and ugly way (with the second cursor often up to several cm from the first cursor.
Hence I'd like to propose the following:
OISInput.cfg is installed into the RootDataDir. On Linux/Unix systems this is the wrong place for editable configuration files. The file should be installed either to /etc/freeorion (global) or to ~/.freeorion (per user).
Sounds reasonable to me
I suggest to comment out all Linux related lines in OISInput.cfg by default and let the desktop environment handle mouse and keyboard input requests as far as possible.
As explained above, I would object to that as the default unless there were persuasive evidence that such really were better for the majority of players.
If problems occur the user can still tweak OISInput.cfg at the aforementioned location.
I think the defaults should remain as they are currently and the folks who have problems with that can do the editing.
I would prefer the user's HOME directory.
I concur.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

AndrewW
Juggernaut
Posts: 791
Joined: Mon Feb 04, 2013 10:15 pm

Re: OISInput.cfg: input text fields don't work

#6 Post by AndrewW »

Dilvish wrote:
I would prefer the user's HOME directory.
I concur.
I agree, a good place to put user editable configuration files.

Apo
Space Squid
Posts: 89
Joined: Fri Apr 19, 2013 4:10 pm

Re: OISInput.cfg: input text fields don't work

#7 Post by Apo »

Dilvish wrote:
Apo wrote:A solution seems to be to disable or comment out all Linux related lines in OISInput.cfg or to set x11_keyboard_grab to true (works only for one user).
commenting out the Linux lines leaves the default values at
mouse_grab=true; grabKeyboard = true; hideMouse = true
which (edit: at least the two grabs) seem like terrible values to me, and I can't believe the majority of users would prefer them. In order to escape the keyboard and mouse grab in order to resize the FO screen or switch to another app, you have to alt-tab, which at least for me very often leaves the FO cursor doubled up in a confusing and ugly way (with the second cursor often up to several cm from the first cursor.
I can't see any difference on my system if I set grab_keyboard to true or false but obviously there are use cases when this doesn't hold true anymore. The default values seem to be reasonable except the grabKeyboard=false setting. I think it makes sense to set it to true by default because it affects people even if they play the game in fullscreen mode. Why wouldn't you want keyboard focus in-game?

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: OISInput.cfg: input text fields don't work

#8 Post by Geoff the Medio »

Apo wrote:Why wouldn't you want keyboard focus in-game?
I think there's a difference between grabbing focus and having focus. The former might mean that if FreeOrion crashed, you'd be unable to switch windows and might have to reboot the system, since FreeOrion had exclusive keyboard access.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: OISInput.cfg: input text fields don't work

#9 Post by Dilvish »

Geoff the Medio wrote:
Apo wrote:Why wouldn't you want keyboard focus in-game?
I think there's a difference between grabbing focus and having focus. The former might mean that if FreeOrion crashed, you'd be unable to switch windows and might have to reboot the system, since FreeOrion had exclusive keyboard access.
A minor additional nuisance with FO keyboard grab on (even if FO mousegrab is left off due to the problems I mention above), using the mouse to click over to another window (such as I often do to swap over to write here about something I'm testing ingame, or to swap to a screenshot program) still leaves the keyboard locked to FO and instead of typing a message I discover I'm sending key commands to FO. Since key commands in FO currently mostly just change focus in various ways, that wouldn't be a huge problem for myself or other players running into the same thing, but I'm not crazy about a setup that would clash with us ever adding more significant key commands. Apo, you may not have seen this if you did your testing only in fullscreen mode, or otherwise simply used alt-tab to switch out of FO, since alt-tab relinquishes the grabs.

Do we have any info about the extent and conditions of actual user need for keyboard-grab?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Apo
Space Squid
Posts: 89
Joined: Fri Apr 19, 2013 4:10 pm

Re: OISInput.cfg: input text fields don't work

#10 Post by Apo »

Apo, you may not have seen this if you did your testing only in fullscreen mode, or otherwise simply used alt-tab to switch out of FO, since alt-tab relinquishes the grabs.
That's true. I'm playing FreeOrion only in fullscreen mode and I haven't had any problems so far with keyboard grab. Alt-Tab works also perfectly fine. :)
Do we have any info about the extent and conditions of actual user need for keyboard-grab?
Good question. I'd like to learn more about why this is only problematic for a particular group of users and why in my case it doesn't matter if I set keyboard grab to true or false.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: OISInput.cfg: input text fields don't work

#11 Post by Dilvish »

Apo wrote:I'd like to learn more about why this is only problematic for a particular group of users and why in my case it doesn't matter if I set keyboard grab to true or false.
For your case, it sounds like it's fairly clear that it doesn't matter to you because you're checking keyboard issues after using alt-tab, which relinquishes the keyboard grab until FO is again the active/top app. Try playing in windowed mode & swap apps via mouseclick rather than alt-tab & see if your keyboard will then still work with that other app (which I don't think it should since that's pretty much the practical definition of keyboard-grab).
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Apo
Space Squid
Posts: 89
Joined: Fri Apr 19, 2013 4:10 pm

Re: OISInput.cfg: input text fields don't work

#12 Post by Apo »

Dilvish wrote:
Apo wrote:I'd like to learn more about why this is only problematic for a particular group of users and why in my case it doesn't matter if I set keyboard grab to true or false.
For your case, it sounds like it's fairly clear that it doesn't matter to you because you're checking keyboard issues after using alt-tab, which relinquishes the keyboard grab until FO is again the active/top app. Try playing in windowed mode & swap apps via mouseclick rather than alt-tab & see if your keyboard will then still work with that other app (which I don't think it should since that's pretty much the practical definition of keyboard-grab).
I can see the difference now.

1. So we have a consensus that it is more reasonable to install OISInput.cfg into the user's home directory.

2. We have no consensus about the default values but we know that some users can't type in text in FreeOrion no matter whether they play in fullscreen or windowed mode with keyboard grab = false. Is there a better solution than to just tell them to modify OISInput.cfg to suit their needs?

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: OISInput.cfg: input text fields don't work

#13 Post by adrian_broher »

Apo wrote:2. We have no consensus about the default values but we know that some users can't type in text in FreeOrion no matter whether they play in fullscreen or windowed mode with keyboard grab = false. Is there a better solution than to just tell them to modify OISInput.cfg to suit their needs?
I don't like the idea of exposing the options at all. The offending part of the code should be fixed instead of telling the user the equivalent of "here you have a adjusting wheel which you can turn, maybe this works for you, maybe not."

Reading the debian bug about the inconsistent time this problem occurs I would like to know if some notification mechanism snitches away the focus of the window. Maybe that is something your user should test with some x11 event tracing. xtrace or xev maybe show us the relevant hint.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: OISInput.cfg: input text fields don't work

#14 Post by Geoff the Medio »

Apo wrote:Is there a better solution than to just tell them to modify OISInput.cfg to suit their needs?
I suspect it's a problem with how OIS works, or how it's being used by FreeOrion. If that's the case, I don't know how to fix or improve the current behaviour. OIS isn't being maintained much, if at all, and has never worked as nicely as the old SDL input system that was used before the switch to OGRE, at least for mouse behaviour on Windows, in my opinion.

There might be other projects using OIS that could be inspected to see if there's something different about how OIS is being set up.

Alternatively, if someone wanted to replace OIS with a suitable alternative free / open source OGRE-compatible multi-platform input library, that might be better. "Suitable" in this case means not a huge complicated library that does many other things as well that aren't needed by FreeOrion.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: OISInput.cfg: input text fields don't work

#15 Post by Dilvish »

Reading over the debian bug report log I noticed it looked like only one of the people with this problem said that mousegrab=true fixed it for them.

I was also reminded of the keyboard problem that initially caused me to experiment with these settings about a year ago -- I would sometimes lose the ability to enter text in FO, like they describe. (It's been a very long time since I've run into it so I had forgotten about it.) During those experiments I figured out that my problem (which others have also encountered since then, there is at least one thread on the boards here) was related to some kind of weird ALT-lock type behavior -- if I alt-tabbed out of FO, and then mouseclicked back into it, I would be unable to type in FO (though mouseclicks would behave normally) until I had pressed the same ALT key a single time more, as if it was turning off an ALT-lock the same way you'd turn off a Caps-lock. Even though this had sunk down in my memory, that's probably a lot of the reason why I had a strong aversion to alt-tabbing out of FO :lol:

This is still easily repeatable for me today, I can open up options, go to the directories page, confirm I can type, alt-tab out, click back in, and then I cannot type (or rather, it doesn't accept my input, I think it is reading it all as 'alt-a', 'alt-b', etc) until I hit the ALT key again (has to be the same one I used to alt-tab), and then everything is fine. The alt-lock does not get initiated just by hitting the alt-key a first time, it seems to only start by alt-tab. Apo, please check if this might be their problem, if pressing ALT again allows them to type.

In the past it was just myself and one or two other users who reported running into this & the 'workaround' of pressing ALT again (or avoiding alt-tabbing out) was an easy enough solution, but I realize it can be quite vexing when first encountered, and the broader group of deb users would have a more difficult time getting this info. If any of the deb users confirms this was their problem (and perhaps even if not), I'll poke around a little with the OIS code and see if I can fix the underlying problem.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Post Reply