The ExTermbox.Event struct is directly based off of the C struct from the termbox API, which uses integer codes for the event type, key (based on terminfo), modifier, character, etc.:
So far, the recommended way to match events on a certain key has been to match the integer for that key by first looking up the constant, e.g.:
@ctrl_c Constants.key(:ctrl_c)
case message do
{:event, %{key: @ctrl_c}} ->
# handle ctrl-c keypress
This project evolved out of the termbox bindings library, so this event API made sense in the beginning.
Problems
Constants are clumsy
Looking up constants and storing them in an attribute just to pattern match on them feels clumsy and is an unnecessary extra step. It should be possible to simplify the above as such:
case message do
{:event, %{key: :ctrl_c}} ->
# handle ctrl-c keypress
However, one issue with this is that some keys are defined to have the same integer value. For example, ctrl-~ (tilde) and ctrl-2 are both set to 0x00. Which begs the question: which one do we set as key above?
Not integrated with views and rendering
So far, events are completely separate from the views. The "target" of an event is always the terminal. I think we can do better than that. If I click on a label element, it should be possible for the rendering library to figure out that I've clicked that element and expose that information via the event.
Union type has a lot of extraneous information
The event struct is really a sort of union type---each event has a different type and depending on the type, certain information will be filled in and other information will be blank. From a usability standpoint, this can be very confusing.
Ideas
Extended events
In order to (mostly) maintain backwards compatibility, we could take the existing ExTermbox.Event{} struct and extend it with computed information, e.g.:
Current Situtation
Currently, the runtime / event manager sends terminal events as messages to the application in the following format:
The
ExTermbox.Event
struct is directly based off of the C struct from the termbox API, which uses integer codes for the event type, key (based on terminfo), modifier, character, etc.:https://github.com/nsf/termbox/blob/master/src/termbox.h
So far, the recommended way to match events on a certain key has been to match the integer for that key by first looking up the constant, e.g.:
This project evolved out of the termbox bindings library, so this event API made sense in the beginning.
Problems
Constants are clumsy
Looking up constants and storing them in an attribute just to pattern match on them feels clumsy and is an unnecessary extra step. It should be possible to simplify the above as such:
However, one issue with this is that some keys are defined to have the same integer value. For example,
ctrl-~
(tilde) andctrl-2
are both set to0x00
. Which begs the question: which one do we set askey
above?Not integrated with views and rendering
So far, events are completely separate from the views. The "target" of an event is always the terminal. I think we can do better than that. If I click on a label element, it should be possible for the rendering library to figure out that I've clicked that element and expose that information via the event.
Union type has a lot of extraneous information
The event struct is really a sort of union type---each event has a different type and depending on the type, certain information will be filled in and other information will be blank. From a usability standpoint, this can be very confusing.
Ideas
Extended events
In order to (mostly) maintain backwards compatibility, we could take the existing
ExTermbox.Event{}
struct and extend it with computed information, e.g.:AFAIK, it would only break code that explicitly matches the struct (vs. matching any map with the keys).
New event structs by type (Breaking change)
Another approach would be to totally overhaul it in a new major version:
These would also be sent as messages in a new style:
Other Ideas ???
Next Steps
I'd like to get some feedback and let the problem simmer for a while before I start changing anything.