On Thursday, August 11, 2016 at 11:09:31 PM UTC-6, Janis Voigtländer wrote: > > 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. > They should be I'd think, could have more matchers like a `KeyMap.All` or others as well, could even make a regex matcher for example.
> 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] <javascript:>>: > >> 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] <javascript:>. >> 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.
