OISInput.cfg: input text fields don't work

[Dilvish]

I have a copy of FOv0.4.3+ [SVN 7301] built and running on Ubuntu 14.4...

I very highly recommend you update to the current SVN version; it's more stable (though it is still subject to this alt-tab issue) and is an improvement in many other ways. That would also be practically a necessity for you to make any contributions.

** edit ** I just realized I had misread what version you were using, just a few minutes earlier saw someone say they were running FOv0.4.3+ [SVN 6281], and I misread yours as the same thing (in referring to the test releases we normally drop the "FOv0.4.3+"). I won't claim the current test versions are noticeably more stable than [7301]

[mrSpaceman]

I've been looking at the code for an hour or two and I've found out a few things about FO. It's also true that I haven't found a solution to the problem yet, though I am new here. I am about to hit it on the head for the evening, so I thought I'd collect my thoughts here for the next time. Also, someone might have some useful comments to make.

My current musings:

The problem is with an Alt-TAB keying. The ALT is depressed, then the window loses focus with the depression of a TAB. It could be that the ALT is not checked for release. If this is the case then a potential solution would be to clear the inputs when the main window loses focus.

I've found a function in ./GG/GG/Wnd.cpp called Wnd::LosingFocus() which has no code within it. So far I've not confirmed that this will be useful. What I would like to know is whether this would be called if the main window loses focus.

Where is the main game window created? Is it a GG window? Would it be apt to have a piece of code to clean up the keyboard input in this function?

The other thing is to find the appropriate method for "cleaning" the input.

Thoughts?

I'll give this more effort later.

[Geoff the Medio]

It could be that the ALT is not checked for release.

More so, the keyup event for the ALT is not generated because the release happens while the FreeOrion window isn't the currently selected window in the OS.

If this is the case then a potential solution would be to clear the inputs when the main window loses focus.

I don't know what you mean by "clear the inputs". But generating / injecting keyup events, similar to what's done for the mouse buttons in HumanClientApp::HandleFocusChange() might help.

What I would like to know is whether [Wnd::LosingFocus()] would be called if the main window loses focus.

No. Or at least one specifically enough so.

Where is the main game window created?

mainSetupAndRunOgre() in chmain.cpp (and then in Ogre code).

Would it be apt to have a piece of code to clean up the keyboard input in this function?

I don't understand the question or its relevance to the issue of this thread.

[mrSpaceman]

I've updated! I'll try and remember to update more regularly: this is the first time I've used SVN to do collaboration with people other than myself

Also, I've started to find other things: the UI I need to turn off my computer, or I'll get sucked in to a very late night... As I say, more later!

I'll try and answer Geoff's questions later, too. [Just noticed them.] I think we're talking about the same thing, in different terms (I'm still getting up to speed with the way you're working here; excuse me while this happens.)

[mrSpaceman]

It could be that the ALT is not checked for release.

More so, the keyup event for the ALT is not generated because the release happens while the FreeOrion window isn't the currently selected window in the OS.

Yep, that sort of thing. I'm going to try that when I can sit and have a go.

If this is the case then a potential solution would be to clear the inputs when the main window loses focus.

I don't know what you mean by "clear the inputs". But generating / injecting keyup events, similar to what's done for the mouse buttons in HumanClientApp::HandleFocusChange() might help.

I don't know what I mean yet, "clean the inputs" was a non-technical, hand-waving phrase to mean do-something-that-means-that-the-UI-doesn't-think-there-are-keys-pressed-when-regaining-focus. Adding extra keyup events is a good idea to try out.

What I would like to know is whether [Wnd::LosingFocus()] would be called if the main window loses focus.

No. Or at least one specifically enough so.

I'm not sure what your comment means (language problem). I'm going to check which function if any does get called when the main window loses focus. I can imagine it's not this specific function, but a over-ridden function belonging to the main UI window. Or perhaps it's an Ogre (rather than a GG) function which handles this? I will try and work out the answer to this question in further code-digging later.

Where is the main game window created?

mainSetupAndRunOgre() in chmain.cpp (and then in Ogre code).

Yes! Thanks! I was actually just finding this with my code-digging last night.

Would it be apt to have a piece of code to clean up the keyboard input in this function?

I don't understand the question or its relevance to the issue of this thread.

I don't understand why you don't understand this I'm still talking about the LosingFocus function and the "cleaning inputs" to solve the issue. The issue under discussion is the problem when Alt-TABbing. It might not be in the thread title, though this is the place where the discussion was being conducted, and it's the place that is linked to from the SF bug ticket on the text-entry/Alt-TAB issue. Should we move the specific discussion of this problem and its solution to another thread? I suppose it's at your discretion to do.

[Geoff the Medio]

Would it be apt to have a piece of code to clean up the keyboard input in this function?

I don't understand the question or its relevance to the issue of this thread.

I don't understand why you don't understand this I'm still talking about the LosingFocus function and the "cleaning inputs" to solve the issue.

The quote was immediately after asking "Where is the main game window created?"

Something like the attached patch might help by injecting keyup events on game window focus changes. Can't test for myself if it makes any difference.

[mrSpaceman]

Ah, I see the confusion. Mea culpa.

I'll take a look at this patch and test that it works.

[mrSpaceman]

In summary, it seems that Geoff's patch doesn't fix the bug.

Firsty, I presumed that:

Code: Select all

OIS::KeyEvent key_event(mouse, key_code, ' ');

...was meant to be:

Code: Select all

OIS::KeyEvent key_event(keyboard, key_code, ' ');

...so I changed that. However, the patch doesn't have the desired effect with either version of this line of code.

Perhaps it's the mModifiers of OISKeyboard which needs to be set to be clear of any modifiers. There a few thing I can do to check this, for example adding debugging output to the HumanClientApp::HandleFocusChange. I haven't done this yet, tho' it's the next thing I'll try to do.

I am happy to continue plugging away at this problem. I am learning a lot about the code in the process.

I does seem that there are keyboard issues in Linux for OIS, judging by the forum thread here: http://www.wreckedgames.com/forum/index ... 642.0.html This issue might be a little old and might have been partially fixed - or the discussion on this other forum thread incomplete (not getting all the symptoms/problems). I wonder if it would be prudent to fix them further up the code chain - ie., instead of fixing it in the FreeOrion client, fixing the underlying OIS classes? I will put priority in getting FreeOrion functioning correctly.

[mrSpaceman]

I used the following debugging in the HumanClientApp::HandleFocusChange method:

Code: Select all

   // similarly inject key up events for all keys
    OIS::Keyboard* keyboard = ois ? ois->GetKeyboard() : 0;
    if (keyboard) {
        //report the status of the keyboard object
        std::cout << "Alt state prior to key clearing: " << keyboard->isModifierDown(OIS::Keyboard::Alt) << std::endl;
        std::cout << "Shift state prior to key clearing: " << keyboard->isModifierDown(OIS::Keyboard::Shift) << std::endl;
        std::cout << "Ctrl state prior to key clearing: " << keyboard->isModifierDown(OIS::Keyboard::Ctrl) << std::endl;
        OIS::KeyListener* kl = ois;
        for (OIS::KeyCode key_code = OIS::KC_ESCAPE; key_code <= OIS::KC_MEDIASELECT;
             key_code = OIS::KeyCode(key_code + 1))
        {
            OIS::KeyEvent key_event(keyboard, key_code, ' ');
            kl->keyReleased(key_event);
        }
        //again report the status of the keyboard object
        std::cout << "Alt state after key clearing: " << keyboard->isModifierDown(OIS::Keyboard::Alt) << std::endl;
        std::cout << "Shift state after key clearing: " << keyboard->isModifierDown(OIS::Keyboard::Shift) << std::endl;
        std::cout << "Ctrl state after key clearing: " << keyboard->isModifierDown(OIS::Keyboard::Ctrl) << std::endl;
    } 

When running the console shows:

Code: Select all

 Alt state prior to key clearing: 1
Shift state prior to key clearing: 0
Ctrl state prior to key clearing: 0
Alt state after key clearing: 1
Shift state after key clearing: 0
Ctrl state after key clearing: 0

...so calling keyReleased to the object doesn't do the job. The next thing to try is to clear the mModifiers variable in the OISKeyboard object (OISLinuxKeyboard?) when the window loses focus. I'm not sure which method would be able to do this yet.

[Edited to reduce the space between code blocks and add another sentence of explanation.]

[Geoff the Medio]

Might be able to do something like

Code: Select all

    OIS::Keyboard* keyboard = 0;
    if (ois)
        keyboard = ois->GetKeyboard();
    if (keyboard) {
        OIS::KeyListener* kl = ois;
        for (OIS::KeyCode key_code = OIS::KC_ESCAPE; key_code <= OIS::KC_MEDIASELECT;
             key_code = OIS::KeyCode(key_code + 1))
        {
            OIS::KeyEvent key_event(keyboard, key_code, '\0');
            kl->keyReleased(key_event);
        }
        keyboard->capture();
    }

Seems to help for me with the mouse equivalent problem. Possibly even without any keyReleased / mouseReleased event injection.

[mrSpaceman]

I've been looking at how the Win32KeyBoard [sic] & LinuxKeyboard classes handle the mModifiers variable. I've just noticed your post now, Geoff.

What I've found:

The Win32KeyBoard::capture() method seems to clear the mModifiers variable when it is called. The task is delegated to one of two methods: in consulatation with the key buffer (Win32KeyBoard::_readBuffered method) or checking whether the key is actually pressed (Win32KeyBoard::_read method).

In the LinuxKeyboard class the capture method is all written in the same block of code. It checks for X events, and while there are X events it checks to see what type of event for the sake of pressed and released keys. Otherwise it checks for grabbing focus and does some stuff to grab the keyboard.

Any hints at a solution?:

It looks like your last post might contain the simple solution of adding a line into HumanClientApp::HandleFocusChange():

Code: Select all

keyboard->capture();

If the OIS code is written correctly then regaining focus should do the right thing and clear the modifiers. It's worth a shot by itself. Hovwer, if not, then the LinuxKeyboard::capture() method needs another line to say:

Code: Select all

mModifiers = 0; 

I don't see why you would want to keep Alt, Ctrl and Shift through a focus change. If you were really bothered then when gaining focus you could test if these keys were pressed and set the mModifiers variable accordingly at that point.

[Geoff the Medio]

...LinuxKeyboard::capture() method needs another line to say:

Code: Select all

mModifiers = 0; 

...

Depending on local copy modifications of the OIS code is potentially problematic. It would be best to avoid making such changes if a FreeOrion or GG code change can accomplish the same

I don't see why you would want to keep Alt, Ctrl and Shift through a focus change.

Probably there is no need to keep such key states, and if the keys have actually changed physical state, the keystate passed into FreeOrion / GG code should reflect that change.

[Geoff the Medio]

It looks like your last post might contain the simple solution of adding a line into HumanClientApp::HandleFocusChange():

Code: Select all

keyboard->capture();

[...] It's worth a shot by itself.

Did you try this?

[mrSpaceman]

I did try adding the

Code: Select all

keyboard->capture();

line. It didn't work. I'm going to give it a little more time (later), then admit defeat. As you've said in another thread (viewtopic.php?f=24&t=8988&p=71053) OIS is broken and it's not currently being developed. Perhaps SDL is a better shout.

[Geoff the Medio]

I did try adding the

Code: Select all

keyboard->capture();

line. It didn't work.

With or without the keyrelease event injections?

Regardless, did it cause any problems? It seemed to help things a bit on Windows, so I might commit such an addition anyway if it didn't make things any worse for you...