Re: [elm-discuss] Re: about the Keyboard API

[OvermindDL1]

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 >:
>
>> 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 :
>>>
 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 d

Re: [elm-discuss] Re: about the Keyboard API

[Janis Voigtländer]

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 :

> 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 :
>>
>>> 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'

Re: [elm-discuss] Re: about the Keyboard API

[OvermindDL1]

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 >:
>
>> 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 

Re: [elm-discuss] Re: about the Keyboard API

[Janis Voigtländer]

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 :

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

[elm-discuss] Re: about the Keyboard API

[OvermindDL1]

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

[elm-discuss] Re: about the Keyboard API

[Janis Voigtländer]

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.

Am Donnerstag, 11. August 2016 schrieb OvermindDL1 :

> Yeah they would be useful.  I went ahead and tried my hand at editing the
> code a bit to make it what I think is more readable, although the entire
> project gets formatted exceedingly differently if elm-format is run over
> it, so I did not and followed the existing style.  I'd not messed with a
> game in Elm yet, that was fun.  :-)
>
> But yeah, just a little keypress state action mapper, nothing special,
> easy to read but a bit longer (could put most of it 'in' subscriptions
> instead of another function like I did, but eh, I also like explicit events
> to change states so PauseToggle was broken up from 3 purposes to 3 distinct
> events, multi-purpose events bug me... this did make the program longer
> though, but more readable and easier to follow in my opinion):
> https://github.com/OvermindDL1/dontfall
>
>
> On Wednesday, August 10, 2016 at 3:42:46 PM UTC-6, Gábor Varga wrote:
>>
>> I like the proposed changes to keyboard API, they would definitely make
>> my life easier.
>>
>> Also, that is the level where I want to do filtering in this case: as
>> close to the event source as possible. Since the idea is that I am not
>> interested in a bunch of events: I do not want them to be sent to my
>> application at the first place.
>>
> --
> 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.
>

-- 
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.

Re: [elm-discuss] Re: about the Keyboard API

[OvermindDL1]

Yeah they would be useful.  I went ahead and tried my hand at editing the 
code a bit to make it what I think is more readable, although the entire 
project gets formatted exceedingly differently if elm-format is run over 
it, so I did not and followed the existing style.  I'd not messed with a 
game in Elm yet, that was fun.  :-)

But yeah, just a little keypress state action mapper, nothing special, easy 
to read but a bit longer (could put most of it 'in' subscriptions instead 
of another function like I did, but eh, I also like explicit events to 
change states so PauseToggle was broken up from 3 purposes to 3 distinct 
events, multi-purpose events bug me... this did make the program longer 
though, but more readable and easier to follow in my opinion): 
 https://github.com/OvermindDL1/dontfall


On Wednesday, August 10, 2016 at 3:42:46 PM UTC-6, Gábor Varga wrote:
>
> I like the proposed changes to keyboard API, they would definitely make my 
> life easier.
>
> Also, that is the level where I want to do filtering in this case: as 
> close to the event source as possible. Since the idea is that I am not 
> interested in a bunch of events: I do not want them to be sent to my 
> application at the first place.
>

-- 
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.

Re: [elm-discuss] Re: about the Keyboard API

[Gábor Varga]

I like the proposed changes to keyboard API, they would definitely make my life 
easier.

Also, that is the level where I want to do filtering in this case: as close to 
the event source as possible. Since the idea is that I am not interested in a 
bunch of events: I do not want them to be sent to my application at the first 
place.

-- 
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.

Re: [elm-discuss] Re: about the Keyboard API

[Janis Voigtländer]

For actual subscription filters that I am using I have a lot of ports

Yes, I can see that that would be an additional case. Ports have not been
on my radar, since they were not relevant to the projects considered.

So Keyboard and ports.

For ports, that could motivate a similar change, where

port name : (Type -> msg) -> Sub msg

becomes

port name : (Type -> Maybe msg) -> Sub msg

But let’s not make this part of the current proposal.

In any case, that’s still only two cases (since all ports would be handled
equally), nothing spreading to all APIs.

Also, since my last email, more than 100 more lines total are gone.

That’s nice. But let’s not confuse it with anything meaningful about the
proposal at hand. You are obviously removing a lot of stuff. There’s no way
really for us to know why that stuff was there and what other strategies
might be applicable to remove it or to have prevented it from being there
in the first place. If that’s to be discussed, it belongs in the other
thread, about your “generic filtering of all kinds of events” proposal.

For the five concrete projects I pointed to, I say with confidence that the
Keyboard API proposal I brought up here achieves something which that other
proposal does not, in terms of simplifying the code.
​

2016-08-10 22:21 GMT+02:00 OvermindDL1 :

> On Wednesday, August 10, 2016 at 1:01:10 PM UTC-6, Janis Voigtländer wrote:
>>
>> Only one?
>>
>> Yes, indeed. Note what I wrote there. It talks about filtering
>> subscriptions. All the examples you mention do not seem to be about
>> subscriptions, but instead about updates that come from other sources,
>> probably from HTML events. Where (except keyboard handling) have you wanted
>> to apply a filter function to a Sub-typed thing? (Leading us away from
>> keyboard, so maybe this is more suitable to continue in the other thread
>> about generic subscription filtering.)
>>
> For actual subscription filters that I am using I have a lot of ports
> (integration with javascript code that I am not allowed to get rid of) and
> sometimes the port calls are useful and sometimes they are not.  My Helpers
> library has both a `msg_ignore` and a `cmd_ignore` that I use heavily for
> such purposes (which my Helper library swallows thankfully).  My
> subscriptions used to be fairly large and hairy because of all the checks,
> that is since gone and now replaced with:
> ```elm
>
> subscriptions : Model -> Sub Msgsubscriptions model =
> Sub.batch
> [ port_MessageOptionCB (\{ text } -> MessageOptionCB text)
> , onInfoConnect (\{ msg } -> InfoConnect msg.uid)
> , onRoomListInit (\{ msg, cb_data } -> RoomList_Init cb_data 
> msg.roomlist)
> , onRoomListJoined (\{ msg, cb_data } -> RoomList_Joined cb_data 
> msg.roomlist)
> , onRoomListParted (\{ msg, cb_data } -> RoomList_Parted cb_data 
> msg.roomlist)
> , onRoomListNotif (\{ msg, cb_data } -> RoomList_Notif cb_data 
> msg.msgs)
> , onRoomClosed (\{ msg, cb_data } -> Room_Part cb_data msg)
> , onRoomInfo (\{ msg, cb_data } -> Room_Info cb_data msg)
> , onRoomMsgsInit (\{ msg, cb_data } -> RoomMsg_Init cb_data msg)
> , onRoomMsgsNew (\{ msg, cb_data } -> RoomMsg_New cb_data msg)
> , onRoomUserInit (\{ msg, cb_data } -> RoomUser_Init cb_data msg)
> , onRoomUserJoined (\{ msg, cb_data } -> RoomUser_Joined cb_data msg)
> , onRoomUserParted (\{ msg, cb_data } -> RoomUser_Parted cb_data msg)
> , onRoomNotif (\{ msg, cb_data } -> RoomMsg_Notif cb_data msg.msgs)
> , onRoomSyncState (\{ msg, cb_data } -> RoomMsg_SyncState cb_data msg)
> , onRoomSyncJoin (\{ msg, cb_data } -> RoomMsg_SyncJoin cb_data msg)
> , onRoomSyncLeave (\{ msg, cb_data } -> RoomMsg_SyncLeave cb_data msg)
> , {- snip a *lot* more -}
>
> ```
>
> Although that call is in a module dedicated to ports and subscriptions so
> it is mostly out of sight, but when I had to touch it before it was quite a
> mess (and yes I should re-arrange the order of the cb_data, but meh, this
> way was more natural in the filter and update calls).
>
> Also, since my last email, more than 100 more lines total are gone.  ^.^
>
> --
> 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.
>

-- 
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.

Re: [elm-discuss] Re: about the Keyboard API

[OvermindDL1]

On Wednesday, August 10, 2016 at 1:01:10 PM UTC-6, Janis Voigtländer wrote:
>
> Only one?
>
> Yes, indeed. Note what I wrote there. It talks about filtering 
> subscriptions. All the examples you mention do not seem to be about 
> subscriptions, but instead about updates that come from other sources, 
> probably from HTML events. Where (except keyboard handling) have you wanted 
> to apply a filter function to a Sub-typed thing? (Leading us away from 
> keyboard, so maybe this is more suitable to continue in the other thread 
> about generic subscription filtering.)
>
For actual subscription filters that I am using I have a lot of ports 
(integration with javascript code that I am not allowed to get rid of) and 
sometimes the port calls are useful and sometimes they are not.  My Helpers 
library has both a `msg_ignore` and a `cmd_ignore` that I use heavily for 
such purposes (which my Helper library swallows thankfully).  My 
subscriptions used to be fairly large and hairy because of all the checks, 
that is since gone and now replaced with:
```elm

subscriptions : Model -> Sub Msgsubscriptions model =
Sub.batch
[ port_MessageOptionCB (\{ text } -> MessageOptionCB text)
, onInfoConnect (\{ msg } -> InfoConnect msg.uid)
, onRoomListInit (\{ msg, cb_data } -> RoomList_Init cb_data 
msg.roomlist)
, onRoomListJoined (\{ msg, cb_data } -> RoomList_Joined cb_data 
msg.roomlist)
, onRoomListParted (\{ msg, cb_data } -> RoomList_Parted cb_data 
msg.roomlist)
, onRoomListNotif (\{ msg, cb_data } -> RoomList_Notif cb_data msg.msgs)
, onRoomClosed (\{ msg, cb_data } -> Room_Part cb_data msg)
, onRoomInfo (\{ msg, cb_data } -> Room_Info cb_data msg)
, onRoomMsgsInit (\{ msg, cb_data } -> RoomMsg_Init cb_data msg)
, onRoomMsgsNew (\{ msg, cb_data } -> RoomMsg_New cb_data msg)
, onRoomUserInit (\{ msg, cb_data } -> RoomUser_Init cb_data msg)
, onRoomUserJoined (\{ msg, cb_data } -> RoomUser_Joined cb_data msg)
, onRoomUserParted (\{ msg, cb_data } -> RoomUser_Parted cb_data msg)
, onRoomNotif (\{ msg, cb_data } -> RoomMsg_Notif cb_data msg.msgs)
, onRoomSyncState (\{ msg, cb_data } -> RoomMsg_SyncState cb_data msg)
, onRoomSyncJoin (\{ msg, cb_data } -> RoomMsg_SyncJoin cb_data msg)
, onRoomSyncLeave (\{ msg, cb_data } -> RoomMsg_SyncLeave cb_data msg)
, {- snip a *lot* more -}

```

Although that call is in a module dedicated to ports and subscriptions so 
it is mostly out of sight, but when I had to touch it before it was quite a 
mess (and yes I should re-arrange the order of the cb_data, but meh, this 
way was more natural in the filter and update calls).

Also, since my last email, more than 100 more lines total are gone.  ^.^

-- 
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.

Re: [elm-discuss] Re: about the Keyboard API

[Janis Voigtländer]

Ah entirely replace them

Yes, that’s what I proposed in an earlier message in this thread.

An action manager like mentioned above could make it very easy then,
especially if it was a state-based action mapper as is common in many
windowing systems.

An action manager would be something else, and not needed for the cases I
showed. Concerning extending the Keyboard API in a different direction
(stateful), see the “conditions” set out by Evan in the README:
https://github.com/elm-lang/keyboard/blob/master/README.md.

Just many experiences over many decades of seeing once good API’s explode
and become a mess,…

You may find that what you experienced in other languages and frameworks
about how APIs develop over time does not translate to how things happen in
the Elm sphere, due to the way Evan manages things. In particular for
something like the Keyboard API, which depends on native code and thus will
continue to stay under his control.

Only one?

Yes, indeed. Note what I wrote there. It talks about filtering
subscriptions. All the examples you mention do not seem to be about
subscriptions, but instead about updates that come from other sources,
probably from HTML events. Where (except keyboard handling) have you wanted
to apply a filter function to a Sub-typed thing? (Leading us away from
keyboard, so maybe this is more suitable to continue in the other thread
about generic subscription filtering.)
​

2016-08-10 20:46 GMT+02:00 OvermindDL1 :

> On Wednesday, August 10, 2016 at 12:20:46 PM UTC-6, Daniel Bachler wrote:
>>
>> I like your general solution, OvermindDL1, but I don't think it is
>> mutually exclusive with improving the keyboard api as Janis suggested. For
>> general cases, your solution is great. But as several people already said,
>> with Keyboard it is practically always the case that you want to filter,
>> ergo it makes sense to "bake it into the api" of keyboard.
>>
>
> True yeah.  Actually for a keyboard a state-mapper would probably be
> best.  Being able to register keys to an action and being able to re-map
> them with ease.  Could make an easy set of functions for that.
>
>
> On Wednesday, August 10, 2016 at 12:20:46 PM UTC-6, Daniel Bachler wrote:
>
>> So from me +1 for Janis revised proposal for this specific case, but also
>> a thumbs up to the general approach to filtering. OvermindDL1, do you want
>> to write a post about this showing it to newcomers in more detail?
>>
>
> Already did:  https://groups.google.com/forum/#!topic/elm-discuss/u_
> 30Y4iueRY
>
>
>
> On Wednesday, August 10, 2016 at 12:21:45 PM UTC-6, Janis Voigtländer
> wrote:
>>
>> I don’t understand your concern. The Keyboard API would not get larger,
>> because I have proposed to replace three old functions by three new
>> functions.
>>
> Ah entirely replace them.  An action manager like mentioned above could
> make it very easy then, especially if it was a state-based action mapper as
> is common in many windowing systems.
>
>
> On Wednesday, August 10, 2016 at 12:21:45 PM UTC-6, Janis Voigtländer
> wrote:
>
>> The rest of your concerns build on that concern (ballooning), so seem
>> immaterial to me at the moment.
>>
> Just many experiences over many decades of seeing once good API's explode
> and become a mess, bit paranoid about it...  >.>
>
>
> On Wednesday, August 10, 2016 at 12:21:45 PM UTC-6, Janis Voigtländer
> wrote:
>
>> Generally, if you haven’t yet, you might want to go back and read the
>> original “generic subscription filtering” thread I pointed to in the first
>> post, in full. And I may add that since then I have been on the lookout for
>> specific cases where subscription filtering is desired. I haven’t found
>> enough cases to convince myself that a generic mechanism is called for. In
>> fact, I found *exactly* the one, keyboard handling, that I am addressing
>> here. I naturally have looked in only specific places, but let me say that
>> I have had more than those five students coding Elm projects.
>>
> Only one?  I've cleaned out a half-dozen messages from my big app and
> still have plenty more to work through as I notice them.  It has changed
> the code count by (checking git) total of -77 lines (everything is
> `elm-format`'d as well), which is fairly significant for only handling 6
> message types so far.
>
> But of the filtering I do so far, I have two TEA-modules hooked in (my own
> Helpers and elm-mdl), handle the Scroll event (I only load older messages
> if the scroll hits within 16 pixels of the top of the div), as well as 3
> notification ones that I ignore if the relevant room is not visible at the
> moment (the primary path already registers others to the top notification
> listing).  I am really liking how it looks though, flattened 'update'
> significantly in some hairy sections.  :-)
>
>
>> --
> 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-dis

Re: [elm-discuss] Re: about the Keyboard API

[OvermindDL1]

On Wednesday, August 10, 2016 at 12:20:46 PM UTC-6, Daniel Bachler wrote:
>
> I like your general solution, OvermindDL1, but I don't think it is 
> mutually exclusive with improving the keyboard api as Janis suggested. For 
> general cases, your solution is great. But as several people already said, 
> with Keyboard it is practically always the case that you want to filter, 
> ergo it makes sense to "bake it into the api" of keyboard.
>
 
True yeah.  Actually for a keyboard a state-mapper would probably be best. 
 Being able to register keys to an action and being able to re-map them 
with ease.  Could make an easy set of functions for that.


On Wednesday, August 10, 2016 at 12:20:46 PM UTC-6, Daniel Bachler wrote: 

> So from me +1 for Janis revised proposal for this specific case, but also 
> a thumbs up to the general approach to filtering. OvermindDL1, do you want 
> to write a post about this showing it to newcomers in more detail?
>

Already did: 
 https://groups.google.com/forum/#!topic/elm-discuss/u_30Y4iueRY 



On Wednesday, August 10, 2016 at 12:21:45 PM UTC-6, Janis Voigtländer wrote:
>
> I don’t understand your concern. The Keyboard API would not get larger, 
> because I have proposed to replace three old functions by three new 
> functions. 
>
Ah entirely replace them.  An action manager like mentioned above could 
make it very easy then, especially if it was a state-based action mapper as 
is common in many windowing systems.


On Wednesday, August 10, 2016 at 12:21:45 PM UTC-6, Janis Voigtländer wrote:

> The rest of your concerns build on that concern (ballooning), so seem 
> immaterial to me at the moment.
>
Just many experiences over many decades of seeing once good API's explode 
and become a mess, bit paranoid about it...  >.>

 
On Wednesday, August 10, 2016 at 12:21:45 PM UTC-6, Janis Voigtländer wrote:

> Generally, if you haven’t yet, you might want to go back and read the 
> original “generic subscription filtering” thread I pointed to in the first 
> post, in full. And I may add that since then I have been on the lookout for 
> specific cases where subscription filtering is desired. I haven’t found 
> enough cases to convince myself that a generic mechanism is called for. In 
> fact, I found *exactly* the one, keyboard handling, that I am addressing 
> here. I naturally have looked in only specific places, but let me say that 
> I have had more than those five students coding Elm projects.
>
Only one?  I've cleaned out a half-dozen messages from my big app and still 
have plenty more to work through as I notice them.  It has changed the code 
count by (checking git) total of -77 lines (everything is `elm-format`'d as 
well), which is fairly significant for only handling 6 message types so far.

But of the filtering I do so far, I have two TEA-modules hooked in (my own 
Helpers and elm-mdl), handle the Scroll event (I only load older messages 
if the scroll hits within 16 pixels of the top of the div), as well as 3 
notification ones that I ignore if the relevant room is not visible at the 
moment (the primary path already registers others to the top notification 
listing).  I am really liking how it looks though, flattened 'update' 
significantly in some hairy sections.  :-)


>

-- 
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.

Re: [elm-discuss] Re: about the Keyboard API

[Janis Voigtländer]

I don’t understand your concern. The Keyboard API would not get larger,
because I have proposed to replace three old functions by three new
functions.

The rest of your concerns build on that concern (ballooning), so seem
immaterial to me at the moment.

Let’s judge the proposed change to the Keyboard API on its own merits, not
on some feared implicit outreach to other APIs.

Other issues like onScroll etc. may have their own API problems. They are
not directly affected by the change to the Keyboard API, though. Maybe you
want to discuss those other API problems in separate threads, with concrete
examples as well?

Generally, if you haven’t yet, you might want to go back and read the
original “generic subscription filtering” thread I pointed to in the first
post, in full. And I may add that since then I have been on the lookout for
specific cases where subscription filtering is desired. I haven’t found
enough cases to convince myself that a generic mechanism is called for. In
fact, I found *exactly* the one, keyboard handling, that I am addressing
here. I naturally have looked in only specific places, but let me say that
I have had more than those five students coding Elm projects.
​

2016-08-10 20:08 GMT+02:00 OvermindDL1 :

>
> On Wednesday, August 10, 2016 at 11:51:36 AM UTC-6, Janis Voigtländer
> wrote:
>
>> Okay, saw this only after sending my previous message. Still, the
>> FilterOnly message to be handled in update functions now is like a
>> return of the NothingHappened message that I was so happy to have
>> eliminated. Plus, the filters function’s added complexity. I still stand
>> with “I’d rather have the Keyboard API changed in the way I proposed,
>> than to have to use this more complicated machinery.”
>>
> Given this, how would that balloon the API for something like `onScroll`
> to only handle when it is in certain areas (like the top/bottom to load
> more things)?  Or balloon the API for listening for, say, a "@\b[^\b]*\b"
> in a string in a textfield so you only get a message when one exists?
> Etc... etc...  The Keyboard API would get larger with such an API change
> and the same style would have to be copied into everything that could
> potentially be subscribed to else no filtering in those either except in
> update (which would still call subscriptions/view).  It just seems like a
> very slippery slope to me.  If such an API was added to Keyboard then
> someone could point to it as an example of why it should be added to on a
> Scroll message, or handling input, or etc...  `filters` may be a new
> callback but it gathers all of those needed things in to one place while
> keeping update/subscriptions highly readable, as well as filters being
> highly readable as it only handles one concept, filtering, instead of
> having spaghetti code all over the place to do this testing.  With
> `filters` my code has shrunk in size, a lot of 'if' and 'case's are just
> gone (not moved to filter, a lot are entirely *gone*).  It handles this
> case, and others without starting down the slippery slope of API ballooning.
>
>
>
>
>> 2016-08-10 19:38 GMT+02:00 OvermindDL1 :
>>
>>> It would need the HandleKeyboardDown/Up messages, however I've recently
>>> made a change to my Msg structure so I have something like this:
>>> ```elm
>>>
>>> type alias MsgFiltered =
>>>   { HandleKeyboardUp Char
>>>   , HandleKeyboardDown Char
>>>   }
>>> type alias Msg
>>>   = FilterOnly MsgFiltered
>>>   | Other
>>>   | Interesting
>>>   | To
>>>   | Update
>>>   | Messages
>>>   | Like
>>>   | JumpDown
>>>   | JumpUp
>>>
>>> ```
>>> And it seems to be working well.  I just ignore the `FilterOnly` message
>>> entirely in my Update and can handle `FilterOnly` messages in the filter
>>> with ease (while still filtering others if I want).  It makes it easy to
>>> add messages that are only converted to others in the filter, then just
>>> subscribe to `(\c -> FilterOnly (TestFiltered c))` as normal.  That way you
>>> do not need to even have a case for them in your main update, just for the
>>> FilterOnly one, which you can just `( model, Cmd.none )` once.
>>>
>>>
>>> On Wednesday, August 10, 2016 at 11:22:47 AM UTC-6, Janis Voigtländer
>>> wrote:

 What will the GameMsg type look like?
 ​

 2016-08-10 18:59 GMT+02:00 OvermindDL1 :

> > If there are alternatives *with currently available functions* to
> my proposal, very interested to hear it in this thread.
>
> That is why I looked at more options and started thinking about how it
> could also solve other filtering issues that I have, so a singular thing
> that could solve it all would be nice.  :-)
>
>
> Given code from the dontfall game, the current top-post suggestion was
> to change subscriptions to be:
> ```elm
>
> subscriptions : GameData -> Sub GameMsgsubscriptions d =
> Sub.batch
> ([ Keyboard.downsSelectively (\c -> if Char.fromCode c == 'P' 
> then Just PauseToogle else

Re: [elm-discuss] Re: about the Keyboard API

[Daniel Bachler]

I like your general solution, OvermindDL1, but I don't think it is mutually
exclusive with improving the keyboard api as Janis suggested. For general
cases, your solution is great. But as several people already said, with
Keyboard it is practically always the case that you want to filter, ergo it
makes sense to "bake it into the api" of keyboard.

So from me +1 for Janis revised proposal for this specific case, but also a
thumbs up to the general approach to filtering. OvermindDL1, do you want to
write a post about this showing it to newcomers in more detail?


-- 
Daniel Bachler
http://www.danielbachler.de


On 10 August 2016 at 20:08, OvermindDL1  wrote:

>
> On Wednesday, August 10, 2016 at 11:51:36 AM UTC-6, Janis Voigtländer
> wrote:
>
>> Okay, saw this only after sending my previous message. Still, the
>> FilterOnly message to be handled in update functions now is like a
>> return of the NothingHappened message that I was so happy to have
>> eliminated. Plus, the filters function’s added complexity. I still stand
>> with “I’d rather have the Keyboard API changed in the way I proposed,
>> than to have to use this more complicated machinery.”
>>
> Given this, how would that balloon the API for something like `onScroll`
> to only handle when it is in certain areas (like the top/bottom to load
> more things)?  Or balloon the API for listening for, say, a "@\b[^\b]*\b"
> in a string in a textfield so you only get a message when one exists?
> Etc... etc...  The Keyboard API would get larger with such an API change
> and the same style would have to be copied into everything that could
> potentially be subscribed to else no filtering in those either except in
> update (which would still call subscriptions/view).  It just seems like a
> very slippery slope to me.  If such an API was added to Keyboard then
> someone could point to it as an example of why it should be added to on a
> Scroll message, or handling input, or etc...  `filters` may be a new
> callback but it gathers all of those needed things in to one place while
> keeping update/subscriptions highly readable, as well as filters being
> highly readable as it only handles one concept, filtering, instead of
> having spaghetti code all over the place to do this testing.  With
> `filters` my code has shrunk in size, a lot of 'if' and 'case's are just
> gone (not moved to filter, a lot are entirely *gone*).  It handles this
> case, and others without starting down the slippery slope of API ballooning.
>
>
>
>
>> 2016-08-10 19:38 GMT+02:00 OvermindDL1 :
>>
>>> It would need the HandleKeyboardDown/Up messages, however I've recently
>>> made a change to my Msg structure so I have something like this:
>>> ```elm
>>>
>>> type alias MsgFiltered =
>>>   { HandleKeyboardUp Char
>>>   , HandleKeyboardDown Char
>>>   }
>>> type alias Msg
>>>   = FilterOnly MsgFiltered
>>>   | Other
>>>   | Interesting
>>>   | To
>>>   | Update
>>>   | Messages
>>>   | Like
>>>   | JumpDown
>>>   | JumpUp
>>>
>>> ```
>>> And it seems to be working well.  I just ignore the `FilterOnly` message
>>> entirely in my Update and can handle `FilterOnly` messages in the filter
>>> with ease (while still filtering others if I want).  It makes it easy to
>>> add messages that are only converted to others in the filter, then just
>>> subscribe to `(\c -> FilterOnly (TestFiltered c))` as normal.  That way you
>>> do not need to even have a case for them in your main update, just for the
>>> FilterOnly one, which you can just `( model, Cmd.none )` once.
>>>
>>>
>>> On Wednesday, August 10, 2016 at 11:22:47 AM UTC-6, Janis Voigtländer
>>> wrote:

 What will the GameMsg type look like?
 ​

 2016-08-10 18:59 GMT+02:00 OvermindDL1 :

> > If there are alternatives *with currently available functions* to
> my proposal, very interested to hear it in this thread.
>
> That is why I looked at more options and started thinking about how it
> could also solve other filtering issues that I have, so a singular thing
> that could solve it all would be nice.  :-)
>
>
> Given code from the dontfall game, the current top-post suggestion was
> to change subscriptions to be:
> ```elm
>
> subscriptions : GameData -> Sub GameMsgsubscriptions d =
> Sub.batch
> ([ Keyboard.downsSelectively (\c -> if Char.fromCode c == 'P' 
> then Just PauseToogle else Nothing) ] ++
> if d.state == Running then
> [ AnimationFrame.diffs Tick
> , Keyboard.downsSelectively (\c -> if Char.fromCode c == 
> ' ' then Just JumpDown else Nothing)
> , Keyboard.upsSelectively (\c -> if Char.fromCode c == ' 
> ' then Just JumpUp else Nothing)
> ]
> else
> [])
>
> ```
>
> In the thing I proposed that can handle generic message filtering (not
> just subscrip

Re: [elm-discuss] Re: about the Keyboard API

[OvermindDL1]

On Wednesday, August 10, 2016 at 11:51:36 AM UTC-6, Janis Voigtländer wrote:

> Okay, saw this only after sending my previous message. Still, the 
> FilterOnly message to be handled in update functions now is like a return 
> of the NothingHappened message that I was so happy to have eliminated. 
> Plus, the filters function’s added complexity. I still stand with “I’d 
> rather have the Keyboard API changed in the way I proposed, than to have 
> to use this more complicated machinery.”
>
Given this, how would that balloon the API for something like `onScroll` to 
only handle when it is in certain areas (like the top/bottom to load more 
things)?  Or balloon the API for listening for, say, a "@\b[^\b]*\b" in a 
string in a textfield so you only get a message when one exists?  Etc... 
etc...  The Keyboard API would get larger with such an API change and the 
same style would have to be copied into everything that could potentially 
be subscribed to else no filtering in those either except in update (which 
would still call subscriptions/view).  It just seems like a very slippery 
slope to me.  If such an API was added to Keyboard then someone could point 
to it as an example of why it should be added to on a Scroll message, or 
handling input, or etc...  `filters` may be a new callback but it gathers 
all of those needed things in to one place while keeping 
update/subscriptions highly readable, as well as filters being highly 
readable as it only handles one concept, filtering, instead of having 
spaghetti code all over the place to do this testing.  With `filters` my 
code has shrunk in size, a lot of 'if' and 'case's are just gone (not moved 
to filter, a lot are entirely *gone*).  It handles this case, and others 
without starting down the slippery slope of API ballooning.


 

> 2016-08-10 19:38 GMT+02:00 OvermindDL1 >:
>
>> It would need the HandleKeyboardDown/Up messages, however I've recently 
>> made a change to my Msg structure so I have something like this:
>> ```elm
>>
>> type alias MsgFiltered =
>>   { HandleKeyboardUp Char
>>   , HandleKeyboardDown Char
>>   }
>> type alias Msg
>>   = FilterOnly MsgFiltered
>>   | Other
>>   | Interesting
>>   | To
>>   | Update
>>   | Messages
>>   | Like
>>   | JumpDown
>>   | JumpUp
>>
>> ```
>> And it seems to be working well.  I just ignore the `FilterOnly` message 
>> entirely in my Update and can handle `FilterOnly` messages in the filter 
>> with ease (while still filtering others if I want).  It makes it easy to 
>> add messages that are only converted to others in the filter, then just 
>> subscribe to `(\c -> FilterOnly (TestFiltered c))` as normal.  That way you 
>> do not need to even have a case for them in your main update, just for the 
>> FilterOnly one, which you can just `( model, Cmd.none )` once.
>>
>>
>> On Wednesday, August 10, 2016 at 11:22:47 AM UTC-6, Janis Voigtländer 
>> wrote:
>>>
>>> What will the GameMsg type look like?
>>> ​
>>>
>>> 2016-08-10 18:59 GMT+02:00 OvermindDL1 :
>>>
 > If there are alternatives *with currently available functions* to my 
 proposal, very interested to hear it in this thread.

 That is why I looked at more options and started thinking about how it 
 could also solve other filtering issues that I have, so a singular thing 
 that could solve it all would be nice.  :-)


 Given code from the dontfall game, the current top-post suggestion was 
 to change subscriptions to be:
 ```elm

 subscriptions : GameData -> Sub GameMsgsubscriptions d =
 Sub.batch
 ([ Keyboard.downsSelectively (\c -> if Char.fromCode c == 'P' then 
 Just PauseToogle else Nothing) ] ++
 if d.state == Running then
 [ AnimationFrame.diffs Tick
 , Keyboard.downsSelectively (\c -> if Char.fromCode c == ' 
 ' then Just JumpDown else Nothing)
 , Keyboard.upsSelectively (\c -> if Char.fromCode c == ' ' 
 then Just JumpUp else Nothing)
 ]
 else
 [])

 ```

 In the thing I proposed that can handle generic message filtering (not 
 just subscription) would turn the above back into a fairly normal and 
 readable style of:
 ```elm

 subscriptions : GameData -> Sub GameMsgsubscriptions d =
 Sub.batch
   [ Keyboard.downs HandleKeyboardDown
   , Keyboard.ups HandleKeyboardUps
   , if d.state == Running then AnimationFrame.diffs Tick else Sub.none
   ]

 ```
 And a new callback (added in the main where init/update/etc are, in my 
 package is called 'filters') would be something like this, this is a very 
 simple example and `filters` can do a lot more, but for simple keyboard 
 filtering:
 ```elm

 filters : Msg -> Model -> ( Msg, States Model Msg )filters msg model =
   if model.state == Running then
 case msg of
  

Re: [elm-discuss] Re: about the Keyboard API

[OvermindDL1]

Yeah I've been looking for potentially a way to have 2 message types 
altogether.  I am leaning toward just Msg having an UpdateMsg and a 
FilterMsg subtypes.  It would be easy to split on either then and even 
hoist them into their request function.


On Wednesday, August 10, 2016 at 11:51:36 AM UTC-6, Janis Voigtländer wrote:
>
> Okay, saw this only after sending my previous message. Still, the 
> FilterOnly message to be handled in update functions now is like a return 
> of the NothingHappened message that I was so happy to have eliminated. 
> Plus, the filters function’s added complexity. I still stand with “I’d 
> rather have the Keyboard API changed in the way I proposed, than to have 
> to use this more complicated machinery.”
> ​
>
> 2016-08-10 19:38 GMT+02:00 OvermindDL1 >:
>
>> It would need the HandleKeyboardDown/Up messages, however I've recently 
>> made a change to my Msg structure so I have something like this:
>> ```elm
>>
>> type alias MsgFiltered =
>>   { HandleKeyboardUp Char
>>   , HandleKeyboardDown Char
>>   }
>> type alias Msg
>>   = FilterOnly MsgFiltered
>>   | Other
>>   | Interesting
>>   | To
>>   | Update
>>   | Messages
>>   | Like
>>   | JumpDown
>>   | JumpUp
>>
>> ```
>> And it seems to be working well.  I just ignore the `FilterOnly` message 
>> entirely in my Update and can handle `FilterOnly` messages in the filter 
>> with ease (while still filtering others if I want).  It makes it easy to 
>> add messages that are only converted to others in the filter, then just 
>> subscribe to `(\c -> FilterOnly (TestFiltered c))` as normal.  That way you 
>> do not need to even have a case for them in your main update, just for the 
>> FilterOnly one, which you can just `( model, Cmd.none )` once.
>>
>>
>> On Wednesday, August 10, 2016 at 11:22:47 AM UTC-6, Janis Voigtländer 
>> wrote:
>>>
>>> What will the GameMsg type look like?
>>> ​
>>>
>>> 2016-08-10 18:59 GMT+02:00 OvermindDL1 :
>>>
 > If there are alternatives *with currently available functions* to my 
 proposal, very interested to hear it in this thread.

 That is why I looked at more options and started thinking about how it 
 could also solve other filtering issues that I have, so a singular thing 
 that could solve it all would be nice.  :-)


 Given code from the dontfall game, the current top-post suggestion was 
 to change subscriptions to be:
 ```elm

 subscriptions : GameData -> Sub GameMsgsubscriptions d =
 Sub.batch
 ([ Keyboard.downsSelectively (\c -> if Char.fromCode c == 'P' then 
 Just PauseToogle else Nothing) ] ++
 if d.state == Running then
 [ AnimationFrame.diffs Tick
 , Keyboard.downsSelectively (\c -> if Char.fromCode c == ' 
 ' then Just JumpDown else Nothing)
 , Keyboard.upsSelectively (\c -> if Char.fromCode c == ' ' 
 then Just JumpUp else Nothing)
 ]
 else
 [])

 ```

 In the thing I proposed that can handle generic message filtering (not 
 just subscription) would turn the above back into a fairly normal and 
 readable style of:
 ```elm

 subscriptions : GameData -> Sub GameMsgsubscriptions d =
 Sub.batch
   [ Keyboard.downs HandleKeyboardDown
   , Keyboard.ups HandleKeyboardUps
   , if d.state == Running then AnimationFrame.diffs Tick else Sub.none
   ]

 ```
 And a new callback (added in the main where init/update/etc are, in my 
 package is called 'filters') would be something like this, this is a very 
 simple example and `filters` can do a lot more, but for simple keyboard 
 filtering:
 ```elm

 filters : Msg -> Model -> ( Msg, States Model Msg )filters msg model =
   if model.state == Running then
 case msg of
 HandleKeyboardDown c ->
 case Char.fromCode c ->
 'P' -> ( PauseToggle, States.enableAll )
 ' ' -> ( JumpDown, States.enableAll )
 _ -> ( msg, States.disableAll )
 HandleKeyboardUp c ->
 case Char.fromCode c ->
 ' ' -> ( JumpUp, States.enableAll )
 _ -> ( msg, States.disableAll )
 _ -> ( msg, States.enableAll )
   else
   ( msg, States.enableAll )

 ```
 You could also delegate to other TEA-style modules.  You could filter 
 out the Tick here instead of subscribing and unsubscribing (I like a 
 simple 
 'subscriptions' callback).  Anything with `States.disableAll` will disable 
 all callbacks for that msg, so update will not be called, subscriptions 
 will not be called, and view will not be called (it returns the cached 
 values from last time so an exact match test of === in javascript shows 
 they are identical and thus Elm will do

Re: [elm-discuss] Re: about the Keyboard API

[Janis Voigtländer]

Let me answer that myself, after looking some more at your proposal.

The GameMsg type would become more complicated than it was before, rather
than becoming less complicated as was the case with my proposal/design.

Moreover, the update function would also be more complicated. You say that
certain messages will never get there. But still the compiler will force
you to do something about them, due to exhaustiveness checking. In my
original post I argued that using the new API the update function would be
simpler and more refactoring safe in case of future extensions. That
advantage is lost with your approach (if you don’t agree with that
assessment, please show how the update function would look, concretely).

Plus, the filters function adds conceptual complexity, whereas in my
original post the goal was reduced conceptual complexity, and the changes I
showed there on the concrete project demonstrate that such a reduction is
indeed achieved.

So, your approach may have other uses, but as far as I can see it does not
have the use I was after with the proposed API change, namely to simplify
typical keyboard handling code as exemplified by those five different
projects of different people.
​

2016-08-10 19:22 GMT+02:00 Janis Voigtländer :

> What will the GameMsg type look like?
> ​
>
> 2016-08-10 18:59 GMT+02:00 OvermindDL1 :
>
>> > If there are alternatives *with currently available functions* to my
>> proposal, very interested to hear it in this thread.
>>
>> That is why I looked at more options and started thinking about how it
>> could also solve other filtering issues that I have, so a singular thing
>> that could solve it all would be nice.  :-)
>>
>>
>> Given code from the dontfall game, the current top-post suggestion was to
>> change subscriptions to be:
>> ```elm
>>
>> subscriptions : GameData -> Sub GameMsgsubscriptions d =
>> Sub.batch
>> ([ Keyboard.downsSelectively (\c -> if Char.fromCode c == 'P' then 
>> Just PauseToogle else Nothing) ] ++
>> if d.state == Running then
>> [ AnimationFrame.diffs Tick
>> , Keyboard.downsSelectively (\c -> if Char.fromCode c == ' ' 
>> then Just JumpDown else Nothing)
>> , Keyboard.upsSelectively (\c -> if Char.fromCode c == ' ' 
>> then Just JumpUp else Nothing)
>> ]
>> else
>> [])
>>
>> ```
>>
>> In the thing I proposed that can handle generic message filtering (not
>> just subscription) would turn the above back into a fairly normal and
>> readable style of:
>> ```elm
>>
>> subscriptions : GameData -> Sub GameMsgsubscriptions d =
>> Sub.batch
>>   [ Keyboard.downs HandleKeyboardDown
>>   , Keyboard.ups HandleKeyboardUps
>>   , if d.state == Running then AnimationFrame.diffs Tick else Sub.none
>>   ]
>>
>> ```
>> And a new callback (added in the main where init/update/etc are, in my
>> package is called 'filters') would be something like this, this is a very
>> simple example and `filters` can do a lot more, but for simple keyboard
>> filtering:
>> ```elm
>>
>> filters : Msg -> Model -> ( Msg, States Model Msg )filters msg model =
>>   if model.state == Running then
>> case msg of
>> HandleKeyboardDown c ->
>> case Char.fromCode c ->
>> 'P' -> ( PauseToggle, States.enableAll )
>> ' ' -> ( JumpDown, States.enableAll )
>> _ -> ( msg, States.disableAll )
>> HandleKeyboardUp c ->
>> case Char.fromCode c ->
>> ' ' -> ( JumpUp, States.enableAll )
>> _ -> ( msg, States.disableAll )
>> _ -> ( msg, States.enableAll )
>>   else
>>   ( msg, States.enableAll )
>>
>> ```
>> You could also delegate to other TEA-style modules.  You could filter out
>> the Tick here instead of subscribing and unsubscribing (I like a simple
>> 'subscriptions' callback).  Anything with `States.disableAll` will disable
>> all callbacks for that msg, so update will not be called, subscriptions
>> will not be called, and view will not be called (it returns the cached
>> values from last time so an exact match test of === in javascript shows
>> they are identical and thus Elm will do nothing).
>>
>> With the above `filters` you will not ever get
>> HandleKeyboardDown/HandleKeyboardUp in your `update` at all, ever, it is
>> either translated to another message or entirely canceled.  Adding more
>> message conversions is as simple as adding another case, so you could add,
>> say a shooting state with like:
>> ```elm
>>
>> filters : Msg -> Model -> ( Msg, States Model Msg )filters msg model =
>>   if model.state == Running then
>> case msg of
>> HandleKeyboardDown c ->
>> case Char.fromCode c ->
>> 'P' -> ( PauseToggle, States.enableAll )
>> ' ' -> ( JumpDown, States.enableAll )
>> 'z' -> ( StartShooting, States.enableAll )
>> _ -> ( msg, States.di

Re: [elm-discuss] Re: about the Keyboard API

[Janis Voigtländer]

Okay, saw this only after sending my previous message. Still, the FilterOnly
message to be handled in update functions now is like a return of the
NothingHappened message that I was so happy to have eliminated. Plus, the
filters function’s added complexity. I still stand with “I’d rather have
the Keyboard API changed in the way I proposed, than to have to use this
more complicated machinery.”
​

2016-08-10 19:38 GMT+02:00 OvermindDL1 :

> It would need the HandleKeyboardDown/Up messages, however I've recently
> made a change to my Msg structure so I have something like this:
> ```elm
>
> type alias MsgFiltered =
>   { HandleKeyboardUp Char
>   , HandleKeyboardDown Char
>   }
> type alias Msg
>   = FilterOnly MsgFiltered
>   | Other
>   | Interesting
>   | To
>   | Update
>   | Messages
>   | Like
>   | JumpDown
>   | JumpUp
>
> ```
> And it seems to be working well.  I just ignore the `FilterOnly` message
> entirely in my Update and can handle `FilterOnly` messages in the filter
> with ease (while still filtering others if I want).  It makes it easy to
> add messages that are only converted to others in the filter, then just
> subscribe to `(\c -> FilterOnly (TestFiltered c))` as normal.  That way you
> do not need to even have a case for them in your main update, just for the
> FilterOnly one, which you can just `( model, Cmd.none )` once.
>
>
> On Wednesday, August 10, 2016 at 11:22:47 AM UTC-6, Janis Voigtländer
> wrote:
>>
>> What will the GameMsg type look like?
>> ​
>>
>> 2016-08-10 18:59 GMT+02:00 OvermindDL1 :
>>
>>> > If there are alternatives *with currently available functions* to my
>>> proposal, very interested to hear it in this thread.
>>>
>>> That is why I looked at more options and started thinking about how it
>>> could also solve other filtering issues that I have, so a singular thing
>>> that could solve it all would be nice.  :-)
>>>
>>>
>>> Given code from the dontfall game, the current top-post suggestion was
>>> to change subscriptions to be:
>>> ```elm
>>>
>>> subscriptions : GameData -> Sub GameMsgsubscriptions d =
>>> Sub.batch
>>> ([ Keyboard.downsSelectively (\c -> if Char.fromCode c == 'P' then 
>>> Just PauseToogle else Nothing) ] ++
>>> if d.state == Running then
>>> [ AnimationFrame.diffs Tick
>>> , Keyboard.downsSelectively (\c -> if Char.fromCode c == ' 
>>> ' then Just JumpDown else Nothing)
>>> , Keyboard.upsSelectively (\c -> if Char.fromCode c == ' ' 
>>> then Just JumpUp else Nothing)
>>> ]
>>> else
>>> [])
>>>
>>> ```
>>>
>>> In the thing I proposed that can handle generic message filtering (not
>>> just subscription) would turn the above back into a fairly normal and
>>> readable style of:
>>> ```elm
>>>
>>> subscriptions : GameData -> Sub GameMsgsubscriptions d =
>>> Sub.batch
>>>   [ Keyboard.downs HandleKeyboardDown
>>>   , Keyboard.ups HandleKeyboardUps
>>>   , if d.state == Running then AnimationFrame.diffs Tick else Sub.none
>>>   ]
>>>
>>> ```
>>> And a new callback (added in the main where init/update/etc are, in my
>>> package is called 'filters') would be something like this, this is a very
>>> simple example and `filters` can do a lot more, but for simple keyboard
>>> filtering:
>>> ```elm
>>>
>>> filters : Msg -> Model -> ( Msg, States Model Msg )filters msg model =
>>>   if model.state == Running then
>>> case msg of
>>> HandleKeyboardDown c ->
>>> case Char.fromCode c ->
>>> 'P' -> ( PauseToggle, States.enableAll )
>>> ' ' -> ( JumpDown, States.enableAll )
>>> _ -> ( msg, States.disableAll )
>>> HandleKeyboardUp c ->
>>> case Char.fromCode c ->
>>> ' ' -> ( JumpUp, States.enableAll )
>>> _ -> ( msg, States.disableAll )
>>> _ -> ( msg, States.enableAll )
>>>   else
>>>   ( msg, States.enableAll )
>>>
>>> ```
>>> You could also delegate to other TEA-style modules.  You could filter
>>> out the Tick here instead of subscribing and unsubscribing (I like a simple
>>> 'subscriptions' callback).  Anything with `States.disableAll` will disable
>>> all callbacks for that msg, so update will not be called, subscriptions
>>> will not be called, and view will not be called (it returns the cached
>>> values from last time so an exact match test of === in javascript shows
>>> they are identical and thus Elm will do nothing).
>>>
>>> With the above `filters` you will not ever get
>>> HandleKeyboardDown/HandleKeyboardUp in your `update` at all, ever, it
>>> is either translated to another message or entirely canceled.  Adding more
>>> message conversions is as simple as adding another case, so you could add,
>>> say a shooting state with like:
>>> ```elm
>>>
>>> filters : Msg -> Model -> ( Msg, States Model Msg )filters msg model =
>>>   if model.state == Running then
>>> case msg of
>>> 

Re: [elm-discuss] Re: about the Keyboard API

[OvermindDL1]

It would need the HandleKeyboardDown/Up messages, however I've recently 
made a change to my Msg structure so I have something like this:
```elm

type alias MsgFiltered =
  { HandleKeyboardUp Char
  , HandleKeyboardDown Char
  }
type alias Msg
  = FilterOnly MsgFiltered
  | Other
  | Interesting
  | To
  | Update
  | Messages
  | Like
  | JumpDown
  | JumpUp

```
And it seems to be working well.  I just ignore the `FilterOnly` message 
entirely in my Update and can handle `FilterOnly` messages in the filter 
with ease (while still filtering others if I want).  It makes it easy to 
add messages that are only converted to others in the filter, then just 
subscribe to `(\c -> FilterOnly (TestFiltered c))` as normal.  That way you 
do not need to even have a case for them in your main update, just for the 
FilterOnly one, which you can just `( model, Cmd.none )` once.


On Wednesday, August 10, 2016 at 11:22:47 AM UTC-6, Janis Voigtländer wrote:
>
> What will the GameMsg type look like?
> ​
>
> 2016-08-10 18:59 GMT+02:00 OvermindDL1 >:
>
>> > If there are alternatives *with currently available functions* to my 
>> proposal, very interested to hear it in this thread.
>>
>> That is why I looked at more options and started thinking about how it 
>> could also solve other filtering issues that I have, so a singular thing 
>> that could solve it all would be nice.  :-)
>>
>>
>> Given code from the dontfall game, the current top-post suggestion was to 
>> change subscriptions to be:
>> ```elm
>>
>> subscriptions : GameData -> Sub GameMsgsubscriptions d =
>> Sub.batch
>> ([ Keyboard.downsSelectively (\c -> if Char.fromCode c == 'P' then 
>> Just PauseToogle else Nothing) ] ++
>> if d.state == Running then
>> [ AnimationFrame.diffs Tick
>> , Keyboard.downsSelectively (\c -> if Char.fromCode c == ' ' 
>> then Just JumpDown else Nothing)
>> , Keyboard.upsSelectively (\c -> if Char.fromCode c == ' ' 
>> then Just JumpUp else Nothing)
>> ]
>> else
>> [])
>>
>> ```
>>
>> In the thing I proposed that can handle generic message filtering (not 
>> just subscription) would turn the above back into a fairly normal and 
>> readable style of:
>> ```elm
>>
>> subscriptions : GameData -> Sub GameMsgsubscriptions d =
>> Sub.batch
>>   [ Keyboard.downs HandleKeyboardDown
>>   , Keyboard.ups HandleKeyboardUps
>>   , if d.state == Running then AnimationFrame.diffs Tick else Sub.none
>>   ]
>>
>> ```
>> And a new callback (added in the main where init/update/etc are, in my 
>> package is called 'filters') would be something like this, this is a very 
>> simple example and `filters` can do a lot more, but for simple keyboard 
>> filtering:
>> ```elm
>>
>> filters : Msg -> Model -> ( Msg, States Model Msg )filters msg model =
>>   if model.state == Running then
>> case msg of
>> HandleKeyboardDown c ->
>> case Char.fromCode c ->
>> 'P' -> ( PauseToggle, States.enableAll )
>> ' ' -> ( JumpDown, States.enableAll )
>> _ -> ( msg, States.disableAll )
>> HandleKeyboardUp c ->
>> case Char.fromCode c ->
>> ' ' -> ( JumpUp, States.enableAll )
>> _ -> ( msg, States.disableAll )
>> _ -> ( msg, States.enableAll )
>>   else
>>   ( msg, States.enableAll )
>>
>> ```
>> You could also delegate to other TEA-style modules.  You could filter out 
>> the Tick here instead of subscribing and unsubscribing (I like a simple 
>> 'subscriptions' callback).  Anything with `States.disableAll` will disable 
>> all callbacks for that msg, so update will not be called, subscriptions 
>> will not be called, and view will not be called (it returns the cached 
>> values from last time so an exact match test of === in javascript shows 
>> they are identical and thus Elm will do nothing).
>>
>> With the above `filters` you will not ever get 
>> HandleKeyboardDown/HandleKeyboardUp in your `update` at all, ever, it is 
>> either translated to another message or entirely canceled.  Adding more 
>> message conversions is as simple as adding another case, so you could add, 
>> say a shooting state with like:
>> ```elm
>>
>> filters : Msg -> Model -> ( Msg, States Model Msg )filters msg model =
>>   if model.state == Running then
>> case msg of
>> HandleKeyboardDown c ->
>> case Char.fromCode c ->
>> 'P' -> ( PauseToggle, States.enableAll )
>> ' ' -> ( JumpDown, States.enableAll )
>> 'z' -> ( StartShooting, States.enableAll )
>> _ -> ( msg, States.disableAll )
>> HandleKeyboardUp c ->
>> case Char.fromCode c ->
>> ' ' -> ( JumpUp, States.enableAll )
>> 'z' -> ( StopShooting, States.enableAll )
>> _ -> ( msg, States.disableAll )
>> _ -> ( msg, States

Re: [elm-discuss] Re: about the Keyboard API

[Janis Voigtländer]

What will the GameMsg type look like?
​

2016-08-10 18:59 GMT+02:00 OvermindDL1 :

> > If there are alternatives *with currently available functions* to my
> proposal, very interested to hear it in this thread.
>
> That is why I looked at more options and started thinking about how it
> could also solve other filtering issues that I have, so a singular thing
> that could solve it all would be nice.  :-)
>
>
> Given code from the dontfall game, the current top-post suggestion was to
> change subscriptions to be:
> ```elm
>
> subscriptions : GameData -> Sub GameMsgsubscriptions d =
> Sub.batch
> ([ Keyboard.downsSelectively (\c -> if Char.fromCode c == 'P' then 
> Just PauseToogle else Nothing) ] ++
> if d.state == Running then
> [ AnimationFrame.diffs Tick
> , Keyboard.downsSelectively (\c -> if Char.fromCode c == ' ' 
> then Just JumpDown else Nothing)
> , Keyboard.upsSelectively (\c -> if Char.fromCode c == ' ' 
> then Just JumpUp else Nothing)
> ]
> else
> [])
>
> ```
>
> In the thing I proposed that can handle generic message filtering (not
> just subscription) would turn the above back into a fairly normal and
> readable style of:
> ```elm
>
> subscriptions : GameData -> Sub GameMsgsubscriptions d =
> Sub.batch
>   [ Keyboard.downs HandleKeyboardDown
>   , Keyboard.ups HandleKeyboardUps
>   , if d.state == Running then AnimationFrame.diffs Tick else Sub.none
>   ]
>
> ```
> And a new callback (added in the main where init/update/etc are, in my
> package is called 'filters') would be something like this, this is a very
> simple example and `filters` can do a lot more, but for simple keyboard
> filtering:
> ```elm
>
> filters : Msg -> Model -> ( Msg, States Model Msg )filters msg model =
>   if model.state == Running then
> case msg of
> HandleKeyboardDown c ->
> case Char.fromCode c ->
> 'P' -> ( PauseToggle, States.enableAll )
> ' ' -> ( JumpDown, States.enableAll )
> _ -> ( msg, States.disableAll )
> HandleKeyboardUp c ->
> case Char.fromCode c ->
> ' ' -> ( JumpUp, States.enableAll )
> _ -> ( msg, States.disableAll )
> _ -> ( msg, States.enableAll )
>   else
>   ( msg, States.enableAll )
>
> ```
> You could also delegate to other TEA-style modules.  You could filter out
> the Tick here instead of subscribing and unsubscribing (I like a simple
> 'subscriptions' callback).  Anything with `States.disableAll` will disable
> all callbacks for that msg, so update will not be called, subscriptions
> will not be called, and view will not be called (it returns the cached
> values from last time so an exact match test of === in javascript shows
> they are identical and thus Elm will do nothing).
>
> With the above `filters` you will not ever get 
> HandleKeyboardDown/HandleKeyboardUp
> in your `update` at all, ever, it is either translated to another message
> or entirely canceled.  Adding more message conversions is as simple as
> adding another case, so you could add, say a shooting state with like:
> ```elm
>
> filters : Msg -> Model -> ( Msg, States Model Msg )filters msg model =
>   if model.state == Running then
> case msg of
> HandleKeyboardDown c ->
> case Char.fromCode c ->
> 'P' -> ( PauseToggle, States.enableAll )
> ' ' -> ( JumpDown, States.enableAll )
> 'z' -> ( StartShooting, States.enableAll )
> _ -> ( msg, States.disableAll )
> HandleKeyboardUp c ->
> case Char.fromCode c ->
> ' ' -> ( JumpUp, States.enableAll )
> 'z' -> ( StopShooting, States.enableAll )
> _ -> ( msg, States.disableAll )
> _ -> ( msg, States.enableAll )
>   else
>   ( msg, States.enableAll )
>
> ```
>
> Just as simple as adding a readable case to each the down and up to send
> the two StartShooting/StopShooting messages.  You could easily pull values
> from the model if the user can remap their keys and just do if's instead
> too.
>
> But yes, the filtering of messages is done in one and only area, and if
> you filter everything well then your update does not even need to become a
> mess of nested case's for the various states and such but you know that you
> will only get a message when it is actually valid for your state, so you
> know that you will not get a, say, `JumpUp` message unless you are in the
> `Running` state, so you do not even need to check that.  Your operations
> become simple and direct.
>
>
> On Wednesday, August 10, 2016 at 10:27:42 AM UTC-6, Janis Voigtländer
> wrote:
>>
>> Generally, Nick is right, I primarily want to hear feedback about the
>> specific API proposal I made.
>>
>> However, I wrote the other day that "If there are alternatives *with
>> currently available fu

Re: [elm-discuss] Re: about the Keyboard API

[OvermindDL1]

For note, if you want to not get HandleKeyPress messages ever it should 
actually be:
```elm

filters : Msg -> Model -> ( Msg, States Model Msg )filters msg model =
  if model.state == Running then
case msg of
HandleKeyboardDown c ->
case Char.fromCode c ->
'P' -> ( PauseToggle, States.enableAll )
' ' -> ( JumpDown, States.enableAll )
'z' -> ( StartShooting, States.enableAll )
_ -> ( msg, States.disableAll )
HandleKeyboardUp c ->
case Char.fromCode c ->
' ' -> ( JumpUp, States.enableAll )
'z' -> ( StopShooting, States.enableAll )
_ -> ( msg, States.disableAll )
_ -> ( msg, States.enableAll )
  else
  case msg of
HandleKeyboardUp _ -> ( msg, States.disableAll )
HandleKeyboardDown _ -> ( msg, States.disableAll )
_ -> ( msg, States.enableAll )

```

Though if you are never handling HandleKeyboardUp/Down in your update it 
does not matter anyway.

On Wednesday, August 10, 2016 at 10:59:40 AM UTC-6, OvermindDL1 wrote:
>
> > If there are alternatives *with currently available functions* to my 
> proposal, very interested to hear it in this thread.
>
> That is why I looked at more options and started thinking about how it 
> could also solve other filtering issues that I have, so a singular thing 
> that could solve it all would be nice.  :-)
>
>
> Given code from the dontfall game, the current top-post suggestion was to 
> change subscriptions to be:
> ```elm
>
> subscriptions : GameData -> Sub GameMsgsubscriptions d =
> Sub.batch
> ([ Keyboard.downsSelectively (\c -> if Char.fromCode c == 'P' then 
> Just PauseToogle else Nothing) ] ++
> if d.state == Running then
> [ AnimationFrame.diffs Tick
> , Keyboard.downsSelectively (\c -> if Char.fromCode c == ' ' 
> then Just JumpDown else Nothing)
> , Keyboard.upsSelectively (\c -> if Char.fromCode c == ' ' 
> then Just JumpUp else Nothing)
> ]
> else
> [])
>
> ```
>
> In the thing I proposed that can handle generic message filtering (not 
> just subscription) would turn the above back into a fairly normal and 
> readable style of:
> ```elm
>
> subscriptions : GameData -> Sub GameMsgsubscriptions d =
> Sub.batch
>   [ Keyboard.downs HandleKeyboardDown
>   , Keyboard.ups HandleKeyboardUps
>   , if d.state == Running then AnimationFrame.diffs Tick else Sub.none
>   ]
>
> ```
> And a new callback (added in the main where init/update/etc are, in my 
> package is called 'filters') would be something like this, this is a very 
> simple example and `filters` can do a lot more, but for simple keyboard 
> filtering:
> ```elm
>
> filters : Msg -> Model -> ( Msg, States Model Msg )filters msg model =
>   if model.state == Running then
> case msg of
> HandleKeyboardDown c ->
> case Char.fromCode c ->
> 'P' -> ( PauseToggle, States.enableAll )
> ' ' -> ( JumpDown, States.enableAll )
> _ -> ( msg, States.disableAll )
> HandleKeyboardUp c ->
> case Char.fromCode c ->
> ' ' -> ( JumpUp, States.enableAll )
> _ -> ( msg, States.disableAll )
> _ -> ( msg, States.enableAll )
>   else
>   ( msg, States.enableAll )
>
> ```
> You could also delegate to other TEA-style modules.  You could filter out 
> the Tick here instead of subscribing and unsubscribing (I like a simple 
> 'subscriptions' callback).  Anything with `States.disableAll` will disable 
> all callbacks for that msg, so update will not be called, subscriptions 
> will not be called, and view will not be called (it returns the cached 
> values from last time so an exact match test of === in javascript shows 
> they are identical and thus Elm will do nothing).
>
> With the above `filters` you will not ever get 
> HandleKeyboardDown/HandleKeyboardUp in your `update` at all, ever, it is 
> either translated to another message or entirely canceled.  Adding more 
> message conversions is as simple as adding another case, so you could add, 
> say a shooting state with like:
> ```elm
>
> filters : Msg -> Model -> ( Msg, States Model Msg )filters msg model =
>   if model.state == Running then
> case msg of
> HandleKeyboardDown c ->
> case Charhttps://groups.google.com/d/optout.

Re: [elm-discuss] Re: about the Keyboard API

[Janis Voigtländer]

Generally, Nick is right, I primarily want to hear feedback about the
specific API proposal I made.

However, I wrote the other day that "If there are alternatives *with
currently available functions* to my proposal, very interested to hear it
in this thread."

So since Overmind seems to since have released some package/functions that
are now available, it could be on-topic to see how/whether these do address
points I try to address with the API proposal. Hence my questions (or
"challenge" if you wish) in the previous message.


2016-08-10 18:13 GMT+02:00 Nick H :

> That is not what this discussion is about. Janis proposed a change to the
> Keyboard API. The reason he started this thread was to get our thoughts on
> his proposal.
>
> On Wed, Aug 10, 2016 at 8:37 AM, OvermindDL1 
> wrote:
>
>> How is it off-topic considering its whole purpose is to handle this exact
>> kind of issue?  The discussion is about filtering messages, potentially
>> translating them to a a better message that is for a specific purpose
>> without needing to worry about checking for valid input in update area.  It
>> is handled generically.
>>
>>
>> On Wednesday, August 10, 2016 at 8:44:12 AM UTC-6, Nick H wrote:
>>>
>>> Overmind, we can all see the thread that you started. It is still
>>> off-topic for you to bring it up here.
>>>
>>> On Wed, Aug 10, 2016 at 7:40 AM, OvermindDL1  wrote:
>>>
 Well for what it is worth I made a library that can filter messages
 before they are handled, so you could, for example, turn a keypress of 'w'
 into a message of 'GoForward' and 's' into 'GoBackward' or whatever.  And
 if you cancel a message then it becomes entirely unhandled and you will
 never even see it appear in the event loop (update/subscription/view).  If
 your convert a message then you never see the original, only your converted
 one.  I am curious if anyone wants to test it with these issues as I think
 it would work very well as a, for example, key remapper.  It is a
 nice-central place to put key mapping (since it has a model you could even
 setup a dynamic key mapper based on user settings with ease).  Cleans up
 code in update as since you can expect to only receive valid messages if
 you filter them here first, vastly cleans up code there to only the actual
 work.  The package is up at the elm package website (ProgramEx I think I
 named it).  Still very in testing but it seems to be working utterly
 perfect in one of my big apps and has already cleaned up a lot of code.
 Here is how the filter code looks (this one 'delegates' to two different
 TEA-form libraries their messages and alters a Scroll event just like you'd
 expect to do with key remapping):

 ```elm

 filters : Msg -> Model -> ( Msg, States Model Msg )filters msg model =
 let
 log =
 debug_log (model.programFlags.debug_log |> Maybe.withDefault 
 False) "filters" ( msg, model )
 in
 case msg of
 Helpers helpersMsg ->
 ( msg
 , States.enableAll |> States.delegate (helpers_delegate 
 Helpers helpersMsg)
 )

 Mdl mdlMsg ->
 ( msg
 , States.enableAll
 |> States.delegate
 { key = "Mdl"
 , update = Just (\_ o -> Material.update mdlMsg o)
 , subscriptions = Just (\o -> 
 Material.subscriptions Mdl o)
 }
 )


 MesgList_Scroll scrolled ->
 case model.loc of
 RoomLocation rid _ ->
 let
 doLoad : Bool
 doLoad =
 (model.firstMessageReached == False)
 && (scrolled.pos < 16)
 && (model.isLoadingOlder == False)

 && ((Dict.size model.active_room_msgs) 
 >= 10)

 in
 if doLoad then
 ( MesgList_LoadOlder rid, States.enableAll 
 )
 else
 ( msg, States.disableAll )

 _ ->
 ( msg, States.disableAll )


 _ ->
 ( msg, States.enableAll )

 ```

 On Tuesday, August 9, 2016 at 10:55:43 PM UTC-6, Nick H wrote:
>
> This would be a really nice improvement. I doubt there is anybody
> using the keyboard API who wants to capture every key press. (But would
> love to see a counter-example!) Typing is handled by the HTML library
>
> O

Re: [elm-discuss] Re: about the Keyboard API

[Janis Voigtländer]

My opening post discussed the API proposal here in the context of several
pieces of very concrete code using Keyboard (written as student projects
not for the purpose of showing a particular point about Elm, but to simply
get stuff done).

Please take one of them, preferably the one I elaborated on at some length
in that message, https://github.com/arpad-m/dontfall. In the message I
showed which code in that project would be affected by the proposed API
change, and how the new code would look. Can you show how your proposal
would affect that project? Which functions would be changed in what way?
Then we could see whether your proposal addresses the points that I try to
address (and mentioned as such) with my proposal.
​

2016-08-10 17:37 GMT+02:00 OvermindDL1 :

> How is it off-topic considering its whole purpose is to handle this exact
> kind of issue?  The discussion is about filtering messages, potentially
> translating them to a a better message that is for a specific purpose
> without needing to worry about checking for valid input in update area.  It
> is handled generically.
>
>
> On Wednesday, August 10, 2016 at 8:44:12 AM UTC-6, Nick H wrote:
>>
>> Overmind, we can all see the thread that you started. It is still
>> off-topic for you to bring it up here.
>>
>> On Wed, Aug 10, 2016 at 7:40 AM, OvermindDL1  wrote:
>>
>>> Well for what it is worth I made a library that can filter messages
>>> before they are handled, so you could, for example, turn a keypress of 'w'
>>> into a message of 'GoForward' and 's' into 'GoBackward' or whatever.  And
>>> if you cancel a message then it becomes entirely unhandled and you will
>>> never even see it appear in the event loop (update/subscription/view).  If
>>> your convert a message then you never see the original, only your converted
>>> one.  I am curious if anyone wants to test it with these issues as I think
>>> it would work very well as a, for example, key remapper.  It is a
>>> nice-central place to put key mapping (since it has a model you could even
>>> setup a dynamic key mapper based on user settings with ease).  Cleans up
>>> code in update as since you can expect to only receive valid messages if
>>> you filter them here first, vastly cleans up code there to only the actual
>>> work.  The package is up at the elm package website (ProgramEx I think I
>>> named it).  Still very in testing but it seems to be working utterly
>>> perfect in one of my big apps and has already cleaned up a lot of code.
>>> Here is how the filter code looks (this one 'delegates' to two different
>>> TEA-form libraries their messages and alters a Scroll event just like you'd
>>> expect to do with key remapping):
>>>
>>> ```elm
>>>
>>> filters : Msg -> Model -> ( Msg, States Model Msg )filters msg model =
>>> let
>>> log =
>>> debug_log (model.programFlags.debug_log |> Maybe.withDefault 
>>> False) "filters" ( msg, model )
>>> in
>>> case msg of
>>> Helpers helpersMsg ->
>>> ( msg
>>> , States.enableAll |> States.delegate (helpers_delegate 
>>> Helpers helpersMsg)
>>> )
>>>
>>> Mdl mdlMsg ->
>>> ( msg
>>> , States.enableAll
>>> |> States.delegate
>>> { key = "Mdl"
>>> , update = Just (\_ o -> Material.update mdlMsg o)
>>> , subscriptions = Just (\o -> 
>>> Material.subscriptions Mdl o)
>>> }
>>> )
>>>
>>>
>>> MesgList_Scroll scrolled ->
>>> case model.loc of
>>> RoomLocation rid _ ->
>>> let
>>> doLoad : Bool
>>> doLoad =
>>> (model.firstMessageReached == False)
>>> && (scrolled.pos < 16)
>>> && (model.isLoadingOlder == False)
>>>
>>> && ((Dict.size model.active_room_msgs) 
>>> >= 10)
>>>
>>> in
>>> if doLoad then
>>> ( MesgList_LoadOlder rid, States.enableAll )
>>> else
>>> ( msg, States.disableAll )
>>>
>>> _ ->
>>> ( msg, States.disableAll )
>>>
>>>
>>> _ ->
>>> ( msg, States.enableAll )
>>>
>>> ```
>>>
>>> On Tuesday, August 9, 2016 at 10:55:43 PM UTC-6, Nick H wrote:

 This would be a really nice improvement. I doubt there is anybody using
 the keyboard API who wants to capture every key press. (But would love to
 see a counter-example!) Typing is handled by the HTML library

 On Mon, Aug 8, 2016 at 11:01 PM, Janis Voigtländer <
 janis.voi...@gmail.com> wrote:

> To up the proposal, here a revi

Re: [elm-discuss] Re: about the Keyboard API

[Nick H]

That is not what this discussion is about. Janis proposed a change to the
Keyboard API. The reason he started this thread was to get our thoughts on
his proposal.

On Wed, Aug 10, 2016 at 8:37 AM, OvermindDL1  wrote:

> How is it off-topic considering its whole purpose is to handle this exact
> kind of issue?  The discussion is about filtering messages, potentially
> translating them to a a better message that is for a specific purpose
> without needing to worry about checking for valid input in update area.  It
> is handled generically.
>
>
> On Wednesday, August 10, 2016 at 8:44:12 AM UTC-6, Nick H wrote:
>>
>> Overmind, we can all see the thread that you started. It is still
>> off-topic for you to bring it up here.
>>
>> On Wed, Aug 10, 2016 at 7:40 AM, OvermindDL1  wrote:
>>
>>> Well for what it is worth I made a library that can filter messages
>>> before they are handled, so you could, for example, turn a keypress of 'w'
>>> into a message of 'GoForward' and 's' into 'GoBackward' or whatever.  And
>>> if you cancel a message then it becomes entirely unhandled and you will
>>> never even see it appear in the event loop (update/subscription/view).  If
>>> your convert a message then you never see the original, only your converted
>>> one.  I am curious if anyone wants to test it with these issues as I think
>>> it would work very well as a, for example, key remapper.  It is a
>>> nice-central place to put key mapping (since it has a model you could even
>>> setup a dynamic key mapper based on user settings with ease).  Cleans up
>>> code in update as since you can expect to only receive valid messages if
>>> you filter them here first, vastly cleans up code there to only the actual
>>> work.  The package is up at the elm package website (ProgramEx I think I
>>> named it).  Still very in testing but it seems to be working utterly
>>> perfect in one of my big apps and has already cleaned up a lot of code.
>>> Here is how the filter code looks (this one 'delegates' to two different
>>> TEA-form libraries their messages and alters a Scroll event just like you'd
>>> expect to do with key remapping):
>>>
>>> ```elm
>>>
>>> filters : Msg -> Model -> ( Msg, States Model Msg )filters msg model =
>>> let
>>> log =
>>> debug_log (model.programFlags.debug_log |> Maybe.withDefault 
>>> False) "filters" ( msg, model )
>>> in
>>> case msg of
>>> Helpers helpersMsg ->
>>> ( msg
>>> , States.enableAll |> States.delegate (helpers_delegate 
>>> Helpers helpersMsg)
>>> )
>>>
>>> Mdl mdlMsg ->
>>> ( msg
>>> , States.enableAll
>>> |> States.delegate
>>> { key = "Mdl"
>>> , update = Just (\_ o -> Material.update mdlMsg o)
>>> , subscriptions = Just (\o -> 
>>> Material.subscriptions Mdl o)
>>> }
>>> )
>>>
>>>
>>> MesgList_Scroll scrolled ->
>>> case model.loc of
>>> RoomLocation rid _ ->
>>> let
>>> doLoad : Bool
>>> doLoad =
>>> (model.firstMessageReached == False)
>>> && (scrolled.pos < 16)
>>> && (model.isLoadingOlder == False)
>>>
>>> && ((Dict.size model.active_room_msgs) 
>>> >= 10)
>>>
>>> in
>>> if doLoad then
>>> ( MesgList_LoadOlder rid, States.enableAll )
>>> else
>>> ( msg, States.disableAll )
>>>
>>> _ ->
>>> ( msg, States.disableAll )
>>>
>>>
>>> _ ->
>>> ( msg, States.enableAll )
>>>
>>> ```
>>>
>>> On Tuesday, August 9, 2016 at 10:55:43 PM UTC-6, Nick H wrote:

 This would be a really nice improvement. I doubt there is anybody using
 the keyboard API who wants to capture every key press. (But would love to
 see a counter-example!) Typing is handled by the HTML library

 On Mon, Aug 8, 2016 at 11:01 PM, Janis Voigtländer <
 janis.voi...@gmail.com> wrote:

> To up the proposal, here a revision.
>
> Instead of proposing to *add* new functions, I now propose to
> *replace*
>
> Keyboard.presses : (KeyCode -> msg) -> Sub msgKeyboard.downs : (KeyCode 
> -> msg) -> Sub msgKeyboard.ups : (KeyCode -> msg) -> Sub msg
>
> by
>
> Keyboard.presses : (KeyCode -> Maybe msg) -> Sub msgKeyboard.downs : 
> (KeyCode -> Maybe msg) -> Sub msgKeyboard.ups : (KeyCode -> Maybe msg) -> 
> Sub msg
>
> It would still be easy to recover the old behavior if wanted in a
> specific situation, by throwing

Re: [elm-discuss] Re: about the Keyboard API

[OvermindDL1]

How is it off-topic considering its whole purpose is to handle this exact 
kind of issue?  The discussion is about filtering messages, potentially 
translating them to a a better message that is for a specific purpose 
without needing to worry about checking for valid input in update area.  It 
is handled generically.


On Wednesday, August 10, 2016 at 8:44:12 AM UTC-6, Nick H wrote:
>
> Overmind, we can all see the thread that you started. It is still 
> off-topic for you to bring it up here.
>
> On Wed, Aug 10, 2016 at 7:40 AM, OvermindDL1  > wrote:
>
>> Well for what it is worth I made a library that can filter messages 
>> before they are handled, so you could, for example, turn a keypress of 'w' 
>> into a message of 'GoForward' and 's' into 'GoBackward' or whatever.  And 
>> if you cancel a message then it becomes entirely unhandled and you will 
>> never even see it appear in the event loop (update/subscription/view).  If 
>> your convert a message then you never see the original, only your converted 
>> one.  I am curious if anyone wants to test it with these issues as I think 
>> it would work very well as a, for example, key remapper.  It is a 
>> nice-central place to put key mapping (since it has a model you could even 
>> setup a dynamic key mapper based on user settings with ease).  Cleans up 
>> code in update as since you can expect to only receive valid messages if 
>> you filter them here first, vastly cleans up code there to only the actual 
>> work.  The package is up at the elm package website (ProgramEx I think I 
>> named it).  Still very in testing but it seems to be working utterly 
>> perfect in one of my big apps and has already cleaned up a lot of code.  
>> Here is how the filter code looks (this one 'delegates' to two different 
>> TEA-form libraries their messages and alters a Scroll event just like you'd 
>> expect to do with key remapping):
>>
>> ```elm
>>
>> filters : Msg -> Model -> ( Msg, States Model Msg )filters msg model =
>> let
>> log =
>> debug_log (model.programFlags.debug_log |> Maybe.withDefault 
>> False) "filters" ( msg, model )
>> in
>> case msg of
>> Helpers helpersMsg ->
>> ( msg
>> , States.enableAll |> States.delegate (helpers_delegate 
>> Helpers helpersMsg)
>> )
>>
>> Mdl mdlMsg ->
>> ( msg
>> , States.enableAll
>> |> States.delegate
>> { key = "Mdl"
>> , update = Just (\_ o -> Material.update mdlMsg o)
>> , subscriptions = Just (\o -> Material.subscriptions 
>> Mdl o)
>> }
>> )
>>
>>
>> MesgList_Scroll scrolled ->
>> case model.loc of
>> RoomLocation rid _ ->
>> let
>> doLoad : Bool
>> doLoad =
>> (model.firstMessageReached == False)
>> && (scrolled.pos < 16)
>> && (model.isLoadingOlder == False)
>>
>> && ((Dict.size model.active_room_msgs) 
>> >= 10)
>>
>> in
>> if doLoad then
>> ( MesgList_LoadOlder rid, States.enableAll )
>> else
>> ( msg, States.disableAll )
>>
>> _ ->
>> ( msg, States.disableAll )
>>
>>
>> _ ->
>> ( msg, States.enableAll )
>>
>> ```
>>
>> On Tuesday, August 9, 2016 at 10:55:43 PM UTC-6, Nick H wrote:
>>>
>>> This would be a really nice improvement. I doubt there is anybody using 
>>> the keyboard API who wants to capture every key press. (But would love to 
>>> see a counter-example!) Typing is handled by the HTML library
>>>
>>> On Mon, Aug 8, 2016 at 11:01 PM, Janis Voigtländer <
>>> janis.voi...@gmail.com> wrote:
>>>
 To up the proposal, here a revision.

 Instead of proposing to *add* new functions, I now propose to *replace*

 Keyboard.presses : (KeyCode -> msg) -> Sub msgKeyboard.downs : (KeyCode -> 
 msg) -> Sub msgKeyboard.ups : (KeyCode -> msg) -> Sub msg

 by

 Keyboard.presses : (KeyCode -> Maybe msg) -> Sub msgKeyboard.downs : 
 (KeyCode -> Maybe msg) -> Sub msgKeyboard.ups : (KeyCode -> Maybe msg) -> 
 Sub msg

 It would still be easy to recover the old behavior if wanted in a 
 specific situation, by throwing in Just. But actually I posit that one 
 almost never really wants to capture all keys. Usually, one wants to be 
 selective. That selectiveness has to be expressed somewhere, and doing it 
 with the Maybe type that is designed for such purpose is generally 
 better than going for something like 

Re: [elm-discuss] Re: about the Keyboard API

[Nick H]

Overmind, we can all see the thread that you started. It is still off-topic
for you to bring it up here.

On Wed, Aug 10, 2016 at 7:40 AM, OvermindDL1  wrote:

> Well for what it is worth I made a library that can filter messages before
> they are handled, so you could, for example, turn a keypress of 'w' into a
> message of 'GoForward' and 's' into 'GoBackward' or whatever.  And if you
> cancel a message then it becomes entirely unhandled and you will never even
> see it appear in the event loop (update/subscription/view).  If your
> convert a message then you never see the original, only your converted
> one.  I am curious if anyone wants to test it with these issues as I think
> it would work very well as a, for example, key remapper.  It is a
> nice-central place to put key mapping (since it has a model you could even
> setup a dynamic key mapper based on user settings with ease).  Cleans up
> code in update as since you can expect to only receive valid messages if
> you filter them here first, vastly cleans up code there to only the actual
> work.  The package is up at the elm package website (ProgramEx I think I
> named it).  Still very in testing but it seems to be working utterly
> perfect in one of my big apps and has already cleaned up a lot of code.
> Here is how the filter code looks (this one 'delegates' to two different
> TEA-form libraries their messages and alters a Scroll event just like you'd
> expect to do with key remapping):
>
> ```elm
>
> filters : Msg -> Model -> ( Msg, States Model Msg )filters msg model =
> let
> log =
> debug_log (model.programFlags.debug_log |> Maybe.withDefault 
> False) "filters" ( msg, model )
> in
> case msg of
> Helpers helpersMsg ->
> ( msg
> , States.enableAll |> States.delegate (helpers_delegate 
> Helpers helpersMsg)
> )
>
> Mdl mdlMsg ->
> ( msg
> , States.enableAll
> |> States.delegate
> { key = "Mdl"
> , update = Just (\_ o -> Material.update mdlMsg o)
> , subscriptions = Just (\o -> Material.subscriptions 
> Mdl o)
> }
> )
>
>
> MesgList_Scroll scrolled ->
> case model.loc of
> RoomLocation rid _ ->
> let
> doLoad : Bool
> doLoad =
> (model.firstMessageReached == False)
> && (scrolled.pos < 16)
> && (model.isLoadingOlder == False)
>
> && ((Dict.size model.active_room_msgs) >= 
> 10)
>
> in
> if doLoad then
> ( MesgList_LoadOlder rid, States.enableAll )
> else
> ( msg, States.disableAll )
>
> _ ->
> ( msg, States.disableAll )
>
>
> _ ->
> ( msg, States.enableAll )
>
> ```
>
> On Tuesday, August 9, 2016 at 10:55:43 PM UTC-6, Nick H wrote:
>>
>> This would be a really nice improvement. I doubt there is anybody using
>> the keyboard API who wants to capture every key press. (But would love to
>> see a counter-example!) Typing is handled by the HTML library
>>
>> On Mon, Aug 8, 2016 at 11:01 PM, Janis Voigtländer <
>> janis.voi...@gmail.com> wrote:
>>
>>> To up the proposal, here a revision.
>>>
>>> Instead of proposing to *add* new functions, I now propose to *replace*
>>>
>>> Keyboard.presses : (KeyCode -> msg) -> Sub msgKeyboard.downs : (KeyCode -> 
>>> msg) -> Sub msgKeyboard.ups : (KeyCode -> msg) -> Sub msg
>>>
>>> by
>>>
>>> Keyboard.presses : (KeyCode -> Maybe msg) -> Sub msgKeyboard.downs : 
>>> (KeyCode -> Maybe msg) -> Sub msgKeyboard.ups : (KeyCode -> Maybe msg) -> 
>>> Sub msg
>>>
>>> It would still be easy to recover the old behavior if wanted in a
>>> specific situation, by throwing in Just. But actually I posit that one
>>> almost never really wants to capture all keys. Usually, one wants to be
>>> selective. That selectiveness has to be expressed somewhere, and doing it
>>> with the Maybe type that is designed for such purpose is generally
>>> better than going for something like extra NoOp or NothingHappened or
>>> NotBound constructors that then need to be handled in a special way in
>>> the app’s update logic, without help from the type system. Making
>>> consideration of the selectiveness part of the modelling up front would
>>> lead to better design. That’s at least the case in the
>>> projects/repositories I have pointed to.
>>> ​
>>>
>>> 2016-08-08 14:48 GMT+02:00 Janis Voigtländer :
>>>
 A while back there was a thread
 

Re: [elm-discuss] Re: about the Keyboard API

[OvermindDL1]

Well for what it is worth I made a library that can filter messages before 
they are handled, so you could, for example, turn a keypress of 'w' into a 
message of 'GoForward' and 's' into 'GoBackward' or whatever.  And if you 
cancel a message then it becomes entirely unhandled and you will never even 
see it appear in the event loop (update/subscription/view).  If your 
convert a message then you never see the original, only your converted one. 
 I am curious if anyone wants to test it with these issues as I think it 
would work very well as a, for example, key remapper.  It is a nice-central 
place to put key mapping (since it has a model you could even setup a 
dynamic key mapper based on user settings with ease).  Cleans up code in 
update as since you can expect to only receive valid messages if you filter 
them here first, vastly cleans up code there to only the actual work.  The 
package is up at the elm package website (ProgramEx I think I named it). 
 Still very in testing but it seems to be working utterly perfect in one of 
my big apps and has already cleaned up a lot of code.  Here is how the 
filter code looks (this one 'delegates' to two different TEA-form libraries 
their messages and alters a Scroll event just like you'd expect to do with 
key remapping):

```elm

filters : Msg -> Model -> ( Msg, States Model Msg )filters msg model =
let
log =
debug_log (model.programFlags.debug_log |> Maybe.withDefault False) 
"filters" ( msg, model )
in
case msg of
Helpers helpersMsg ->
( msg
, States.enableAll |> States.delegate (helpers_delegate Helpers 
helpersMsg)
)

Mdl mdlMsg ->
( msg
, States.enableAll
|> States.delegate
{ key = "Mdl"
, update = Just (\_ o -> Material.update mdlMsg o)
, subscriptions = Just (\o -> Material.subscriptions 
Mdl o)
}
)


MesgList_Scroll scrolled ->
case model.loc of
RoomLocation rid _ ->
let
doLoad : Bool
doLoad =
(model.firstMessageReached == False)
&& (scrolled.pos < 16)
&& (model.isLoadingOlder == False)

&& ((Dict.size model.active_room_msgs) >= 
10)

in
if doLoad then
( MesgList_LoadOlder rid, States.enableAll )
else
( msg, States.disableAll )

_ ->
( msg, States.disableAll )


_ ->
( msg, States.enableAll )

```

On Tuesday, August 9, 2016 at 10:55:43 PM UTC-6, Nick H wrote:
>
> This would be a really nice improvement. I doubt there is anybody using 
> the keyboard API who wants to capture every key press. (But would love to 
> see a counter-example!) Typing is handled by the HTML library
>
> On Mon, Aug 8, 2016 at 11:01 PM, Janis Voigtländer  > wrote:
>
>> To up the proposal, here a revision.
>>
>> Instead of proposing to *add* new functions, I now propose to *replace*
>>
>> Keyboard.presses : (KeyCode -> msg) -> Sub msgKeyboard.downs : (KeyCode -> 
>> msg) -> Sub msgKeyboard.ups : (KeyCode -> msg) -> Sub msg
>>
>> by
>>
>> Keyboard.presses : (KeyCode -> Maybe msg) -> Sub msgKeyboard.downs : 
>> (KeyCode -> Maybe msg) -> Sub msgKeyboard.ups : (KeyCode -> Maybe msg) -> 
>> Sub msg
>>
>> It would still be easy to recover the old behavior if wanted in a 
>> specific situation, by throwing in Just. But actually I posit that one 
>> almost never really wants to capture all keys. Usually, one wants to be 
>> selective. That selectiveness has to be expressed somewhere, and doing it 
>> with the Maybe type that is designed for such purpose is generally 
>> better than going for something like extra NoOp or NothingHappened or 
>> NotBound constructors that then need to be handled in a special way in 
>> the app’s update logic, without help from the type system. Making 
>> consideration of the selectiveness part of the modelling up front would 
>> lead to better design. That’s at least the case in the 
>> projects/repositories I have pointed to.
>> ​
>>
>> 2016-08-08 14:48 GMT+02:00 Janis Voigtländer > >:
>>
>>> A while back there was a thread 
>>>  
>>> about filtering subscriptions. The following is related, but can also (and 
>>> probably better) be consumed and discussed independently. For those that do 
>>> have that older thread as context in mind, the following differs in two 
>>> essential ways:
>>>
>>>- Earlier, the discussion was about generic filt

Re: [elm-discuss] Re: about the Keyboard API

[Nick H]

This would be a really nice improvement. I doubt there is anybody using the
keyboard API who wants to capture every key press. (But would love to see a
counter-example!) Typing is handled by the HTML library

On Mon, Aug 8, 2016 at 11:01 PM, Janis Voigtländer <
janis.voigtlaen...@gmail.com> wrote:

> To up the proposal, here a revision.
>
> Instead of proposing to *add* new functions, I now propose to *replace*
>
> Keyboard.presses : (KeyCode -> msg) -> Sub msgKeyboard.downs : (KeyCode -> 
> msg) -> Sub msgKeyboard.ups : (KeyCode -> msg) -> Sub msg
>
> by
>
> Keyboard.presses : (KeyCode -> Maybe msg) -> Sub msgKeyboard.downs : (KeyCode 
> -> Maybe msg) -> Sub msgKeyboard.ups : (KeyCode -> Maybe msg) -> Sub msg
>
> It would still be easy to recover the old behavior if wanted in a specific
> situation, by throwing in Just. But actually I posit that one almost
> never really wants to capture all keys. Usually, one wants to be selective.
> That selectiveness has to be expressed somewhere, and doing it with the
> Maybe type that is designed for such purpose is generally better than
> going for something like extra NoOp or NothingHappened or NotBound
> constructors that then need to be handled in a special way in the app’s
> update logic, without help from the type system. Making consideration of
> the selectiveness part of the modelling up front would lead to better
> design. That’s at least the case in the projects/repositories I have
> pointed to.
> ​
>
> 2016-08-08 14:48 GMT+02:00 Janis Voigtländer  >:
>
>> A while back there was a thread
>> 
>> about filtering subscriptions. The following is related, but can also (and
>> probably better) be consumed and discussed independently. For those that do
>> have that older thread as context in mind, the following differs in two
>> essential ways:
>>
>>- Earlier, the discussion was about generic filtering of arbitrary
>>subscriptions. The following involves no genericity whatsoever. It is only
>>a proposal about the Keyboard API specifically.
>>- The earlier thread was not rooted in practice, since very little
>>stuff had been built yet with subscriptions. In the following, I point to
>>how things have played out in practice, based on uses students have made 
>> of
>>the current API in projects.
>>
>> --
>>
>> So, on to the subject matter:
>>
>> The keyboard package
>>  currently
>> contains functions such as:
>>
>> Keyboard.downs : (KeyCode -> msg) -> Sub msg
>>
>> Common uses (I’ll point to several repositories below) are such that only
>> some keys are relevant for an application. My proposal is to have functions
>> such as:
>>
>> Keyboard.downsSelectively : (KeyCode -> Maybe msg) -> Sub msg
>>
>> where the semantics is that if a given KeyCode is mapped to Nothing by
>> the tagger, then no message gets sent along the subscription; otherwise the
>> Just is peeled off and the message gets sent.
>> --
>>
>> Let’s look at a practical case, https://github.com/arpad-m/dontfall.
>> It’s a game, where the player uses the keyboard for part of the control.
>> Important excerpts from the code are:
>>
>> The message type (in https://github.com/arpad-m/don
>> tfall/blob/master/src/BaseStuff.elm):
>>
>> type GameMsg = NothingHappened | ... several other messages ...
>>
>> The subscriptions definition (in https://github.com/arpad-m/don
>> tfall/blob/master/src/main.elm):
>>
>> subscriptions : GameData -> Sub GameMsgsubscriptions d =
>> Sub.batch
>> ([ Keyboard.downs (\c -> if Char.fromCode c == 'P' then PauseToogle 
>> else NothingHappened) ] ++
>> if d.state == Running then
>> [ AnimationFrame.diffs Tick
>> , Keyboard.downs (\c -> if Char.fromCode c == ' ' then 
>> JumpDown else NothingHappened)
>> , Keyboard.ups (\c -> if Char.fromCode c == ' ' then JumpUp 
>> else NothingHappened)
>> ]
>> else
>> [])
>>
>> The main case distinction in the main update function (in
>> https://github.com/arpad-m/dontfall/blob/master/src/main.elm):
>>
>> updateScene : GameMsg -> GameData -> (GameData, Cmd GameMsg)updateScene msg 
>> d =
>> (case d.state of
>> ...
>> Running -> case msg of
>> MouseMove (x,_) -> { d | characterPosX = min x d.flWidth}
>> Tick t -> stepTime d t
>> PauseToogle -> { d | state = Paused }
>> JumpDown -> { d | jumpPressed = True }
>> JumpUp -> { d | jumpPressed = False }
>> _ -> d
>> , Cmd.none
>> )
>>
>> Given availability of the functions I propose above, the code could
>> instead look as follows:
>>
>> type GameMsg = ... only the other messages, no NothingHappened ...
>> subscriptions : GameData -> Sub GameMsgsubscriptions d =
>> Sub.batch
>> 

[elm-discuss] Re: about the Keyboard API

[Ian Mackenzie]

I really like this version. It's effectively saying that in the same way 
that most subscriptions/HTML events take map function arguments since you'd 
otherwise almost always want to map the result yourself (using Html.App.map 
or Sub.map), the keyboard functions should take a filter-map function 
argument since you almost always want to filter and map the result. (With 
the slight wrinkle that Sub.filterMap doesn't actually exist, but that's 
getting back into the general subscription-filtering discussion...)

On Tuesday, 9 August 2016 16:01:48 UTC+10, Janis Voigtländer wrote:
>
> To up the proposal, here a revision.
>
> Instead of proposing to *add* new functions, I now propose to *replace*
>
> Keyboard.presses : (KeyCode -> msg) -> Sub msgKeyboard.downs : (KeyCode -> 
> msg) -> Sub msgKeyboard.ups : (KeyCode -> msg) -> Sub msg
>
> by
>
> Keyboard.presses : (KeyCode -> Maybe msg) -> Sub msgKeyboard.downs : (KeyCode 
> -> Maybe msg) -> Sub msgKeyboard.ups : (KeyCode -> Maybe msg) -> Sub msg
>
> It would still be easy to recover the old behavior if wanted in a specific 
> situation, by throwing in Just. But actually I posit that one almost 
> never really wants to capture all keys. Usually, one wants to be selective. 
> That selectiveness has to be expressed somewhere, and doing it with the 
> Maybe type that is designed for such purpose is generally better than 
> going for something like extra NoOp or NothingHappened or NotBound 
> constructors that then need to be handled in a special way in the app’s 
> update logic, without help from the type system. Making consideration of 
> the selectiveness part of the modelling up front would lead to better 
> design. That’s at least the case in the projects/repositories I have 
> pointed to.
> ​
>
> 2016-08-08 14:48 GMT+02:00 Janis Voigtländer  >:
>
>> A while back there was a thread 
>>  
>> about filtering subscriptions. The following is related, but can also (and 
>> probably better) be consumed and discussed independently. For those that do 
>> have that older thread as context in mind, the following differs in two 
>> essential ways:
>>
>>- Earlier, the discussion was about generic filtering of arbitrary 
>>subscriptions. The following involves no genericity whatsoever. It is 
>> only 
>>a proposal about the Keyboard API specifically. 
>>- The earlier thread was not rooted in practice, since very little 
>>stuff had been built yet with subscriptions. In the following, I point to 
>>how things have played out in practice, based on uses students have made 
>> of 
>>the current API in projects. 
>>
>> --
>>
>> So, on to the subject matter:
>>
>> The keyboard package 
>>  currently 
>> contains functions such as:
>>
>> Keyboard.downs : (KeyCode -> msg) -> Sub msg
>>
>> Common uses (I’ll point to several repositories below) are such that only 
>> some keys are relevant for an application. My proposal is to have functions 
>> such as:
>>
>> Keyboard.downsSelectively : (KeyCode -> Maybe msg) -> Sub msg
>>
>> where the semantics is that if a given KeyCode is mapped to Nothing by 
>> the tagger, then no message gets sent along the subscription; otherwise the 
>> Just is peeled off and the message gets sent.
>> --
>>
>> Let’s look at a practical case, https://github.com/arpad-m/dontfall. 
>> It’s a game, where the player uses the keyboard for part of the control. 
>> Important excerpts from the code are:
>>
>> The message type (in 
>> https://github.com/arpad-m/dontfall/blob/master/src/BaseStuff.elm):
>>
>> type GameMsg = NothingHappened | ... several other messages ...
>>
>> The subscriptions definition (in 
>> https://github.com/arpad-m/dontfall/blob/master/src/main.elm):
>>
>> subscriptions : GameData -> Sub GameMsgsubscriptions d =
>> Sub.batch
>> ([ Keyboard.downs (\c -> if Char.fromCode c == 'P' then PauseToogle 
>> else NothingHappened) ] ++
>> if d.state == Running then
>> [ AnimationFrame.diffs Tick
>> , Keyboard.downs (\c -> if Char.fromCode c == ' ' then 
>> JumpDown else NothingHappened)
>> , Keyboard.ups (\c -> if Char.fromCode c == ' ' then JumpUp 
>> else NothingHappened)
>> ]
>> else
>> [])
>>
>> The main case distinction in the main update function (in 
>> https://github.com/arpad-m/dontfall/blob/master/src/main.elm):
>>
>> updateScene : GameMsg -> GameData -> (GameData, Cmd GameMsg)updateScene msg 
>> d =
>> (case d.state of
>> ...
>> Running -> case msg of
>> MouseMove (x,_) -> { d | characterPosX = min x d.flWidth}
>> Tick t -> stepTime d t
>> PauseToogle -> { d | state = Paused }
>> JumpDown -> { d | jumpPressed = True }
>> JumpUp -> { d | jumpPres

[elm-discuss] Re: about the Keyboard API

[Janis Voigtländer]

To up the proposal, here a revision.

Instead of proposing to *add* new functions, I now propose to *replace*

Keyboard.presses : (KeyCode -> msg) -> Sub msgKeyboard.downs :
(KeyCode -> msg) -> Sub msgKeyboard.ups : (KeyCode -> msg) -> Sub msg

by

Keyboard.presses : (KeyCode -> Maybe msg) -> Sub msgKeyboard.downs :
(KeyCode -> Maybe msg) -> Sub msgKeyboard.ups : (KeyCode -> Maybe msg)
-> Sub msg

It would still be easy to recover the old behavior if wanted in a specific
situation, by throwing in Just. But actually I posit that one almost never
really wants to capture all keys. Usually, one wants to be selective. That
selectiveness has to be expressed somewhere, and doing it with the Maybe
type that is designed for such purpose is generally better than going for
something like extra NoOp or NothingHappened or NotBound constructors that
then need to be handled in a special way in the app’s update logic, without
help from the type system. Making consideration of the selectiveness part
of the modelling up front would lead to better design. That’s at least the
case in the projects/repositories I have pointed to.
​

2016-08-08 14:48 GMT+02:00 Janis Voigtländer :

> A while back there was a thread
> 
> about filtering subscriptions. The following is related, but can also (and
> probably better) be consumed and discussed independently. For those that do
> have that older thread as context in mind, the following differs in two
> essential ways:
>
>- Earlier, the discussion was about generic filtering of arbitrary
>subscriptions. The following involves no genericity whatsoever. It is only
>a proposal about the Keyboard API specifically.
>- The earlier thread was not rooted in practice, since very little
>stuff had been built yet with subscriptions. In the following, I point to
>how things have played out in practice, based on uses students have made of
>the current API in projects.
>
> --
>
> So, on to the subject matter:
>
> The keyboard package
>  currently
> contains functions such as:
>
> Keyboard.downs : (KeyCode -> msg) -> Sub msg
>
> Common uses (I’ll point to several repositories below) are such that only
> some keys are relevant for an application. My proposal is to have functions
> such as:
>
> Keyboard.downsSelectively : (KeyCode -> Maybe msg) -> Sub msg
>
> where the semantics is that if a given KeyCode is mapped to Nothing by
> the tagger, then no message gets sent along the subscription; otherwise the
> Just is peeled off and the message gets sent.
> --
>
> Let’s look at a practical case, https://github.com/arpad-m/dontfall. It’s
> a game, where the player uses the keyboard for part of the control.
> Important excerpts from the code are:
>
> The message type (in https://github.com/arpad-m/dontfall/blob/master/src/
> BaseStuff.elm):
>
> type GameMsg = NothingHappened | ... several other messages ...
>
> The subscriptions definition (in https://github.com/arpad-m/
> dontfall/blob/master/src/main.elm):
>
> subscriptions : GameData -> Sub GameMsgsubscriptions d =
> Sub.batch
> ([ Keyboard.downs (\c -> if Char.fromCode c == 'P' then PauseToogle 
> else NothingHappened) ] ++
> if d.state == Running then
> [ AnimationFrame.diffs Tick
> , Keyboard.downs (\c -> if Char.fromCode c == ' ' then 
> JumpDown else NothingHappened)
> , Keyboard.ups (\c -> if Char.fromCode c == ' ' then JumpUp 
> else NothingHappened)
> ]
> else
> [])
>
> The main case distinction in the main update function (in
> https://github.com/arpad-m/dontfall/blob/master/src/main.elm):
>
> updateScene : GameMsg -> GameData -> (GameData, Cmd GameMsg)updateScene msg d 
> =
> (case d.state of
> ...
> Running -> case msg of
> MouseMove (x,_) -> { d | characterPosX = min x d.flWidth}
> Tick t -> stepTime d t
> PauseToogle -> { d | state = Paused }
> JumpDown -> { d | jumpPressed = True }
> JumpUp -> { d | jumpPressed = False }
> _ -> d
> , Cmd.none
> )
>
> Given availability of the functions I propose above, the code could
> instead look as follows:
>
> type GameMsg = ... only the other messages, no NothingHappened ...
> subscriptions : GameData -> Sub GameMsgsubscriptions d =
> Sub.batch
> ([ Keyboard.downsSelectively (\c -> if Char.fromCode c == 'P' then 
> Just PauseToogle else Nothing) ] ++
> if d.state == Running then
> [ AnimationFrame.diffs Tick
> , Keyboard.downsSelectively (\c -> if Char.fromCode c == ' ' 
> then Just JumpDown else Nothing)
> , Keyboard.upsSelectively (\c -> if Char.fromCode c == ' ' 
> then Just JumpUp else Nothing)
> 

Re: [elm-discuss] Re: about the Keyboard API

[Janis Voigtländer]

Am I correct in thinking that this is something that would benefit everyone
who wants to handle keyboard shortcuts in Elm?

If the scenario is:

   - You already have complete message and update logic.
   - You want to capture a selected few key inputs and map them to already
   implemented actions in the app.

then yes, that would be nicer to do with the proposed new functions rather
than the existing ones, since you would not need to suddenly add a NoOp
message constructor and provide (trivial) update logic for it, and possibly
fix a number of other places in the program where case distinction on
message constructors happens. Instead, you simply map the wanted keys to
Just the relevant message constructors you already have, and all others to
Nothing, and don’t need to touch any other part of your program.
​

2016-08-09 0:14 GMT+02:00 Daniel Bachler :

> For what it's worth I like the proposal. Am I correct in thinking that
> this is something that would benefit everyone who wants to handle keyboard
> shortcuts in Elm?
>
> On Monday, August 8, 2016 at 2:49:22 PM UTC+2, Janis Voigtländer wrote:
>>
>> A while back there was a thread
>> 
>> about filtering subscriptions. The following is related, but can also (and
>> probably better) be consumed and discussed independently. For those that do
>> have that older thread as context in mind, the following differs in two
>> essential ways:
>>
>>- Earlier, the discussion was about generic filtering of arbitrary
>>subscriptions. The following involves no genericity whatsoever. It is only
>>a proposal about the Keyboard API specifically.
>>- The earlier thread was not rooted in practice, since very little
>>stuff had been built yet with subscriptions. In the following, I point to
>>how things have played out in practice, based on uses students have made 
>> of
>>the current API in projects.
>>
>> --
>>
>> So, on to the subject matter:
>>
>> The keyboard package
>>  currently
>> contains functions such as:
>>
>> Keyboard.downs : (KeyCode -> msg) -> Sub msg
>>
>> Common uses (I’ll point to several repositories below) are such that only
>> some keys are relevant for an application. My proposal is to have functions
>> such as:
>>
>> Keyboard.downsSelectively : (KeyCode -> Maybe msg) -> Sub msg
>>
>> where the semantics is that if a given KeyCode is mapped to Nothing by
>> the tagger, then no message gets sent along the subscription; otherwise the
>> Just is peeled off and the message gets sent.
>> --
>>
>> Let’s look at a practical case, https://github.com/arpad-m/dontfall.
>> It’s a game, where the player uses the keyboard for part of the control.
>> Important excerpts from the code are:
>>
>> The message type (in https://github.com/arpad-m/don
>> tfall/blob/master/src/BaseStuff.elm):
>>
>> type GameMsg = NothingHappened | ... several other messages ...
>>
>> The subscriptions definition (in https://github.com/arpad-m/don
>> tfall/blob/master/src/main.elm):
>>
>> subscriptions : GameData -> Sub GameMsgsubscriptions d =
>> Sub.batch
>> ([ Keyboard.downs (\c -> if Char.fromCode c == 'P' then PauseToogle 
>> else NothingHappened) ] ++
>> if d.state == Running then
>> [ AnimationFrame.diffs Tick
>> , Keyboard.downs (\c -> if Char.fromCode c == ' ' then 
>> JumpDown else NothingHappened)
>> , Keyboard.ups (\c -> if Char.fromCode c == ' ' then JumpUp 
>> else NothingHappened)
>> ]
>> else
>> [])
>>
>> The main case distinction in the main update function (in
>> https://github.com/arpad-m/dontfall/blob/master/src/main.elm):
>>
>> updateScene : GameMsg -> GameData -> (GameData, Cmd GameMsg)updateScene msg 
>> d =
>> (case d.state of
>> ...
>> Running -> case msg of
>> MouseMove (x,_) -> { d | characterPosX = min x d.flWidth}
>> Tick t -> stepTime d t
>> PauseToogle -> { d | state = Paused }
>> JumpDown -> { d | jumpPressed = True }
>> JumpUp -> { d | jumpPressed = False }
>> _ -> d
>> , Cmd.none
>> )
>>
>> Given availability of the functions I propose above, the code could
>> instead look as follows:
>>
>> type GameMsg = ... only the other messages, no NothingHappened ...
>> subscriptions : GameData -> Sub GameMsgsubscriptions d =
>> Sub.batch
>> ([ Keyboard.downsSelectively (\c -> if Char.fromCode c == 'P' then 
>> Just PauseToogle else Nothing) ] ++
>> if d.state == Running then
>> [ AnimationFrame.diffs Tick
>> , Keyboard.downsSelectively (\c -> if Char.fromCode c == ' ' 
>> then Just JumpDown else Nothing)
>> , Keyboard.upsSelectively (\c -> if Char.fromCode c == ' ' 
>> then Just Jump

[elm-discuss] Re: about the Keyboard API

[Daniel Bachler]

For what it's worth I like the proposal. Am I correct in thinking that this 
is something that would benefit everyone who wants to handle keyboard 
shortcuts in Elm?

On Monday, August 8, 2016 at 2:49:22 PM UTC+2, Janis Voigtländer wrote:
>
> A while back there was a thread 
>  
> about filtering subscriptions. The following is related, but can also (and 
> probably better) be consumed and discussed independently. For those that do 
> have that older thread as context in mind, the following differs in two 
> essential ways:
>
>- Earlier, the discussion was about generic filtering of arbitrary 
>subscriptions. The following involves no genericity whatsoever. It is only 
>a proposal about the Keyboard API specifically. 
>- The earlier thread was not rooted in practice, since very little 
>stuff had been built yet with subscriptions. In the following, I point to 
>how things have played out in practice, based on uses students have made 
> of 
>the current API in projects. 
>
> --
>
> So, on to the subject matter:
>
> The keyboard package 
>  currently 
> contains functions such as:
>
> Keyboard.downs : (KeyCode -> msg) -> Sub msg
>
> Common uses (I’ll point to several repositories below) are such that only 
> some keys are relevant for an application. My proposal is to have functions 
> such as:
>
> Keyboard.downsSelectively : (KeyCode -> Maybe msg) -> Sub msg
>
> where the semantics is that if a given KeyCode is mapped to Nothing by 
> the tagger, then no message gets sent along the subscription; otherwise the 
> Just is peeled off and the message gets sent.
> --
>
> Let’s look at a practical case, https://github.com/arpad-m/dontfall. It’s 
> a game, where the player uses the keyboard for part of the control. 
> Important excerpts from the code are:
>
> The message type (in 
> https://github.com/arpad-m/dontfall/blob/master/src/BaseStuff.elm):
>
> type GameMsg = NothingHappened | ... several other messages ...
>
> The subscriptions definition (in 
> https://github.com/arpad-m/dontfall/blob/master/src/main.elm):
>
> subscriptions : GameData -> Sub GameMsgsubscriptions d =
> Sub.batch
> ([ Keyboard.downs (\c -> if Char.fromCode c == 'P' then PauseToogle 
> else NothingHappened) ] ++
> if d.state == Running then
> [ AnimationFrame.diffs Tick
> , Keyboard.downs (\c -> if Char.fromCode c == ' ' then 
> JumpDown else NothingHappened)
> , Keyboard.ups (\c -> if Char.fromCode c == ' ' then JumpUp 
> else NothingHappened)
> ]
> else
> [])
>
> The main case distinction in the main update function (in 
> https://github.com/arpad-m/dontfall/blob/master/src/main.elm):
>
> updateScene : GameMsg -> GameData -> (GameData, Cmd GameMsg)updateScene msg d 
> =
> (case d.state of
> ...
> Running -> case msg of
> MouseMove (x,_) -> { d | characterPosX = min x d.flWidth}
> Tick t -> stepTime d t
> PauseToogle -> { d | state = Paused }
> JumpDown -> { d | jumpPressed = True }
> JumpUp -> { d | jumpPressed = False }
> _ -> d
> , Cmd.none
> )
>
> Given availability of the functions I propose above, the code could 
> instead look as follows:
>
> type GameMsg = ... only the other messages, no NothingHappened ...
> subscriptions : GameData -> Sub GameMsgsubscriptions d =
> Sub.batch
> ([ Keyboard.downsSelectively (\c -> if Char.fromCode c == 'P' then 
> Just PauseToogle else Nothing) ] ++
> if d.state == Running then
> [ AnimationFrame.diffs Tick
> , Keyboard.downsSelectively (\c -> if Char.fromCode c == ' ' 
> then Just JumpDown else Nothing)
> , Keyboard.upsSelectively (\c -> if Char.fromCode c == ' ' 
> then Just JumpUp else Nothing)
> ]
> else
> [])
> updateScene : GameMsg -> GameData -> (GameData, Cmd GameMsg)updateScene msg d 
> =
> (case d.state of
> ...
> Running -> case msg of
> MouseMove (x,_) -> { d | characterPosX = min x d.flWidth}
> Tick t -> stepTime d t
> PauseToogle -> { d | state = Paused }
> JumpDown -> { d | jumpPressed = True }
> JumpUp -> { d | jumpPressed = False }
> , Cmd.none
> )
>
> Advantages:
>
>1. 
>
>simpler message type, no special role no-op constructor needed
>2. 
>
>no spurious update and render cycles while the game is running
>3. 
>
>less room for bugs in the update logic
>
> Some additional comments on the latter two of these points:
>
> Re 2., given the current implementation, whenever a key is hit that is not 
> relevant, the update function

Re: [elm-discuss] Re: about the Keyboard API

[OvermindDL1]

Sorry, I always try to look for more generic solutions for specific 
problems.  :-)


On Monday, August 8, 2016 at 9:05:18 AM UTC-6, Janis Voigtländer wrote:
>
> Please don’t derail this thread. As its title says, and as my preface to 
> the opening post says, it is specifically about the Keyboard API.
>
> If you want to pursue a completely different direction with a more general 
> API for generic “skipping updates” stuff, please continue the other thread 
>  I 
> pointed to, or start a new thread.
>
> If there are alternatives *with currently available functions* to my 
> proposal, very interested to hear it in this thread. Also interested in 
> hearing suggestions for other changes to the Keyboard API that would 
> address my points in an alternative way. But suggestions that are dependent 
> on stuff that does not exist and that is not keyboard specific are 
> derailing.
>
> 2016-08-08 16:48 GMT+02:00 OvermindDL1 >:
>
> I do say that I wish there were some way to make some 'update' call as 
>> no-view and/or no-subscription re-call needed.  Like instead of returning 
>> `( model, Cmd.none )` we could do `( model, Cmd.cancelView )` or `( model, 
>> Cmd.cancelSubscription )` or both via `Cmd.batch`, or perhaps as a 
>> three-argument tuple that defaults to `( model, Cmd.none, StateChanges.none 
>> )` or so, which would default to calling everything.  I have a lot of 
>> update messages that are handled that do not change the view and/or 
>> subscriptions and it would be nice to prevent calling those somehow.  Hmm, 
>> actually a backward compatible change would be to add a new Program 
>> callback, in addition to the usual `init`, `update`, `subscriptions`, and 
>> `view`, add another one that I will call just `blah` for now, optional in 
>> the Program or so, but have it be like:
>> ```
>> blah : Msg -> ( Msg, States )
>> blah msg ->
>>   case msg of
>> MyMessageThree _ -> ( msg, States.batch [ States.cancelView, 
>> States.cancelSubscriptions )
>> MyMessageNine arg0 _ -> ( MyMessageThree arg0, States.noChanges ) -- 
>> or `States.none`?
>> MyRedrawMessage -> ( msg, States.cancelView )
>> MyMessageTwelve _ -> ( msg, States.onlyUpdate )
>> _ -> ( msg, States.noChanges )
>> ```
>>
>> And it would be called after `init` and before every call of `update`.  
>> It would allow an easy way to translate one message type into another 
>> (maybe even a way to decorate it more so it can get passed to another 
>> modules update/subscription, this would be a **great** hooking location for 
>> modules), as well as a way to specify what states should be updated for a 
>> given message, a default no-op function could be supplied via 
>> `States.defaultHandle` or so that you could pass to the program so people 
>> do not have to override it in the easy cases.
>>
>> Hmm, an idea for a module handler, one of the states could be something 
>> like:
>> ```elm
>> MaterialMessage msg -> ( msg, States.delegate { 
>> update=Material.update, subscriptions=Material.subscriptions } )
>> ```
>> Which of course the other module could simplify via a helper to:
>> ```elm
>> MaterialMessage msg -> Material.blah msg
>> ```
>>
>>
>> On Monday, August 8, 2016 at 6:49:22 AM UTC-6, Janis Voigtländer wrote:
>>>
>>> A while back there was a thread 
>>>  
>>> about filtering subscriptions. The following is related, but can also (and 
>>> probably better) be consumed and discussed independently. For those that do 
>>> have that older thread as context in mind, the following differs in two 
>>> essential ways:
>>>
>>>- Earlier, the discussion was about generic filtering of arbitrary 
>>>subscriptions. The following involves no genericity whatsoever. It is 
>>> only 
>>>a proposal about the Keyboard API specifically. 
>>>- The earlier thread was not rooted in practice, since very little 
>>>stuff had been built yet with subscriptions. In the following, I point 
>>> to 
>>>how things have played out in practice, based on uses students have made 
>>> of 
>>>the current API in projects. 
>>>
>>> --
>>>
>>> So, on to the subject matter:
>>>
>>> The keyboard package 
>>>  currently 
>>> contains functions such as:
>>>
>>> Keyboard.downs : (KeyCode -> msg) -> Sub msg
>>>
>>> Common uses (I’ll point to several repositories below) are such that 
>>> only some keys are relevant for an application. My proposal is to have 
>>> functions such as:
>>>
>>> Keyboard.downsSelectively : (KeyCode -> Maybe msg) -> Sub msg
>>>
>>> where the semantics is that if a given KeyCode is mapped to Nothing by 
>>> the tagger, then no message gets sent along the subscription; otherwise the 
>>> Just is peeled off and the message gets sent.
>>> --
>>>
>>> Let’s look at a pra

Re: [elm-discuss] Re: about the Keyboard API

[Janis Voigtländer]

Please don’t derail this thread. As its title says, and as my preface to
the opening post says, it is specifically about the Keyboard API.

If you want to pursue a completely different direction with a more general
API for generic “skipping updates” stuff, please continue the other thread
 I
pointed to, or start a new thread.

If there are alternatives *with currently available functions* to my
proposal, very interested to hear it in this thread. Also interested in
hearing suggestions for other changes to the Keyboard API that would
address my points in an alternative way. But suggestions that are dependent
on stuff that does not exist and that is not keyboard specific are
derailing.

2016-08-08 16:48 GMT+02:00 OvermindDL1 :

I do say that I wish there were some way to make some 'update' call as
> no-view and/or no-subscription re-call needed.  Like instead of returning
> `( model, Cmd.none )` we could do `( model, Cmd.cancelView )` or `( model,
> Cmd.cancelSubscription )` or both via `Cmd.batch`, or perhaps as a
> three-argument tuple that defaults to `( model, Cmd.none, StateChanges.none
> )` or so, which would default to calling everything.  I have a lot of
> update messages that are handled that do not change the view and/or
> subscriptions and it would be nice to prevent calling those somehow.  Hmm,
> actually a backward compatible change would be to add a new Program
> callback, in addition to the usual `init`, `update`, `subscriptions`, and
> `view`, add another one that I will call just `blah` for now, optional in
> the Program or so, but have it be like:
> ```
> blah : Msg -> ( Msg, States )
> blah msg ->
>   case msg of
> MyMessageThree _ -> ( msg, States.batch [ States.cancelView,
> States.cancelSubscriptions )
> MyMessageNine arg0 _ -> ( MyMessageThree arg0, States.noChanges ) --
> or `States.none`?
> MyRedrawMessage -> ( msg, States.cancelView )
> MyMessageTwelve _ -> ( msg, States.onlyUpdate )
> _ -> ( msg, States.noChanges )
> ```
>
> And it would be called after `init` and before every call of `update`.  It
> would allow an easy way to translate one message type into another (maybe
> even a way to decorate it more so it can get passed to another modules
> update/subscription, this would be a **great** hooking location for
> modules), as well as a way to specify what states should be updated for a
> given message, a default no-op function could be supplied via
> `States.defaultHandle` or so that you could pass to the program so people
> do not have to override it in the easy cases.
>
> Hmm, an idea for a module handler, one of the states could be something
> like:
> ```elm
> MaterialMessage msg -> ( msg, States.delegate {
> update=Material.update, subscriptions=Material.subscriptions } )
> ```
> Which of course the other module could simplify via a helper to:
> ```elm
> MaterialMessage msg -> Material.blah msg
> ```
>
>
> On Monday, August 8, 2016 at 6:49:22 AM UTC-6, Janis Voigtländer wrote:
>>
>> A while back there was a thread
>> 
>> about filtering subscriptions. The following is related, but can also (and
>> probably better) be consumed and discussed independently. For those that do
>> have that older thread as context in mind, the following differs in two
>> essential ways:
>>
>>- Earlier, the discussion was about generic filtering of arbitrary
>>subscriptions. The following involves no genericity whatsoever. It is only
>>a proposal about the Keyboard API specifically.
>>- The earlier thread was not rooted in practice, since very little
>>stuff had been built yet with subscriptions. In the following, I point to
>>how things have played out in practice, based on uses students have made 
>> of
>>the current API in projects.
>>
>> --
>>
>> So, on to the subject matter:
>>
>> The keyboard package
>>  currently
>> contains functions such as:
>>
>> Keyboard.downs : (KeyCode -> msg) -> Sub msg
>>
>> Common uses (I’ll point to several repositories below) are such that only
>> some keys are relevant for an application. My proposal is to have functions
>> such as:
>>
>> Keyboard.downsSelectively : (KeyCode -> Maybe msg) -> Sub msg
>>
>> where the semantics is that if a given KeyCode is mapped to Nothing by
>> the tagger, then no message gets sent along the subscription; otherwise the
>> Just is peeled off and the message gets sent.
>> --
>>
>> Let’s look at a practical case, https://github.com/arpad-m/dontfall.
>> It’s a game, where the player uses the keyboard for part of the control.
>> Important excerpts from the code are:
>>
>> The message type (in https://github.com/arpad-m/don
>> tfall/blob/master/src/BaseStuff.elm):
>>
>> type GameMsg = NothingHappened | ... several other messages ...
>

[elm-discuss] Re: about the Keyboard API

[OvermindDL1]

Yeah looking 
at https://github.com/elm-lang/core/blob/4.0.4/src/Native/Platform.js shows 
that it would be very easy to add that functionality to core.

On Monday, August 8, 2016 at 8:48:26 AM UTC-6, OvermindDL1 wrote:
>
> I do say that I wish there were some way to make some 'update' call as 
> no-view and/or no-subscription re-call needed.  Like instead of returning 
> `( model, Cmd.none )` we could do `( model, Cmd.cancelView )` or `( model, 
> Cmd.cancelSubscription )` or both via `Cmd.batch`, or perhaps as a 
> three-argument tuple that defaults to `( model, Cmd.none, StateChanges.none 
> )` or so, which would default to calling everything.  I have a lot of 
> update messages that are handled that do not change the view and/or 
> subscriptions and it would be nice to prevent calling those somehow.  Hmm, 
> actually a backward compatible change would be to add a new Program 
> callback, in addition to the usual `init`, `update`, `subscriptions`, and 
> `view`, add another one that I will call just `blah` for now, optional in 
> the Program or so, but have it be like:
> ```
> blah : Msg -> ( Msg, States )
> blah msg ->
>   case msg of
> MyMessageThree _ -> ( msg, States.batch [ States.cancelView, 
> States.cancelSubscriptions )
> MyMessageNine arg0 _ -> ( MyMessageThree arg0, States.noChanges ) -- 
> or `States.none`?
> MyRedrawMessage -> ( msg, States.cancelView )
> MyMessageTwelve _ -> ( msg, States.onlyUpdate )
> _ -> ( msg, States.noChanges )
> ```
>
> And it would be called after `init` and before every call of `update`.  It 
> would allow an easy way to translate one message type into another (maybe 
> even a way to decorate it more so it can get passed to another modules 
> update/subscription, this would be a **great** hooking location for 
> modules), as well as a way to specify what states should be updated for a 
> given message, a default no-op function could be supplied via 
> `States.defaultHandle` or so that you could pass to the program so people 
> do not have to override it in the easy cases.
>
> Hmm, an idea for a module handler, one of the states could be something 
> like:
> ```elm
> MaterialMessage msg -> ( msg, States.delegate { 
> update=Material.update, subscriptions=Material.subscriptions } )
> ```
> Which of course the other module could simplify via a helper to:
> ```elm
> MaterialMessage msg -> Material.blah msg
> ```
>
>
> On Monday, August 8, 2016 at 6:49:22 AM UTC-6, Janis Voigtländer wrote:
>>
>> A while back there was a thread 
>>  
>> about filtering subscriptions. The following is related, but can also (and 
>> probably better) be consumed and discussed independently. For those that do 
>> have that older thread as context in mind, the following differs in two 
>> essential ways:
>>
>>- Earlier, the discussion was about generic filtering of arbitrary 
>>subscriptions. The following involves no genericity whatsoever. It is 
>> only 
>>a proposal about the Keyboard API specifically. 
>>- The earlier thread was not rooted in practice, since very little 
>>stuff had been built yet with subscriptions. In the following, I point to 
>>how things have played out in practice, based on uses students have made 
>> of 
>>the current API in projects. 
>>
>> --
>>
>> So, on to the subject matter:
>>
>> The keyboard package 
>>  currently 
>> contains functions such as:
>>
>> Keyboard.downs : (KeyCode -> msg) -> Sub msg
>>
>> Common uses (I’ll point to several repositories below) are such that only 
>> some keys are relevant for an application. My proposal is to have functions 
>> such as:
>>
>> Keyboard.downsSelectively : (KeyCode -> Maybe msg) -> Sub msg
>>
>> where the semantics is that if a given KeyCode is mapped to Nothing by 
>> the tagger, then no message gets sent along the subscription; otherwise the 
>> Just is peeled off and the message gets sent.
>> --
>>
>> Let’s look at a practical case, https://github.com/arpad-m/dontfall. 
>> It’s a game, where the player uses the keyboard for part of the control. 
>> Important excerpts from the code are:
>>
>> The message type (in 
>> https://github.com/arpad-m/dontfall/blob/master/src/BaseStuff.elm):
>>
>> type GameMsg = NothingHappened | ... several other messages ...
>>
>> The subscriptions definition (in 
>> https://github.com/arpad-m/dontfall/blob/master/src/main.elm):
>>
>> subscriptions : GameData -> Sub GameMsgsubscriptions d =
>> Sub.batch
>> ([ Keyboard.downs (\c -> if Char.fromCode c == 'P' then PauseToogle 
>> else NothingHappened) ] ++
>> if d.state == Running then
>> [ AnimationFrame.diffs Tick
>> , Keyboard.downs (\c -> if Char.fromCode c == ' ' then 
>> JumpDown else NothingHappened)
>> , Keyboard.ups (\c -> if

[elm-discuss] Re: about the Keyboard API

[OvermindDL1]

I do say that I wish there were some way to make some 'update' call as 
no-view and/or no-subscription re-call needed.  Like instead of returning 
`( model, Cmd.none )` we could do `( model, Cmd.cancelView )` or `( model, 
Cmd.cancelSubscription )` or both via `Cmd.batch`, or perhaps as a 
three-argument tuple that defaults to `( model, Cmd.none, StateChanges.none 
)` or so, which would default to calling everything.  I have a lot of 
update messages that are handled that do not change the view and/or 
subscriptions and it would be nice to prevent calling those somehow.  Hmm, 
actually a backward compatible change would be to add a new Program 
callback, in addition to the usual `init`, `update`, `subscriptions`, and 
`view`, add another one that I will call just `blah` for now, optional in 
the Program or so, but have it be like:
```
blah : Msg -> ( Msg, States )
blah msg ->
  case msg of
MyMessageThree _ -> ( msg, States.batch [ States.cancelView, 
States.cancelSubscriptions )
MyMessageNine arg0 _ -> ( MyMessageThree arg0, States.noChanges ) -- or 
`States.none`?
MyRedrawMessage -> ( msg, States.cancelView )
MyMessageTwelve _ -> ( msg, States.onlyUpdate )
_ -> ( msg, States.noChanges )
```

And it would be called after `init` and before every call of `update`.  It 
would allow an easy way to translate one message type into another (maybe 
even a way to decorate it more so it can get passed to another modules 
update/subscription, this would be a **great** hooking location for 
modules), as well as a way to specify what states should be updated for a 
given message, a default no-op function could be supplied via 
`States.defaultHandle` or so that you could pass to the program so people 
do not have to override it in the easy cases.

Hmm, an idea for a module handler, one of the states could be something 
like:
```elm
MaterialMessage msg -> ( msg, States.delegate { update=Material.update, 
subscriptions=Material.subscriptions } )
```
Which of course the other module could simplify via a helper to:
```elm
MaterialMessage msg -> Material.blah msg
```


On Monday, August 8, 2016 at 6:49:22 AM UTC-6, Janis Voigtländer wrote:
>
> A while back there was a thread 
>  
> about filtering subscriptions. The following is related, but can also (and 
> probably better) be consumed and discussed independently. For those that do 
> have that older thread as context in mind, the following differs in two 
> essential ways:
>
>- Earlier, the discussion was about generic filtering of arbitrary 
>subscriptions. The following involves no genericity whatsoever. It is only 
>a proposal about the Keyboard API specifically. 
>- The earlier thread was not rooted in practice, since very little 
>stuff had been built yet with subscriptions. In the following, I point to 
>how things have played out in practice, based on uses students have made 
> of 
>the current API in projects. 
>
> --
>
> So, on to the subject matter:
>
> The keyboard package 
>  currently 
> contains functions such as:
>
> Keyboard.downs : (KeyCode -> msg) -> Sub msg
>
> Common uses (I’ll point to several repositories below) are such that only 
> some keys are relevant for an application. My proposal is to have functions 
> such as:
>
> Keyboard.downsSelectively : (KeyCode -> Maybe msg) -> Sub msg
>
> where the semantics is that if a given KeyCode is mapped to Nothing by 
> the tagger, then no message gets sent along the subscription; otherwise the 
> Just is peeled off and the message gets sent.
> --
>
> Let’s look at a practical case, https://github.com/arpad-m/dontfall. It’s 
> a game, where the player uses the keyboard for part of the control. 
> Important excerpts from the code are:
>
> The message type (in 
> https://github.com/arpad-m/dontfall/blob/master/src/BaseStuff.elm):
>
> type GameMsg = NothingHappened | ... several other messages ...
>
> The subscriptions definition (in 
> https://github.com/arpad-m/dontfall/blob/master/src/main.elm):
>
> subscriptions : GameData -> Sub GameMsgsubscriptions d =
> Sub.batch
> ([ Keyboard.downs (\c -> if Char.fromCode c == 'P' then PauseToogle 
> else NothingHappened) ] ++
> if d.state == Running then
> [ AnimationFrame.diffs Tick
> , Keyboard.downs (\c -> if Char.fromCode c == ' ' then 
> JumpDown else NothingHappened)
> , Keyboard.ups (\c -> if Char.fromCode c == ' ' then JumpUp 
> else NothingHappened)
> ]
> else
> [])
>
> The main case distinction in the main update function (in 
> https://github.com/arpad-m/dontfall/blob/master/src/main.elm):
>
> updateScene : GameMsg -> GameData -> (GameData, Cmd GameMsg)updateScene msg d 
> =
> (case d.state of
> ...
>