KeyMapper: a key-binding module, with GUI [Major update 5/2019]

Still isnt working but I managed to make it work.

I had to comment out these lines:

            # item_pad = (0.4, 0.2),
            # item_frameColor = (0.15, 0.42, 0.18, 1),
            # item_clickSound = base.btnClickSound,

and missing import

from DirectOptionMenuAware import DirectOptionMenuAware

Anyways, in the example modifier combinations dont work. And more importantly also it seems it doesnt work with keys that generate unicode characters? Like in my case: ě š č ř …

Could you show me the error(s) that you got with those lines in place, please? They should work, being, I think, standard DirectGUI keyword-parameters.

Also, what version of Panda are you using?

Ah, that’s odd–I thought that I’d removed that!

Aaah, I see–I removed the file from the repository, but didn’t update the example game.

Okay, I’ve updated the game in the repository to instead use the base Panda “DirectOptionMenu” class!

Correct, in general they don’t, I’m afraid. :/

I believe that a fuller description is given in the documentation, under “Known issues”, but it’s related to the way that Panda handles such combinations.

It’s possibly something that’s fixable, but as it deals with Panda’s handling of key-events and as I don’t generally find myself using modifiers with my controls, I haven’t really had much inclination to delve into the matter, I’m afraid.

Ah, that’s a problem! I’m afraid that I don’t have such keys on my keyboard, so I never tested for them…

Are these characters generated by a single key? That is, do you have an “ě” on your keyboard?

And do events using these keys work with standard Panda key-events, as registered via “accept”?

(And thank you for pointing out these issues, by the way! I appreciate it. ^_^)

Known pipe types:
  wglGraphicsPipe
(all display modules loaded.)
Traceback (most recent call last):
  File "c:/Users/01/Desktop/KeyMapper-master/KeyMapperExampleGame.py", line 875, in <module>
    game = KeyMapperTestGame()
  File "c:/Users/01/Desktop/KeyMapper-master/KeyMapperExampleGame.py", line 689, in __init__
    self.keyMapper.setup()
  File "c:/Users/01/Desktop/KeyMapper-master/KeyMapperExampleGame.py", line 111, in setup
    KeyMapper.setup(self)
  File "c:\Users\01\Desktop\KeyMapper-master\KeyMapper.py", line 416, in setup
    self.buildMainGUI()
  File "c:/Users/01/Desktop/KeyMapper-master/KeyMapperExampleGame.py", line 199, in buildMainGUI
    KeyMapper.buildMainGUI(self)
  File "c:\Users\01\Desktop\KeyMapper-master\KeyMapper.py", line 502, in buildMainGUI
    self.buildProfileGUI()
  File "c:/Users/01/Desktop/KeyMapper-master/KeyMapperExampleGame.py", line 172, in buildProfileGUI
    popupMarker_relief = None)
  File "c:\Users\01\Desktop\KeyMapper-master\DirectOptionMenuAware.py", line 36, in __init__
    self.initialiseoptions(DirectOptionMenuAware)
  File "C:\Panda3D-1.10.7-x64\direct\gui\DirectGuiBase.py", line 275, in initialiseoptions
    '" for ' + myClass.__name__)
KeyError: 'Unknown options "item_pad, item_frameColor, item_clickSound" for DirectOptionMenuAware'

Panda3D-1.10.7-x64

And yeah, ě is a single key, panda generates raw-2 event for it. If you want to make your keybindings work on every keyboard then you have to use only raw-key events.

As to the error, ah! That seems to have been a bug related to “DirectOptionMenuAware”. Since I’ve switched the code in the repository to no longer use that class, it should be fine now.

As to the key-events, I’ll give that consideration, thank you; I’ve made a note of it as an issue to look into. (Although, thinking about it, it seems to me like a bug in Panda that normal key-events aren’t being generated.)

@Pignon: I’ve just uploaded an update to the KeyMapper repository. Would you do me the favour please of trying it out and letting me know whether the module now correctly supports the sort of keys that it wasn’t previously handling?

Again had to comment that 3 lines.
It shows that it binded the keys (it didnt before) but in the game they dont work. Also maybe its just the font but the ˇ above ě etc. is upside down and all the other letters are also incorrect. Can you include the font or check if it has the characters.

That’s very strange. Did you get the updated copy of the example-game? It should no longer be using DirectOptionMenuAware, and thus those parameters should work… o_0

Most frustrating! :/

[edit] Do you perhaps have a modified version of DirectOptionMenu, or any of the DirectGUI classes, in your build of Panda…? [/edit]

Ah, that’s a pity!

Okay, I’ll have to look into that further, I think. I’ll likely make a thread to ask after the issue, as I don’t seem to have a keyboard to hand that allows me to experiment with it myself.

But progress, at least!

I’m just using the default font, I believe–that is, it should be using whatever Panda uses when no font is specified, as I haven’t specified one. I’m not sure offhand of what font that is, I’m afraid.

You dont need special keyboard, you can change in your system keyboard to Czech and the 2-0 keys are some of the buttons that are the raw- only events.

And yeah DirectOptionMenu has the same issue.

KeyError: 'Unknown options "item_pad, item_frameColor, item_clickSound" for DirectOptionMenu'

I’ve tried that, I’m afraid: under Ubuntu, at least, Panda resolutely reports standard English key-presses, even when using non-raw events. I’ve tried changing my “input source” (i.e. which key-set I type in, e.g. Hangul) and using an on-screen keyboard. No apparent effect.

Hmm… Very odd. As far as I can tell, it should work.

Here, for example, is a thread in which “item_pad” was mentioned as being present:

Well, when I ctrl+F in DirectOptionMenu.py there are no results for item_pad, item_frameColor and item_clickSound.

On windows when I use multiple keyboards I have to swap them when an application is running because they tend to swap back to default one. Maybe its the same in Ubuntu? :smiley: No idea.

Unfortunately, DirectGUI’s handling of sub-component keywords is a little on the arcane side. There’s code that breaks down such keywords and passes them on to said sub-components, as I recall.

You won’t find mention of “popupMarker_image” (as mentioned in the docs), either, for example.

I’m pretty sure that I’ve tried that, I’m afraid. ^^; But I’ll give it another shot…

[edit] Nope, whether I switch “input sources” before or during a run, I just get English letters. :/

And it works on your PC? Shouldnt those be maybe as extraArgs? In the manual those keywords are not mentioned, where did you find them?
https://docs.panda3d.org/1.10/python/programming/directgui/directoptionmenu

It does indeed!

I don’t think that DirectGUI widgets use extraArgs when being constructed, do they?

I honestly don’t recall–it’s been a while since I wrote this code. However, there are, I think, a few such keywords that can be inferred to exist. For example, I just tried out “popupMarker_hpr”, and it seems to work. (Use the “r” value to rotate the marker.)

Sorry, I didnt get to learning DirectGUI yet. I installed 1.10.8 and still same. Do you have latest version? Then it must be platform specific? Maybe once I get to fiddling with GUI, I might be able to help. Now, I learned that I should write comments for these keywords :smiley:

Not a problem! :slight_smile:

I believe that I do, yes.

Possibly, but I doubt it.

I’m more inclined to suspect that I have a modified version of DirectOptionMenu.py floating about my system somewhere–where that might be I don’t know offhand–that includes these features, and that’s being picked up invisibly.

In any case, if I recall correctly they’re not terribly useful in baseline DirectOptionMenu (as they’re lost when the menu is rebuilt), so I might just remove them and have done with it. The menu will be less pretty, but it’ll reliably work, I daresay!

Thank you for the offer! :slight_smile:

As I said, however, I’m more and more inclined to suspect that the disconnect is coming from a modified version on my end. That’s my best guess right now!

Correction: It looks like I can get non-English characters–but I’m getting some odd inconsistencies in which characters are produced. See the following thread for more on this:
https://discourse.panda3d.org/t/figuring-out-raw-key-support-experimentation/27337/2

@Pignon: Could I trouble you again to try out the recent update of KeyMapper, please? While, as per the above-linked thread, I’m not sure that I’m getting the expected characters in all cases, I hope that I have the events firing correctly, now.

No problemo. You fixed it! But the game is too hard!
edit: BTW what key is the “back” key?
edit2: Im impressed you also support my “flight_stick”, the game is a bit easier on gamepad than keyboard.

Ah, excellent! :smiley:

Whew, that’s a bit of a relief! ^^;

Hah, I have heard that! XD;

Well, you have the source code, you can always adjust it. :stuck_out_tongue_winking_eye:

Aaaah… On a gamepad I think that it’s the “select” button.

Honestly, that’s more Panda’s accomplishment than mine! I just support whatever devices Panda gives me access to. But for my part in that support, thank you. :slight_smile:

Minor update:

I’ve fixed, I believe, an issue in which KeyMapper didn’t correctly identify “wheel” events as being related to a “mouse” device.