I have some questions regarding A5 event handling:

1) ALLEGRO_EVENT_KEY_UP does not have the unichar field. Should I keep the unichar value from ALLEGRO_EVENT_KEY_UP myself or it is going to be available in the future?

2) ALLEGRO_EVENT_MOUSE_AXES does not have the button field. Should I keep the button value from ALLEGRO_EVENT_MOUSE_BUTTON_DOWN myself or it is going to be available in the future?

3) Is the ALLEGRO_EVENT_MOUSE_ENTER_DISPLAY event followed by a ALLEGRO_EVENT_MOUSE_AXES event?

4) in the event ALLEGRO_EVENT_MOUSE_AXES, do I check if the mouse moved by checking the fields dx and dy?

I'm sure it wont. Since a mouse button press has nothing to do with the mouse moving.

But what if you want to know which button is pressed while the mouse is moving?

"Normal" event systems (like Win32) report the mouse button as well as the mouse position.

What if you want to know which keyboard button is pressed while the mouse is moving? At which point do you stop from including the entire input state in every input event?

Anyway, you have two solutions. The preferred way is to use those events to update a struct/class of yours that holds the mouse state. The less preferred way is to use al_get_mouse_state.

Well, in principle there's also dz which can also cause the event to be sent... but yes, that's the idea.

Not sure if it's supposed to, but it doesn't seem to. My Canva5 lib handles both messages as if they are a "MOUSE_AXES" event, seems to make sense that way.

It will not be made available.

What's the problem with making unichar available on key down, just out of curiousity?

It is available on key down, but not key up.

I conflated two things into the KEY_DOWN event. First, it signals that the user pressed a physical key. But it also indicates that a user entered a particular character, which could be a combination of keys which were hit previously (e.g. dead keys) or currently held down (e.g. shift).

As Elias has pointed out, we should actually have separate events for physical key presses and character input.

Here's an example. Say you are using dead keys to type é, by hitting two keys in sequence: apostrophe, then E. You get a KEY_DOWN event (keycode=apostrophe, unichar=0), then another KEY_DOWN (keycode=E, unichar=é). Ok so far.

But if you hit apostrophe, then T? Assuming there is no character mapped to that sequence, with some input methods, that could produce two characters. At the time we send out the KEY_DOWN event for T, though, the KEY_DOWN event for apostrophe was already sent out. So we only have one event to signal two characters.

There are more complicated input methods where character input and keys are even more decoupled. e.g. press a few keys, then pick a character from a graphical list with the mouse.

So the answer is: unichar shouldn't even be provided with KEY_DOWN.

Ok. I misread it as KEY_DOWN not providing a unichar. But what you says makes sense. Is this a 5.0 or later update feature?

I don't think anyone is planning to fix this for 5.0, but it should be fixable in a backwards compatible way later.

You stop at the point that the majority of use cases are covered. 99% of mouse moves that need to know the input state is limited to mouse buttons and modifier keys. That's why most Window systems report the mouse button and modifier keys in mouse move events.

I think that the mouse button and modifiers should be reported in mouse move events. The mouse event struct even has the button field available, so minimal changes are required.

I agree, for the reasons you mention.

Interesting. I think you have a convincing point. Using that logic, it certainly makes sense to include the mouse button state with ALLEGRO_EVENT_MOUSE_BUTTON_DOWN. This would make some functionality (dragging, for example) more accessible. After all, ALLEGRO_EVENT_MOUSE_BUTTON_DOWN returns the mouse wheel position, which doesn't seem nearly as practical.