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

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

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

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

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

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

[elm-discuss] Re: about the Keyboard API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

[elm-discuss] Re: about the Keyboard API

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

[elm-discuss] Re: about the Keyboard API

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

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

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

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

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

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

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

[elm-discuss] Re: about the Keyboard API

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 >

[elm-discuss] Re: about the Keyboard API

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