Okay, this keyMap* suggestion would need more scrutiny. Being a more radical departure from the current API, it is not obvious that all current Keyboard uses would still be well supported.
I will open an issue in the Keyboard repository with my more incremental API proposal. 2016-08-11 18:48 GMT+02:00 OvermindDL1 <[email protected]>: > Heh, yes I keep putting different ideas here, I am not focusing on a > single idea, just working with the API's in testing a bit, figure out some > new ideas, and document them here, upon which I then go out, make a mock-up > of the ideas, and see how it works and document the results again. Just a > set of ideas for others to mull over as well to see if anything has merit. > And yep, the latest Keyboard.keyMap* could be a replacement of the existing > API (or added to it). From my mock testing it seems to be the easiest to > use and most configurable thus far for this specific issue (since it is > entirely just a simple-to-read-and-parse data structure without a host of > mis-matched calls). > > > On Thursday, August 11, 2016 at 9:58:28 AM UTC-6, Janis Voigtländer wrote: >> >> You throw in a lot of different ideas. I’m getting confused. >> >> Concerning the approach with having both subscriptions and your new >> filters hook, I still think what I wrote in my last message (about the >> case if you were to make the same decisions as the original code about >> which subscriptions are running when, particularly concerning the animation >> frame ticking): >> >> However, the result will be again more complex and less readable, I >> think. You will have the dealing with subscriptions distributed over >> different places in the code, while the original version and also the >> version improved by selective Keyboard functions has only one. >> >> Your new message does not seem to try to rebut this. Instead, it proposes >> a completely different route? The Keyboard.keyMapChar and >> Keyboard.keyMapFn etc. things. This would be intended as completely >> replacing the current Keyboard API? As a more radical proposal than just >> changing the types of the current Keyboard.downs etc. functions by >> bringing Maybe into play? >> >> >> 2016-08-11 16:51 GMT+02:00 OvermindDL1 <[email protected]>: >> >>> The ticks did change yes, I originally had it testing the state first >>> but figured, eh, I was wanting to see what a keyboard action mapper would >>> be (which could easily be fed into a Keyboard mapper, ignore the filters >>> stuff). >>> >>> I still find mapping the keyboard events 'inside' subscription to be >>> very noisy. And I still think think a single subscription for a keyboard >>> filter would be best to prevent running and testing multiple. Hmm, maybe >>> something like: >>> ```elm >>> Keyboard.keyMapChar >>> case d.state of >>> Running -> >>> [ ( 'P', KeyDown, PauseToggle ) >>> , ( ' ', KeyDown, JumpDown ) >>> , ( ' ', KeyUp, JumpUp ) >>> ] >>> _ -> >>> [ ( 'P', KeyDown, PauseToggle ) >>> ] >>> ``` >>> >>> I am one of those that hate inline conditionals and prefer to hoist it >>> out, so yes I like the duplicated PauseToggle, makes it explicitly obvious >>> that it is working in each state instead of noise like ++ and such making >>> you have to think more. However I think that is wonderfully readable and >>> could easily register and unregister subscriptions as needed while making >>> configurable key mapping much easier (since no need to convert to if/then >>> repeating or dict lookups or so). >>> >>> Or as a full example the above could be: >>> ```elm >>> subscriptions : GameData -> Sub GameMsg >>> subscriptions = >>> case d.state of >>> Running -> >>> Sub.batch >>> [ AnimationFrame.diffs Tick >>> , Keyboard.keyMapChar >>> [ ( 'P', KeyDown, PauseToggle ) >>> , ( ' ', KeyDown, JumpDown ) >>> , ( ' ', KeyUp, JumpUp ) >>> ] >>> ] >>> _ -> Keyboard.keyMapChar [ ( 'P', KeyDown, PauseToggle ) ] >>> ``` >>> >>> Which I also think is far more readable (embedding state tests are >>> always unreadable). >>> >>> A `Keyboard.keyMapFn` could also make the first element of the tuple be >>> a function that is passed in a keycode so it can do its own testing via >>> returning True/False. Or could just make it a `Keyboard.keyMap` where >>> the first element is a subtype to become `( KeyMap.Char 'P', KeyDown, >>> PauseToggle )` or `KeyMap.Fn` or whatever other options. Would make it >>> easier to expand later as well with more functionality if ever desired. >>> >>> As always, lots of ways to go with various designs. >>> >>> >>> On Wednesday, August 10, 2016 at 8:53:32 PM UTC-6, Janis Voigtländer >>> wrote: >>>> >>>> You did change the behavior, though. Specifically, AnimationFrame.ticks >>>> is always running in your version, even when the game is paused. Similarly >>>> for some of the other subscriptions. As discussed in the generic >>>> subscription filtering thread, it's best to turn off subscriptions >>>> completely whenever possible. Of course, you could adapt your version of >>>> the subscriptions-function to bring the turning-off-of-subscriptions back. >>>> However, the result will be again more complex and less readable, I think. >>>> You will have the dealing with subscriptions distributed over different >>>> places in the code, while the original version and also the version >>>> improved by selective Keyboard functions has only one. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Elm Discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
