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 [email protected]. For more options, visit https://groups.google.com/d/optout.
