not-fl3
Touch simulation additions
Is it bad practice, that this PR still has the original Window2d struct commit in it (and a revert commit) that is not related to this PR? Would you have suggested using git-cherry-pick for distributing the changes of my branch to two branches or something else @not-fl3?
I just saw a much better way to embed this functionality into the codebase, I will correct it tomorrow.
Is it bad practice, that this PR still has the original Window2d struct commit in it (and a revert commit) that is not related to this PR? Would you have suggested using git-cherry-pick for distributing the changes of my branch to two branches or something else @not-fl3?
generally each PR should have just the commits related to this PR, usually before making the PR you want to rebase your feature branch from the origin's main branch
I would like to add functionality for simulating artificial input events through function calls as well. @not-fl3 Do you think that it is a good idea to save a pointer to the stage given to miniquad in the Window::from_config method in the context so that methods in macroquad can use the pointer to the Stage struct to issue input events? (1) Since the Stage struct has no data right now and basically acts like a module for functions (is there any reason for that? I do not understand why the code is written that way right now), I could alternatively just create another Stage instance in the methods that should raise input events. Is that a better idea? (2) I could also just let the methods access the context directly, but this would require more code, especially if we would like InputReceivers to receive the artificially created input as well. (3)