Input event with origin

[jonasBoss]

fix #435

• update InputEvent to include origin and analog_threshold
• save preset as list with InputEvent as dict inside the mapping
• add capability to load old beta preset
• add origin info to each InputEvent in the EventReader
• update EventHandler's
• make sure forward_release forwards to the correct device release_combination_keys does not always forward to the correct device (beta) #577
• update event pipline creation to respect origin information
• add fallback when origin is not set in mapping
• grab devices based off of origin
  • add fallback when origin can not be found during device grabbing???
• seperate InputEvent from InputConfig
• tests
• delete old stuff
• Update documentation (the preset json has changed)

[jonasBoss]

So this is actually more than just including a origin with each event.

The main change is actually the Separation of InputEvent and InputConfig. Currently they are both very similar but it gives us much more flexibility as the InputConfig is no longer restricted by a single event or performance concerns. This can help if we ever choose to process the input on a per frame basis instead of a per event basis.
We can use the InputConfig to store mapping parameters which can be individual for each input of a mapping (e.g. the release_combination_keys flag).

I also renamed the EventCombination to InputCombination.
@sezanzeb I would like to hear your thoughts on this change.

[sezanzeb]

I'll look at it soon

[sezanzeb]

A miroboard showing how all of our models and classes are related might be great at this point

UIMapping, InputConfig, InputEvent, InputDevice, InputCombination

[sezanzeb]

ah,

so InputConfig is for the mapping and describes the input for a mapping

and InputEvent is for the EventHandler pipeline and describes an actual event that is happening right now?

[jonasBoss]

yeah, that is the idea.
Pylint comes with a pyreverse command which can be used to generate UML. Although, Pylint seems to be broken for me :(

[sezanzeb]

here is the pyreverse output:

[sezanzeb]

How about renaming InputCombination to InputConfigCombination?

[sezanzeb]

Thanks. I think splitting it into InputConfig and InputEvent makes sense

[sezanzeb]

Thanks! Is this ready to merge?

I would probably still rename origin to origin_hash though. What are your thoughts on that and #550 (comment)?

Is there a tests that checks if the hash is calculated correctly? Testing that a given generated InputConfig contains the correct hash, which is provided as hardcoded string in the test with a comment explaining where it comes from. And to test that the correct device ends up in origin.

[jonasBoss]

I will rename origin and then it is ready to merge.
I am not sure about the InputCombination it is already in the configs.input_config module. So it should be clear what it does.

As for this:

make sure forward_release forwards to the correct device

That is a bug which is present on beta since ever. I just never thought about it until this PR made it kind of obvious.
There are two possible solutions, which both will need some work.