OSX Carbon or Cocoa? For capslock info...

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderator: Committer

Message
Author
User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: OSX Carbon or Cocoa? For capslock info...

#16 Post by Vezzra »

And finally yet another glitch I noticed: When typing in the chat edit control in the message window, "+" and "-" on the numeric keypad don't get you the chars typed, but instead trigger the zoom-in and zoom-out functions in the galaxy window. This doesn't happen in the other edit controls I used for my tests. My guess is that these keys get caught by a galaxy window event handler, so the chat edit control event handler does not get to see it. The other edit controls I used for testing were part of modal dialogs, that would explain why no other event handler could interfere.

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

Re: OSX Carbon or Cocoa? For capslock info...

#17 Post by Geoff the Medio »

Vezzra wrote:The "standard" "+" and "=" keys (that is, not those on the numeric keypad) act strangly in edit controls. If I press them, the first time nothing happens, a second keystroke gets me one "+" or "=" character. After that subsequent "+" or "=" get me, as expected, one char per keystroke. If I then press delete, not only one, but a whole bunch of the "+" or "=" I typed before gets deleted. "Whole bunch" = 3 to all chars I typed.
Does this happen with and without the numlock patch?

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: OSX Carbon or Cocoa? For capslock info...

#18 Post by Vezzra »

Geoff the Medio wrote:Does this happen with and without the numlock patch?
Yes. This phenomen apparently has nothing to do with your patch.

I investigated the issue further, and discovered another key that triggers a similar behaviour. It's the key left of "1", above the TAB and below the ESC key. On my keybord (german QWERTZ keybord layout) it's the key for the "^" and the "°" (with SHIFT). Pressing this key without SHIFT in an edit control in FO produces no characters (even when pressing it multiple times), but every other key I press afterwards is repeated 9 times - except for the vowel keys (a, e, i, o, u). Pressing one of them after pressing "^" produces just one char. "+" and "=" show exactly the same behavious , the only difference is that these actually do produce characters after a first keystroke that produces nothing.

Pressing this key with SHIFT does nothing at all. No characters, no strange behaviour of other keys afterwards, nothing.

Interestingly enough, these keys have a special function on a german keyboard. The key which has the "+" and "=" characters on US keyboards has the accent chars "´" and "`" on it. Normally, when I press one of these keys and a vowel directly afterwards, I don't get two chars (the accent and the vowel), but one: the vowel with the accent above. Example: "â", "é", etc. Pressing a non vowel key afterwards produces two chars. Example: "^h", "´7" etc.

Now this works in every application that handles my german keyboard according to the settings in my system preferences. In FO there is the problem that apparently the keyboard layout settings in the system preferences are ignored, I get a US keyboard layout in FO (which of course is a bit annoying, Y and Z are swapped and most of the special characters are on different keys, fortunately typing text isn't something you have to do a lot in FO ;)). Obviously the system keyboard settings aren't completely ignored, as the keys that have this special behaviour on german keyboards (to produce accented vowels) seem to interfere with the normal behaviour they have on US keyboards (producing the strange results described above). When I switch the keyboard layout to US in the system preferences, the problem disappears and the keys are working normally.

To me this looks like GG has issues with keyboards other than US, at least on Macs. I'll have a look at the behaviour of these keys on Windows next and report the results.

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

Re: OSX Carbon or Cocoa? For capslock info...

#19 Post by Geoff the Medio »

Vezzra wrote:To me this looks like GG has issues with keyboards other than US...
I think there are some comments in the GG code about assuming a US keyboard layout, or something similar.

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: OSX Carbon or Cocoa? For capslock info...

#20 Post by Vezzra »

Geoff the Medio wrote:I think there are some comments in the GG code about assuming a US keyboard layout, or something similar.
Ok, I see.

A quick test with 0.4 on my old XP laptop revealed no issues on Windows. There the keyboard behaves just like an US keyboard does. So apparently this is a OSX specific issue, I guess that maybe this functionality to produce accented vowels is implemented in different OS/driver levels on Windows and OSX, resulting in some kind of interference on OSX that doesn't happen on Windows.

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: OSX Carbon or Cocoa? For capslock info...

#21 Post by Vezzra »

Hi Geoff,
Vezzra wrote:...While debugging Edit::KeyPress I came across another issue that I've been noticing before. On OSX, when you hide the FO application and bring it back to front (and also when you minimize it to the dock and bring it back), edit controls no longer work correctly. You can delete characters, but can't type new ones. Which is quite annoying of course. The reason is that after hiding/unhiding (minimizing/bringing back up) the Edit::KeyPress parameter mod_keys contains values indicating that one of CTRL, ALT or META (CMD on Mac, WIN on Windows) has been pressed, even if that's not the case. The values seem to vary, one time private member mod_keys.m_flags was set to 64 (when I tried minimizing and bringing back up), another time to 1024 (when I tried hiding/unhiding).

I've no idea why this happens, but at least it's something to start with, if someone wants to look into this issue. I'd do it myself, but I'm a bit out of my depth here.
Looks like I wasn't as much out of my depth as I thought. I've given it a try and found out a bit more: The problem seems to be OIS::Keyboard::isKeyDown (which is called in GetModKeys in OISInput.cpp), this function returns true for OIS::KC_LWIN after hiding/unhiding the FO application regardless if the CMD key has been pressed or not.

So I decided to modify GetKeyMods and added a OSX specific code section for querying the mod keys, calling the carbon framework function GetCurrentKeyModifiers instead of OIS::Keyboard::isKeyDown. A few quick tests indicate that this seems to work, hiding/unhiding and minimizing/restoring the FO app no longer results in not being able to type in edit controls.

I made a patch file for OISInput.cpp and attached it. Attention: As I created this diff against GG SVN 1074, also your previous modifications got included.

As this is a contribution for GiGi, what kind of license statement do you need from me? IIRC GG isn't released under the same license as FO...
Attachments

[The extension patch has been deactivated and can no longer be displayed.]


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

Re: OSX Carbon or Cocoa? For capslock info...

#22 Post by Geoff the Medio »

Vezzra wrote:As this is a contribution for GiGi, what kind of license statement do you need from me? IIRC GG isn't released under the same license as FO...
GiGi is released under the LGPL 2.1 or later (see the note in most of the GG header files), so probably tzlaine would want the same for a patch.

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: OSX Carbon or Cocoa? For capslock info...

#23 Post by Vezzra »

Geoff the Medio wrote:GiGi is released under the LGPL 2.1 or later (see the note in most of the GG header files), so probably tzlaine would want the same for a patch.
Ok, I release this contribution to GiGi under the LGPL 2.1 license.

Post Reply