Jump to content

[trunk@23678] Atlas and Actor Editor ignores input from the keyboard on OSX


wik
 Share

Recommended Posts

NOTE: I have the following patches applied:

https://code.wildfiregames.com/D2752 - to run the editor on OSX

https://code.wildfiregames.com/D2716 - to build libraries on OSX

The problem

Impossible to modify text in the input fields in the editor or navigate map using keyboard (WASD), however, all input remains on the terminal even though it looks like text field in in focus, see screenshot.

397039681_Screenshot2020-05-26at13_40_12.thumb.png.8c710ad6dfa1cbcbce04e3d07bf2ae0f.png

 

Initial research shows that this behavior caused by OSXIsGUIApplication in AtlasDLLApp

class AtlasDLLApp : public wxApp
{
public:

#ifdef __WXOSX__
	virtual bool OSXIsGUIApplication()
	{
		return false;
	}
#endif

Changing it to "return true" fixes issue, i.e. I can edit text and use keyboard to navigate the map.

1406386811_Screenshot2020-05-26at14_06_32.thumb.png.0ddc4851df2d3cfa6a1a70e9aa72846a.png

I also tested OSXIsGUIApplication behavior with libraries/osx/wxwidgets/wxWidgets-3.0.3.1/samples/widgets, if I add OSXIsGUIApplication returning false it no longer possible to change any texts:

1807044532_Screenshot2020-05-26at14_11_48.thumb.png.145bafccedfcfb512b87bf2f02f44429.png

Link to comment
Share on other sites

Also notice that once OSXIsGUIApplication disabled text input works as normal, unlike in "Alpha 23 Ken Wood" where text input is doubled for every key (screenshot from Alpha 23 on OSX Catalina below)

1233832081_Screenshot2020-05-26at14_24_35.thumb.png.ab5dd76f4445a56c371b1a6f41b46a9e.png

 

Link to comment
Share on other sites

I think I "cmd-tab cmd tab" to get the focus back into Atlas.
It's not impossible that we have some outdated settings in WXWidgets, the "return false" here is indeed rather suspect. If that also fixes the double key input it's pretty good.

Can you delete text? In A23 it's also messed up.

Can you input text if you "start'" the simulation?

Edit -> That being said, there might be something else to do, given the fact that we are supposed to use SDL2 for events, so I don't really know.

Link to comment
Share on other sites

5 hours ago, wraitii said:

Can you delete text? In A23 it's also messed up

@wraitii, yes, can delete text too, yay :)

Also, Alt + Enter works, and even "full screen" green button works more as expected.

6 hours ago, wraitii said:

Can you input text if you "start'" the simulation?

Yes, I can change text in the fields on the left side, also QE, WASD and other shortcuts works inside game simulation

However I can't enter / change text in any text fields which appears as a part of game simulation, for example, user name in game options or message in the chat window.

Link to comment
Share on other sites

8 hours ago, wik said:

Yes, I can change text in the fields on the left side, also QE, WASD and other shortcuts works inside game simulation

However I can't enter / change text in any text fields which appears as a part of game simulation, for example, user name in game options or message in the chat window.

Aye, I expected that. Investigating:  there is actually a rather old, still open ticket about this "return false"change: https://trac.wildfiregames.com/ticket/2427 . It seems to have been a hack if I'm being honest. I'm not too sure what's happening exactly, but somehow wxWidgets end up with double-events.

On that specific, I feel like we should return true here. Perhaps SDL2 fixed something. It's definitely related to windows, anyways.

On to "how to fix the text" -> Based on the WxWidgets doc, we will get keydown/keyUp events and also, for text, special "Char" events that contain "translated" test, i.e. shift+a returns "A" instead of "a". When a key is pressed, it ought to send both a KeyDown and a KeyChar event. What we do is skip the keydown event for chars > 256 (i.e. non-ascii) and use KeyChar instead.
The pushing of event is done in ScenarioEditor.cpp, and the handling of messages here.

Based on a cursory reading, this should all work, so what goes wrong? Well, the comment here seems accurate. CInput, the class responsible for input fields in the 0 A.D. GUI, also processes these "translated" events _> In fact historic_bruno did that change. But as you can see in the atlas Message handler, we do a "keydown/keyup" thing, which won't work -> the game expects a TextEditing message. Based on the SDL2 doc, it seems TEXTINPUT is when the text is "committed", i.e. should be stored, while TEXTEDITING is while text is "going on".

This doesn't make much sense in English, but think Mandarin where multiple characters can merge into one glyph (actually, there's an SDL wiki page for that)

It seems WxWidgets doesn't really expose this low-level stuff, so all we get is the "end" character. So I think you should be able to simulate a SDL_TextInputEvent instead of an SDL_TextEditingEvent.

Link to comment
Share on other sites

  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...