I'm fine with the fact that keychar event has the repeat flag, but the fact that keydown no longer has modifiers and unicode broke my GUI API in a way that I really do not know how to fix it. My GUI API is backend based so that's why I used unichar, and then used a switch case for things like meta, alt, shift, etc. I now find myself in a situation where I have no way to determine if the key I pressed will fire a keychar event (atleast not without a big switch case).
I think it would be a good idea if all 3 key events carried around modifier and unicode information. My original issue was in the fact that keyup did not carry unicode, and now keydown does not either. If it is currently assumed that keydown will never produce a unicode, then it shouldn't hurt anything if they all have it. Filling 2 extra ints each keystroke isn't that expensive imo.
Thanks
I'm not quite sure what you're asking for. The unused fields are always filled with zero if that helps.
Filling 2 extra ints each keystroke isn't that expensive imo.
That's not the issue. The problem is that KEY_DOWN and KEY_UP don't necessarily correspond to unicode characters. It doesn't really make sense for them to include that information. They represent key presses. the KEY_CHAR event represents a unicode character.
So if you have, say, a widget for entering text, you'd use KEY_CHAR for displaying the characters and KEY_DOWN for backspace.
Actually you should use KEY_CHAR for back space as well as you want auto repeat. KEY_CHAR is appropriate for almost anything in a gui I think.
What I mean is, for example in the button, when I get a key down, I check if it is space and if it is, it makes the button looked pushed in until space is released. If a key char was not preceded by a key down and was its own thing, I'd just treat them both as key downs. The problem if I do that is that I'd get sometimes 2 keydowns in my gui hence my issue.
You don't need to track key down and key up anymore. You'll get space and backspace events from KEY_CHAR. Skip the keydown entirely, it aught to work fine.
Yes I understand that but, I designed it to be like Windows controls. So in Windows if you push down on space the button looks pushed in until space is released. If I was doing this Allegro specific, I'd use the keycode for everything, but I don't since it also works with SDL. Keychar works fine for textboxes and what not yes, but when I need to know when its pressed and released it is an issue.
In C# a key down allows you to go: if e.keycode == KEYS_A
which I would then use allegros keycode for that but since it is independent I rely on modifier and unicode field
Otherwise I'd have to wrap allegros keycode or something which might not work with all other backends
objects that want character input should take CHAR events, ones that want to track key state should use DOWN/UP events.
Yes that's what I was already doing for my GUI, except I generated my own keychar events based on the keydown, but I don't know how to do this anymore with the new design because the keydown only gives me a keycode which doesn't work for me, I still need a way to kow if there was a capitol J for instance which I could manually do by checking for shift when I get a keycode of allegro_key_j but this seems error prone when allegro can do it for me.
could there simply just then be a way to know if a keydown is about to produce a keychar? I could would with that.
So if your gui already splits them up, why not just map allegro's events directly to your gui events?
It would be easier and more flexable if there was a boolean indicating if the keydown will also produce a keychar. That gives users the flexibility of doing whatever without having those fields.
Even though my gui is split up it still wants unichar on keydown and keyup
Char events don't map 1:1 with keydown or keyup. Anything else will just give you wrong results in most locales.
Wouldn't pressing shift result in a keydown but no keychar, then pressing j while holding shift result in a keydown followed by a keychar event that would have a J unicode value in it right?
I really have no other way to fix this 
Shift isn't its own key afaik. Its a modifier on a key. So you'd only get the key down, once you hit another key with shift. Then you'd also get a key char from it.
Exactly, that is why I proposed just having a boolean that just notifies the user if this keydown will produce a keychar, this way one could ignore that keydown and wait for the keychar if that is their design. This would allow me to control what I consider is a keychar and what is a keydown and so my keydown would have the unichar field.
This is a example of what I mean. The keydown does infact allow them to query numbers and letters, but then keychar is used for the keypress which is like my design, but they still have a way of knowing if '0' was pressed on keydown which is what I do but I use the unichar field.
Shift isn't its own key afaik. Its a modifier on a key. So you'd only get the key down, once you hit another key with shift.
If that were the case, it'd be a lot harder to map shift to an action key in your game.
At least on OS X this isn't true.
Well I fixed it by doing:
From looking at the source, it appears that you'll always get a KEY_CHAR for every KEY_DOWN. Doesn't that solve the problem?
Yes, as I said, I fixed it, it's still a bit hackier than I wanted though