Merged two filters into one. Removed extraneous hotkey assignment.

[GrandyB]

• A new drop down called 'Motion Behaviour' which currently has options 'One way' and 'Round trip'.
• Hotkeys get added and removed when switching between the two types, as applicable.
• Hotkeys are no longer added to the "frontend". This means hotkeys are only listed under their relevant scene, not in a global namespace at the top of the hotkey settings page as well.

TODO:

• Check zh-TW.ini (I re-used most of what we already had, but used google translate for 'behaviour', sorry!)
• Give it a play and make sure I haven't missed anything.

[CatxFish]

Haven't test all the behavior yet , but leave a reminder for the future release : Minimum OBS Studio Version should change to 21.0.0 after this commit because of "obs_property_set_modified_callback2"

[CatxFish]

A Potential issue to discuss : If someone choose round-trip behavior and do forward animation then change the behavior, should we restore the source to the origin position or just ignore it?

[GrandyB]

There's a number of issues regarding this, including transition issues, where two scenes with a differently sized image in actually inherits whatever sizing the live scene's image has when it goes to live. So if the live one is 300x300, whatever new image becomes 300x300 lol.

In regards to the frontend hotkeys, unless there's some way we can find of getting and updating the live scene without hitting the transition button, the best we can do is have any registered hotkeys remain in the global namespace until we transition the new settings over.

e.g. I set filter to round trip and transition - both move and there's hotkeys for both in global and in scene. I then set filter to one way. It removes the backwards hotkey for the scene but keeps it in global until you then transition that scene to live.

As said, we've got a bunch of buggy behaviour in relation to preview<->live so I'm less concerned about this. I'll update the pull request with the older hotkey registration code, then work on the modified motion behaviours, at which point I should be bug fixing a bunch of stuff as I go. This would include your last question. It may or may not make sense after I update those behaviours.

Sound reasonable? I'd suggest not doing a release until we've reached that point... so might also not be worth implementing this merge request either?

[CatxFish]

I agree with you , you can focus on the these behaviors first , and just try what you want to do. I opened a new branch for the ongoing modification .