OSX Carbon or Cocoa? For capslock info...

Geoff the Medio · **Posted:** Sat Jan 28, 2012 11:08 pm

Is the OSX build using Carbon or Cocoa? I don't know exactly what those are, but I gather one or the other tends to be used for building OSX apps.

I ask because I'm looking into making the numeric keypad work properly and respect numlock and capslock settings. I gather most Macs don't actually have numlock keys anymore, but do have capslock. I was able to easily fund a Win32 API function to get the current state of these toggles (and scroll lock) but searching about OSX has been less successful.

I have found one possibility for OSX here which suggests using GetCurrentKeyModifiers() but which appears to require Carbon. There's also this which appears to have alternatives for both... So, I'm wondering if something along these lines would be usable in OISInput.cpp in the GetModKeys function, where I currently have calls to Win32's GetKeyState working as intended.

Vezzra · **Posted:** Sun Jan 29, 2012 12:56 am

Geoff the Medio wrote:

Is the OSX build using Carbon or Cocoa?

What I can see from the dependencies, the human client is linked against both the carbon and the cocoa framework. I hoped to find only one or the other... but both being required is confusing. Unfortunately, I'm out of my depth how to find out which framework is actually the relevant one...

(EDIT: Didn't see that cocoa was used too at first, post edited accordingly)

Quote:

I don't know exactly what those are, but I gather one or the other tends to be used for building OSX apps.

Yes, as far as I understand, these are the GUI frameworks. Carbon is the older one, still kept for backward compatibility, while Cocoa is the current one.

Geoff the Medio · **Posted:** Sun Jan 29, 2012 1:16 am

Can you try removing the Carbon linkage and see if it builds? Maybe it's not actually needed...

Vezzra · **Posted:** Sun Jan 29, 2012 9:17 am

Removing the carbon linkage results in the following build errors:

Code:

Undefined symbols:
  "_GetApplicationEventTarget", referenced from:
      OIS::MacInputManager::_parseConfigSettings(std::multimap<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >&)in libOIS.a(MacInputManager.o)
  "_GetEventKind", referenced from:
      OIS::MacMouse::_mouseCallback(OpaqueEventRef*)      in libOIS.a(MacMouse.o)
  "_GetEventTime", referenced from:
      OIS::MacKeyboard::_modChangeCallback(OpaqueEventRef*)       in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::_keyUpCallback(OpaqueEventRef*)       in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::_keyDownCallback(OpaqueEventRef*)       in libOIS.a(MacKeyboard.o)
  "_RemoveEventHandler", referenced from:
      OIS::MacKeyboard::_initialize()      in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::_initialize()      in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::_initialize()      in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::~MacKeyboard()in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::~MacKeyboard()in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::~MacKeyboard()in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::~MacKeyboard()in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::~MacKeyboard()in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::~MacKeyboard()in libOIS.a(MacKeyboard.o)
      OIS::MacMouse::~MacMouse()in libOIS.a(MacMouse.o)
      OIS::MacMouse::~MacMouse()in libOIS.a(MacMouse.o)
      OIS::MacMouse::~MacMouse()in libOIS.a(MacMouse.o)
      OIS::MacMouse::~MacMouse()in libOIS.a(MacMouse.o)
      OIS::MacMouse::_initialize()     in libOIS.a(MacMouse.o)
      OIS::MacMouse::_initialize()     in libOIS.a(MacMouse.o)
  "_GetWindowBounds", referenced from:
      OIS::MacMouse::_initialize()     in libOIS.a(MacMouse.o)
      OIS::MacMouse::_mouseCallback(OpaqueEventRef*)      in libOIS.a(MacMouse.o)
  "_ActiveNonFloatingWindow", referenced from:
      OIS::MacInputManager::_parseConfigSettings(std::multimap<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >&)in libOIS.a(MacInputManager.o)
  "_CallNextEventHandler", referenced from:
      OIS::MacMouse::WindowFocusChanged(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) in libOIS.a(MacMouse.o)
      MouseWrapper(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) in libOIS.a(MacHelpers.o)
      KeyDownWrapper(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) in libOIS.a(MacHelpers.o)
      KeyUpWrapper(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) in libOIS.a(MacHelpers.o)
      KeyModWrapper(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) in libOIS.a(MacHelpers.o)
  "_NewEventHandlerUPP", referenced from:
      OIS::MacKeyboard::MacKeyboard(OIS::InputManager*, bool, bool)in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::MacKeyboard(OIS::InputManager*, bool, bool)in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::MacKeyboard(OIS::InputManager*, bool, bool)in libOIS.a(MacKeyboard.o)
      OIS::MacMouse::MacMouse(OIS::InputManager*, bool)in libOIS.a(MacMouse.o)
      OIS::MacMouse::MacMouse(OIS::InputManager*, bool)in libOIS.a(MacMouse.o)
  "_DisposeEventHandlerUPP", referenced from:
      OIS::MacKeyboard::~MacKeyboard()in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::~MacKeyboard()in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::~MacKeyboard()in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::~MacKeyboard()in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::~MacKeyboard()in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::~MacKeyboard()in libOIS.a(MacKeyboard.o)
      OIS::MacMouse::~MacMouse()in libOIS.a(MacMouse.o)
      OIS::MacMouse::~MacMouse()in libOIS.a(MacMouse.o)
      OIS::MacMouse::~MacMouse()in libOIS.a(MacMouse.o)
      OIS::MacMouse::~MacMouse()in libOIS.a(MacMouse.o)
  "_GetEventParameter", referenced from:
      OIS::MacKeyboard::_modChangeCallback(OpaqueEventRef*)       in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::_keyUpCallback(OpaqueEventRef*)       in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::_keyDownCallback(OpaqueEventRef*)       in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::_keyDownCallback(OpaqueEventRef*)       in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::_keyDownCallback(OpaqueEventRef*)       in libOIS.a(MacKeyboard.o)
      OIS::MacMouse::_mouseCallback(OpaqueEventRef*)      in libOIS.a(MacMouse.o)
      OIS::MacMouse::_mouseCallback(OpaqueEventRef*)      in libOIS.a(MacMouse.o)
      OIS::MacMouse::_mouseCallback(OpaqueEventRef*)      in libOIS.a(MacMouse.o)
      OIS::MacMouse::_mouseCallback(OpaqueEventRef*)      in libOIS.a(MacMouse.o)
      OIS::MacMouse::_mouseCallback(OpaqueEventRef*)      in libOIS.a(MacMouse.o)
      OIS::MacMouse::_mouseCallback(OpaqueEventRef*)      in libOIS.a(MacMouse.o)
      OIS::MacMouse::_mouseCallback(OpaqueEventRef*)      in libOIS.a(MacMouse.o)
  "_InstallEventHandler", referenced from:
      OIS::MacKeyboard::_initialize()      in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::_initialize()      in libOIS.a(MacKeyboard.o)
      OIS::MacKeyboard::_initialize()      in libOIS.a(MacKeyboard.o)
      OIS::MacMouse::_initialize()     in libOIS.a(MacMouse.o)
      OIS::MacMouse::_initialize()     in libOIS.a(MacMouse.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status

I'll try removing the cocoa linkage next and post the results.

Vezzra · **Posted:** Sun Jan 29, 2012 10:03 am

Removing only the cocoa linkage (and keeping carbon) results in a successful build. I was also able to launch a quick test game. So apparently FO on Mac is a carbon app.

My guess is that someone planned to migrate to the cocoa framework and therefore added in the dependency, but didn't actually get around to implement the necessary modifications, so the cocoa dependency remained, although apparently it isn't needed.

Should the cocoa dependendy be removed for now or should we keep it?

Geoff the Medio · **Posted:** Sun Jan 29, 2012 10:07 am

Vezzra wrote:

Should the cocoa dependendy be removed for now or should we keep it?

This seems likely to cause problems for people other than you, so let's save that for after v0.4 is out... Assuming the Python issues ever get resolved.

In the meantime, if you feel like experimenting, the attached patch uses some Win32-specific functions to get the state of numlock and capslock. In previous posts, I linked to some OSX code using Carbon to do the same. I can't experiment myself, but if you could find some working code to do that on OSX, that would be helpful. All that should need updating is the OISInput.cpp code change; add an OSX-specific section after the #ifdef WIN32 section.

Vezzra · **Posted:** Sun Jan 29, 2012 11:43 am

Geoff the Medio wrote:

...In the meantime, if you feel like experimenting, the attached patch uses some Win32-specific functions to get the state of numlock and capslock. In previous posts, I linked to some OSX code using Carbon to do the same. I can't experiment myself, but if you could find some working code to do that on OSX, that would be helpful. All that should need updating is the OISInput.cpp code change; add an OSX-specific section after the #ifdef WIN32 section.

I felt like experimenting

Just to make sure I understand correctly: The problem is that numlock/capslock don't work in FO (at least on win), so that's why some platform specific code is required to get these working like they should, right?

If I'm correct with this assumption, then I feel a bit stupid now for not having done this earlier: I tried if capslock works in FO on my system - and it does just fine. No problems at all. I tried it with and without your patch applied - same result. Macs (at least the more current ones) don't have numlock, so that's not an issue. Have there been complaints from people running FO on OSX that capslock isn't working for them? If not, I'd suggest to go with the rule "don't fix what isn't broken" and don't add in some OSX specific code.

Unless you think we should do that for some reason? Then of course I can give it a try (although given my still very rudimentary OSX specific programming skills, that might take a bit

).

Quote:

Assuming the Python issues ever get resolved.

I hope to hear from eleazar soon on this one. I hope it's just something specific to his system/setup, otherwise I'll have some serious problems tracking down the root of these issues as I can't reproduce them on my system

EDIT: Forgot to mention: After applying your patch, I had a "#elif" without a condition in line 67 in OISInput.cpp, resulting in a build error. Changed that to "#else" to get the build to succeed.

Geoff the Medio · **Posted:** Sun Jan 29, 2012 7:56 pm

Vezzra wrote:

Just to make sure I understand correctly: The problem is that numlock/capslock don't work in FO (at least on win), so that's why some platform specific code is required to get these working like they should, right?

Right. The patch also modified the Edit control to respond to numeric keypad direction keys and delete being pressed, which previously were nonfunctional (regardless of whether numlock was toggled). Do (presumably desktop) Macs have similar keys these days?

Quote:

I tried if capslock works in FO on my system - and it does just fine. No problems at all. I tried it with and without your patch applied - same result.

Weird... Maybe the existing code works fine on Unix-like OSes? Everything I've read about OIS suggests that it shouldn't, though...

Quote:

Macs (at least the more current ones) don't have numlock, so that's not an issue.

So I've read, though I think a few people have tried hooking up a USB full keyboard with numlock to Macs and may or may not have had issues getting the numlock state.

Quote:

Have there been complaints from people running FO on OSX that capslock isn't working for them?

Not specifically about OSX that I'm aware of. Though even if there was a problem with it, it's quote possible that nobody would have noticed since, really, who's going to be using capslock in FO anyway?

Quote:

If not, I'd suggest to go with the rule "don't fix what isn't broken" and don't add in some OSX specific code.

Seems reasonable.

Vezzra · **Posted:** Thu Feb 02, 2012 2:12 pm

Geoff the Medio wrote:

...The patch also modified the Edit control to respond to numeric keypad direction keys and delete being pressed, which previously were nonfunctional (regardless of whether numlock was toggled). Do (presumably desktop) Macs have similar keys these days?

Depends on the keyboard you have. If you have the wireless keybord, you don't have a numeric keypad. The wireless keybord layout is more or less the same as the macbook keybords. If you have the USB keybord, then you have some extra keys and a numeric keypad. Still, you don't have a numlock on these, as the numeric keypad is just that - a numeric keypad, no double functionality as direction keys etc.

I had the opportunity to run a quick test on an iMac with a FO build with your patch applied, and curiously enough (altough not surprising) this turned the numeric keypad on the Mac USB keyboard into direction keys, with some of the keys behaving a bit strangely. The "+" and "-" keys for example triggered the zoom-in/zoom-out of the starmap instead of printing "+"/"-" even when the input focus was on an edit control.

One key that didn't work was an extra delete key on the numeric keypad. But that's not really an issue as there is another delete key on the USB keyboard that works, and the other keyboards (MacBooks and wireless keyboards) come without either. The rest of the keys seem to work as intended (HOME, END, etc).

Quote:

...Weird... Maybe the existing code works fine on Unix-like OSes? Everything I've read about OIS suggests that it shouldn't, though...

Well, all *I* can tell you it works - no idea why, but it works...

Quote:

...So I've read, though I think a few people have tried hooking up a USB full keyboard with numlock to Macs and may or may not have had issues getting the numlock state.

USB full keyboards with numlock for Macs? Does something like this exist? I haven't seen such a thing, I have to admit. At my office we still have a keyboard from an old G4, and even that one hasn't a numlock I think - I'm going to check that to be sure...

Geoff the Medio · **Posted:** Thu Feb 02, 2012 2:35 pm

Vezzra wrote:

I had the opportunity to run a quick test on an iMac with a FO build with your patch applied, and curiously enough (altough not surprising) this turned the numeric keypad on the Mac USB keyboard into direction keys...

So essentially, on Mac keyboards, the expected functionality for the keypad is as though numlock is always on? What do those keys do without the patch applied?

Quote:

The "+" and "-" keys for example triggered the zoom-in/zoom-out of the starmap instead of printing "+"/"-" even when the input focus was on an edit control.

Does that depend on the patch being applied?

Quote:

One key that didn't work was an extra delete key on the numeric keypad.

Can you investigate what GGK_ enum is passed when that key is pressed? Apparently it's not GGK_DELETE or GGK_KP_PERIOD.

Quote:

The rest of the keys seem to work as intended (HOME, END, etc).

You mean pressing keypad 7 or 1 acted like home or end? Or that there are also actual HOME and END keys that function correctly?

Quote:

USB full keyboards with numlock for Macs? Does something like this exist?

Can't you just plug in a PC USB keyboard with numlock?

eleazar · **Posted:** Thu Feb 02, 2012 3:02 pm

Geoff the Medio wrote:

Can't you just plug in a PC USB keyboard with numlock?

I think you can.

Vezzra · **Posted:** Thu Feb 02, 2012 3:09 pm

Geoff the Medio wrote:

So essentially, on Mac keyboards, the expected functionality for the keypad is as though numlock is always on?

Yes.

Quote:

What do those keys do without the patch applied?

Quote:

The "+" and "-" keys for example triggered the zoom-in/zoom-out of the starmap instead of printing "+"/"-" even when the input focus was on an edit control.

Does that depend on the patch being applied?

I've to admit I haven't tried that. My access to this iMac is very limited, only now and then I'm able to sneak in a quick test run of FO. I'll try that ASAP.

Quote:

One key that didn't work was an extra delete key on the numeric keypad.

Can you investigate what GGK_ enum is passed when that key is pressed? Apparently it's not GGK_DELETE or GGK_KP_PERIOD.

This one is going to be tricky, as there is no development environment installed on this iMac, so no debugging possible. I'd have to hardcode some log statements and try that custom build on this machine... but the question is: Do you think this is really worth the effort? This key is kind of weird anyway, I had to try it in other apps first to find out what it is supposed to do (because the symbol on it wasn't very conclusive), and also redundant (as just one inch beside it is a key much more clearly labeled as delete key). I'll do it if you think it's worth it, but personally I'd just leave it (until the FO dev team get's bored because there's nothing else left to do

)

Quote:

You mean pressing keypad 7 or 1 acted like home or end? Or that there are also actual HOME and END keys that function correctly?

Both. 7 and 1 act like HOME and END, and there are also "dedicated" HOME and END keys.

Quote:

Can't you just plug in a PC USB keyboard with numlock?

I've never tried something like that - but the results might be interesting. Although I can't think why anyone might want to do something like that, I'm quite sure there will be strange issues (like when I tried the other way round and plugged a Mac USB keyboard into a PC) because there are some slight differences in keyboard layout. So unless you want exotic cases like that fully covered, I wouldn't bother with it. Someone who's plugging a PC keyboard into a Mac shouldn't be too surprised if he encounters a few issues

On a sidenote: Do you ever go to sleep??? You're in Vancouver, right? Judging from the times of your posts and your timezone, you stay up very late on a regular basis... but today I'm wondering if you're still up or up again very early...

Geoff the Medio · **Posted:** Sat Feb 04, 2012 10:45 am

Vezzra wrote:

Do you think this is really worth the effort?

I'd like things to work, and tzlaine will probably prefer a more-correct, or more-as-expected, functionality for GG. Whether it's worth *your* effort is up to you to decide...

Quote:

You mean pressing keypad 7 or 1 acted like home or end? Or that there are also actual HOME and END keys that function correctly?

Both. 7 and 1 act like HOME and END, and there are also "dedicated" HOME and END keys.

Makes sense; it's apparently converting the 7 and 1 keypad presses into HOME and END keypresses in Edit, since it thinks numlock is off.

Quote:

On a sidenote: Do you ever go to sleep??? You're in Vancouver, right? Judging from the times of your posts and your timezone, you stay up very late on a regular basis... but today I'm wondering if you're still up or up again very early...

I was a bit sick this week, so ended up sleeping even more irregular hours than usual.

Vezzra · **Posted:** Wed Feb 08, 2012 2:33 pm

I was able to borrow a full USB keyboard and do some tests on my Mac...

Geoff the Medio wrote:

...it's apparently converting the 7 and 1 keypad presses into HOME and END keypresses in Edit, since it thinks numlock is off.

That's exactly what happens. "numlock_on" evaluates to "false" in Edit::KeyPress, so the GGK_KPx keycodes get translated.

These are the results of my tests:

Numeric keypad keys behaviour without your patch: ENTER, "=", "/", "*", "-", "+" work normally (as they should). All the other keys do nothing.

Numeric keypad keys behaviour with your patch: ENTER, "=", "/", "*", "-", "+" work normally (as they should). "7" acts as HOME, "1" as END, "4" as LEFT, "6" as RIGHT, keypad period as DELETE. "8", "2", "9" and "3" do nothing, but I'm sure that's because we're inside a single line edit control. "5" and "0" do nothing.

The strange key above "7" was numlock on older Macs, as I found out in the meantime. Apparently this function was dropped some time ago (so modern Mac keyboards don't have numlock anymore), now this key's supposed function is to act as the "Clear" key in the Calculator app (I googled this one). Further testing revealed that it apparently doesn't do anything in other applications. Why it acted like DELETE when I first tested it (I think in LibreOffice) I don't know, I couldn't reproduce this behaviour.

When you press this key in FO, nothing happens. However, with the other numeric keypad keys at least Edit::KeyPress gets called, with this "Clear" key not even that happens. It's like no key is been pressed at all. As it seems to be ignored by other apps except Calculator, this shouldn't be a problem.

So, the expected behaviour on Mac would be that "Clear" does nothing, while the rest of the numeric keypad keys act like numlock is on. As on Mac the numeric keys on the numeric keypad apparently aren't recognized, I'd suggest to implement an OSX specific code section in Edit::KeyPress translating the GGK_KPx key codes in question. The period key is a bit of a challenge, because depending on the keyboard used this is either a period or a comma. As the keyboard layout in FO is fixed on US QWERTY at the moment, we can just translate it to ".", but once that changes we have to keep in mind that this has to be adapted correctly in Edit::KeyPress too. If you're ok with that suggestion, I can do it if you want.

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.

Vezzra · **Posted:** Wed Feb 08, 2012 2:43 pm

Oh, before I forget, during my tests I noticed another thing: 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.

FreeOrion

OSX Carbon or Cocoa? For capslock info...

Who is online