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 <overm...@gmail.com <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 <overm...@gmail.com>: >>> >>>> 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 elm-discuss...@googlegroups.com. >>>> 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 elm-discuss...@googlegroups.com <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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
