Existing common input abstraction?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Existing common input abstraction?

sledorze
I'm looking for solutions in order to unify mouse / keyboard (at least) management for our little project.
Any input welcomed (lol)

Stephane
Reply | Threaded
Open this post in threaded view
|

Re: Existing common input abstraction?

Dion Whitehead Amago
In hydrax https://github.com/dionjwa/Hydrax/tree/
touch, gestures, and mouse events are funneled into an InputManager,
so as long as you're not needing non-gesture-multi-finger touch, you
have a single unified access point for mouse/touch events.

On Fri, Jun 17, 2011 at 11:49 AM, sledorze <[hidden email]> wrote:

> I'm looking for solutions in order to unify mouse / keyboard (at least)
> management for our little project.
> Any input welcomed (lol)
>
> Stephane
>
>
> --
> View this message in context: http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6487864.html
> Sent from the Haxe mailing list archive at Nabble.com.
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Existing common input abstraction?

sledorze
Thanks! :)
Reply | Threaded
Open this post in threaded view
|

Re: Existing common input abstraction?

Rob Fell
In reply to this post by sledorze
Hi,

"awe6" features a UI abstraction: IInputManager
http://code.google.com/p/awe6/wiki/ComponentInputs

It provides mouse, keyboard and "virtual" joypads using a state / FRP
approach (rather than events) ... e.g:

is space pressed: IInputKeyboard.getIsKeyDown( EKey.SPACE ):Bool
how long has space been pressed: IInputKeyboard.getKeyDownDuration(
EKey.SPACE ):Bool
current mouse horizontal speed: IInputMouse.deltaX:Int

Might be useful (in part or full) if you like that style?

Best regards, Rob



On 11:59 AM, sledorze wrote:

> I'm looking for solutions in order to unify mouse / keyboard (at least)
> management for our little project.
> Any input welcomed (lol)
>
> Stephane
>
>
> --
> View this message in context: http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6487864.html
> Sent from the Haxe mailing list archive at Nabble.com.
>
>


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Existing common input abstraction?

sledorze
Clean project pages!
Thanks for the pointer, :)

But what I'm looking for, is an existing cross-plateform abstraction (includes JS).
Yeah, the event system is something we'll have to discuss at some point in the large.

Stephane

(Big big) P.S.:

By 'FRP'; I wonder what you mean exactly.
I first though you were refering toFunctional Reactive Programming (which I much like :) ) but it appears you weren't..

I've seen that Dion provides Event (hsl) interfaces and you provide a state based solution.

I'm totally biased as I would use FRP (Functional Reactive Programming) but I don't think it's not a natural choice for most programmers and for all tasks..

As for a state vs event based solution; I clearly think the latter is more expressive; as you can derive state from events (a fold) but not the other way around without relying on .. an event (the update to consult the state).

Anyway still it's a matter of taste; we should strive for providing choice rather than dictature and help either case (when possible :) ).



On Fri, Jun 17, 2011 at 7:36 PM, Rob Fell [via Haxe] <[hidden email]> wrote:
Hi,

"awe6" features a UI abstraction: IInputManager
http://code.google.com/p/awe6/wiki/ComponentInputs

It provides mouse, keyboard and "virtual" joypads using a state / FRP
approach (rather than events) ... e.g:

is space pressed: IInputKeyboard.getIsKeyDown( EKey.SPACE ):Bool
how long has space been pressed: IInputKeyboard.getKeyDownDuration(
EKey.SPACE ):Bool
current mouse horizontal speed: IInputMouse.deltaX:Int

Might be useful (in part or full) if you like that style?

Best regards, Rob



On 11:59 AM, sledorze wrote:

> I'm looking for solutions in order to unify mouse / keyboard (at least)
> management for our little project.
> Any input welcomed (lol)
>
> Stephane
>
>
> --
> View this message in context: http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6487864.html
> Sent from the Haxe mailing list archive at Nabble.com.
>
>


--
haXe - an open source web programming language
http://haxe.org



If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6488062.html
To unsubscribe from Existing common input abstraction?, click here.



--
Stéphane Le Dorze

Tel: +33 (0) 6 08  76 70 15


Reply | Threaded
Open this post in threaded view
|

Re: Existing common input abstraction?

Rob Fell


On 11:59 AM, sledorze wrote:

> Clean project pages!
> Thanks for the pointer, :)
>
> But what I'm looking for, is an existing cross-plateform abstraction
> (includes JS).
> Yeah, the event system is something we'll have to discuss at some
> point in the large.
>
> Stephane
>
> (Big big) P.S.:
>
> By 'FRP'; I wonder what you mean exactly.
> I first though you were refering toFunctional Reactive Programming
> (which I much like :) ) but it appears you weren't..

I was :-)
But perhaps simplistically?

My understanding of FRP is that using a time ordered sequence of
discrete states is a valid input stream / cascade.  In this example
other objects relying on Inputs can link directly to the IInputManager
methods without side effect (functional) and be automatically updated as
time changes (reactive).

However, IInputManager has only the "current" state publicly available
(and the remaining stream used privately to derive things like
downDurations etc).

So perhaps to properly qualify this interface as "FRP" we should add an
extra method - e.g:
IInputKeyboard.getSnapshot( age:Int ):IInputKeyboard

Or in the case of inputs we need to consider the true delta - i.e. all
the behavior that has occurred in between - e.g. an array of all input
snapshots to be processed?
IInputKeyboard.getDelta( age:Int ):Array<{ age:Int, snapshot:
IInputKeyboard }>

I'd welcome input :-)

>
> I've seen that Dion provides Event (hsl) interfaces and you provide a
> state based solution.
>
> I'm totally biased as I would use FRP (Functional Reactive
> Programming) but I don't think it's not a natural choice for most
> programmers and for all tasks..
>
> As for a state vs event based solution; I clearly think the latter is
> more expressive; as you can derive state from events (a fold) but not
> the other way around without relying on .. an event (the update to
> consult the state).
>
> Anyway still it's a matter of taste; we should strive for providing
> choice rather than dictature and help either case (when possible :) ).
>
>
>
> On Fri, Jun 17, 2011 at 7:36 PM, Rob Fell [via Haxe] <[hidden email]
> </user/SendEmail.jtp?type=node&node=6488371&i=0>> wrote:
>
>     Hi,
>
>     "awe6" features a UI abstraction: IInputManager
>     http://code.google.com/p/awe6/wiki/ComponentInputs
>
>     It provides mouse, keyboard and "virtual" joypads using a state / FRP
>     approach (rather than events) ... e.g:
>
>     is space pressed: IInputKeyboard.getIsKeyDown( EKey.SPACE ):Bool
>     how long has space been pressed: IInputKeyboard.getKeyDownDuration(
>     EKey.SPACE ):Bool
>     current mouse horizontal speed: IInputMouse.deltaX:Int
>
>     Might be useful (in part or full) if you like that style?
>
>     Best regards, Rob
>
>
>
>     On 11:59 AM, sledorze wrote:
>
>     > I'm looking for solutions in order to unify mouse / keyboard (at
>     least)
>     > management for our little project.
>     > Any input welcomed (lol)
>     >
>     > Stephane
>     >
>     >
>     > --
>     > View this message in context:
>     http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6487864.html
>     > Sent from the Haxe mailing list archive at Nabble.com.
>     >
>     >
>
>
>     --
>     haXe - an open source web programming language
>     http://haxe.org
>
>
>     ------------------------------------------------------------------------
>     If you reply to this email, your message will be added to the
>     discussion below:
>     http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6488062.html
>
>     To unsubscribe from Existing common input abstraction?, click here.
>
>
>
>
> --
> Stéphane Le Dorze
>
> Tel: +33 (0) 6 08  76 70 15
>
>
>
> ------------------------------------------------------------------------
> View this message in context: Re: Existing common input abstraction?
> <http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6488371.html>
> Sent from the Haxe mailing list archive
> <http://haxe.1354130.n2.nabble.com/> at Nabble.com.


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Existing common input abstraction?

sledorze
FRP (or adaptative programming) is a computational model which should exhibit some specific behaviors.
First it's functionnal, so it's made of combinators in order to build programs.
Second it behaves like a pull model, so for a push implementation, to remain consistent, it should respect some graph height when propagating throught nodes (hence the priority queue in Stax).
There's a lot of litterature around that you can find.
Don't get caught by some naive implementation like Microsoft Rx, it is not real reactive programming (not consistent).
You may look at Stax, FrTime, FlapJax, Froc (Ocaml), Reactive (Scala) or the various Haskell implementations.
Conal Eliott is a very interesting guy to read, however, you'll be lost if you're not already an experienced Haskeller..

Recently urWeb, Asana and perhaps OPA (not sure about this one) are using this paradigm to build web servers.

Hope it give enought pointers :)
Stephane


On Sat, Jun 18, 2011 at 3:27 AM, Rob Fell [via Haxe] <[hidden email]> wrote:


On 11:59 AM, sledorze wrote:

> Clean project pages!
> Thanks for the pointer, :)
>
> But what I'm looking for, is an existing cross-plateform abstraction
> (includes JS).
> Yeah, the event system is something we'll have to discuss at some
> point in the large.
>
> Stephane
>
> (Big big) P.S.:
>
> By 'FRP'; I wonder what you mean exactly.
> I first though you were refering toFunctional Reactive Programming
> (which I much like :) ) but it appears you weren't..
I was :-)
But perhaps simplistically?

My understanding of FRP is that using a time ordered sequence of
discrete states is a valid input stream / cascade.  In this example
other objects relying on Inputs can link directly to the IInputManager
methods without side effect (functional) and be automatically updated as
time changes (reactive).

However, IInputManager has only the "current" state publicly available
(and the remaining stream used privately to derive things like
downDurations etc).

So perhaps to properly qualify this interface as "FRP" we should add an
extra method - e.g:
IInputKeyboard.getSnapshot( age:Int ):IInputKeyboard

Or in the case of inputs we need to consider the true delta - i.e. all
the behavior that has occurred in between - e.g. an array of all input
snapshots to be processed?
IInputKeyboard.getDelta( age:Int ):Array<{ age:Int, snapshot:
IInputKeyboard }>

I'd welcome input :-)

>
> I've seen that Dion provides Event (hsl) interfaces and you provide a
> state based solution.
>
> I'm totally biased as I would use FRP (Functional Reactive
> Programming) but I don't think it's not a natural choice for most
> programmers and for all tasks..
>
> As for a state vs event based solution; I clearly think the latter is
> more expressive; as you can derive state from events (a fold) but not
> the other way around without relying on .. an event (the update to
> consult the state).
>
> Anyway still it's a matter of taste; we should strive for providing
> choice rather than dictature and help either case (when possible :) ).
>
>
>
> On Fri, Jun 17, 2011 at 7:36 PM, Rob Fell [via Haxe] <[hidden email]

> </user/SendEmail.jtp?type=node&node=6488371&i=0>> wrote:
>
>     Hi,
>
>     "awe6" features a UI abstraction: IInputManager
>     http://code.google.com/p/awe6/wiki/ComponentInputs
>
>     It provides mouse, keyboard and "virtual" joypads using a state / FRP
>     approach (rather than events) ... e.g:
>
>     is space pressed: IInputKeyboard.getIsKeyDown( EKey.SPACE ):Bool
>     how long has space been pressed: IInputKeyboard.getKeyDownDuration(
>     EKey.SPACE ):Bool
>     current mouse horizontal speed: IInputMouse.deltaX:Int
>
>     Might be useful (in part or full) if you like that style?
>
>     Best regards, Rob
>
>
>
>     On 11:59 AM, sledorze wrote:
>
>     > I'm looking for solutions in order to unify mouse / keyboard (at
>     least)
>     > management for our little project.
>     > Any input welcomed (lol)
>     >
>     > Stephane
>     >
>     >
>     > --
>     > View this message in context:
>     http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6487864.html
>     > Sent from the Haxe mailing list archive at Nabble.com.

>     >
>     >
>
>
>     --
>     haXe - an open source web programming language
>     http://haxe.org
>
>
>     ------------------------------------------------------------------------
>     If you reply to this email, your message will be added to the
>     discussion below:
>     http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6488062.html
>

>     To unsubscribe from Existing common input abstraction?, click here.
>
>
>
>
> --
> Stéphane Le Dorze
>
> Tel: <a href="tel:%2B33%20%280%29%206%2008%20%C2%A076%2070%2015" value="+33608767015" target="_blank">+33 (0) 6 08  76 70 15
>
>
>
> ------------------------------------------------------------------------
> View this message in context: Re: Existing common input abstraction?
> <http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6488371.html>
> Sent from the Haxe mailing list archive
> <http://haxe.1354130.n2.nabble.com/> at Nabble.com.


--
haXe - an open source web programming language
http://haxe.org



If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6489510.html
To unsubscribe from Existing common input abstraction?, click here.



--
Stéphane Le Dorze

Tel: <a href="tel:%2B33%20%280%29%206%2008%20%C2%A076%2070%2015" value="+33608767015" target="_blank">+33 (0) 6 08  76 70 15


Reply | Threaded
Open this post in threaded view
|

Re: Existing common input abstraction?

Simon Asselbergs
Hi Stephane and Sledorze (+ rest of list),

On the short term there is no FRP GUI stuff for haxe. However I after I have done some last work for Stax I will have laser like focus on the development of a real FRP GUI component framework with batteries included (components). I am an Interaction designer for a profession and I will ensure the (micro)usability of both the GUI stuff for end users as well as making it lean and very mean and it will be integral part of Stax. And it will be both for flash and javascript and the idea is that it will add more targets (so also including effort to get Stax to more targets)

So unless you can't wait I guess writing a declarative wrapper for FlapJax would be a nice idea.

Simon

On Sat, Jun 18, 2011 at 2:01 PM, sledorze <[hidden email]> wrote:
FRP (or adaptative programming) is a computational model which should exhibit some specific behaviors.
First it's functionnal, so it's made of combinators in order to build programs.
Second it behaves like a pull model, so for a push implementation, to remain consistent, it should respect some graph height when propagating throught nodes (hence the priority queue in Stax).
There's a lot of litterature around that you can find.
Don't get caught by some naive implementation like Microsoft Rx, it is not real reactive programming (not consistent).
You may look at Stax, FrTime, FlapJax, Froc (Ocaml), Reactive (Scala) or the various Haskell implementations.
Conal Eliott is a very interesting guy to read, however, you'll be lost if you're not already an experienced Haskeller..

Recently urWeb, Asana and perhaps OPA (not sure about this one) are using this paradigm to build web servers.

Hope it give enought pointers :)
Stephane


On Sat, Jun 18, 2011 at 3:27 AM, Rob Fell [via Haxe] <[hidden email]> wrote:


On 11:59 AM, sledorze wrote:

> Clean project pages!
> Thanks for the pointer, :)
>
> But what I'm looking for, is an existing cross-plateform abstraction
> (includes JS).
> Yeah, the event system is something we'll have to discuss at some
> point in the large.
>
> Stephane
>
> (Big big) P.S.:
>
> By 'FRP'; I wonder what you mean exactly.
> I first though you were refering toFunctional Reactive Programming
> (which I much like :) ) but it appears you weren't..
I was :-)
But perhaps simplistically?

My understanding of FRP is that using a time ordered sequence of
discrete states is a valid input stream / cascade.  In this example
other objects relying on Inputs can link directly to the IInputManager
methods without side effect (functional) and be automatically updated as
time changes (reactive).

However, IInputManager has only the "current" state publicly available
(and the remaining stream used privately to derive things like
downDurations etc).

So perhaps to properly qualify this interface as "FRP" we should add an
extra method - e.g:
IInputKeyboard.getSnapshot( age:Int ):IInputKeyboard

Or in the case of inputs we need to consider the true delta - i.e. all
the behavior that has occurred in between - e.g. an array of all input
snapshots to be processed?
IInputKeyboard.getDelta( age:Int ):Array<{ age:Int, snapshot:
IInputKeyboard }>

I'd welcome input :-)

>
> I've seen that Dion provides Event (hsl) interfaces and you provide a
> state based solution.
>
> I'm totally biased as I would use FRP (Functional Reactive
> Programming) but I don't think it's not a natural choice for most
> programmers and for all tasks..
>
> As for a state vs event based solution; I clearly think the latter is
> more expressive; as you can derive state from events (a fold) but not
> the other way around without relying on .. an event (the update to
> consult the state).
>
> Anyway still it's a matter of taste; we should strive for providing
> choice rather than dictature and help either case (when possible :) ).
>
>
>
> On Fri, Jun 17, 2011 at 7:36 PM, Rob Fell [via Haxe] <[hidden email]

> </user/SendEmail.jtp?type=node&node=6488371&i=0>> wrote:
>
>     Hi,
>
>     "awe6" features a UI abstraction: IInputManager
>     http://code.google.com/p/awe6/wiki/ComponentInputs
>
>     It provides mouse, keyboard and "virtual" joypads using a state / FRP
>     approach (rather than events) ... e.g:
>
>     is space pressed: IInputKeyboard.getIsKeyDown( EKey.SPACE ):Bool
>     how long has space been pressed: IInputKeyboard.getKeyDownDuration(
>     EKey.SPACE ):Bool
>     current mouse horizontal speed: IInputMouse.deltaX:Int
>
>     Might be useful (in part or full) if you like that style?
>
>     Best regards, Rob
>
>
>
>     On 11:59 AM, sledorze wrote:
>
>     > I'm looking for solutions in order to unify mouse / keyboard (at
>     least)
>     > management for our little project.
>     > Any input welcomed (lol)
>     >
>     > Stephane
>     >
>     >
>     > --
>     > View this message in context:
>     http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6487864.html
>     > Sent from the Haxe mailing list archive at Nabble.com.

>     >
>     >
>
>
>     --
>     haXe - an open source web programming language
>     http://haxe.org
>
>
>     ------------------------------------------------------------------------
>     If you reply to this email, your message will be added to the
>     discussion below:
>     http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6488062.html
>

>     To unsubscribe from Existing common input abstraction?, click here.
>
>
>
>
> --
> Stéphane Le Dorze
>
> Tel: <a href="tel:%2B33%20%280%29%206%2008%20%C2%A076%2070%2015" value="<a href="tel:%2B33608767015" value="+33608767015" target="_blank">+33608767015" target="_blank"><a href="tel:%2B33%20%280%29%206%2008%20%C2%A076%2070%2015" value="+33608767015" target="_blank">+33 (0) 6 08  76 70 15
>
>
>
> ------------------------------------------------------------------------
> View this message in context: Re: Existing common input abstraction?
> <http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6488371.html>
> Sent from the Haxe mailing list archive
> <http://haxe.1354130.n2.nabble.com/> at Nabble.com.


--
haXe - an open source web programming language
http://haxe.org



If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6489510.html
To unsubscribe from Existing common input abstraction?, click here.



--
Stéphane Le Dorze

Tel: <a href="tel:%2B33%20%280%29%206%2008%20%C2%A076%2070%2015" value="<a href="tel:%2B33608767015" value="+33608767015" target="_blank">+33608767015" target="_blank"><a href="tel:%2B33%20%280%29%206%2008%20%C2%A076%2070%2015" value="+33608767015" target="_blank">+33 (0) 6 08  76 70 15




View this message in context: Re: Existing common input abstraction?
Sent from the Haxe mailing list archive at Nabble.com.

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Existing common input abstraction?

sledorze
A very concern is that you cannot easily prevent leaks with a push based implementation without weak refs if you want to provide flatMap behavior..
So on JS, it's still an issue.
That's said, for other targets, would be very interesting.. 

Stephane

P.S.: I say that because I gave it a try recently and came to implement arrows; problem, they're not very easy to write without specific syntax support..

On Sat, Jun 18, 2011 at 5:37 PM, Simon Asselbergs [via Haxe] <[hidden email]> wrote:
Hi Stephane and Sledorze (+ rest of list),

On the short term there is no FRP GUI stuff for haxe. However I after I have done some last work for Stax I will have laser like focus on the development of a real FRP GUI component framework with batteries included (components). I am an Interaction designer for a profession and I will ensure the (micro)usability of both the GUI stuff for end users as well as making it lean and very mean and it will be integral part of Stax. And it will be both for flash and javascript and the idea is that it will add more targets (so also including effort to get Stax to more targets)

So unless you can't wait I guess writing a declarative wrapper for FlapJax would be a nice idea.

Simon

On Sat, Jun 18, 2011 at 2:01 PM, sledorze <[hidden email]> wrote:
FRP (or adaptative programming) is a computational model which should exhibit some specific behaviors.
First it's functionnal, so it's made of combinators in order to build programs.
Second it behaves like a pull model, so for a push implementation, to remain consistent, it should respect some graph height when propagating throught nodes (hence the priority queue in Stax).
There's a lot of litterature around that you can find.
Don't get caught by some naive implementation like Microsoft Rx, it is not real reactive programming (not consistent).
You may look at Stax, FrTime, FlapJax, Froc (Ocaml), Reactive (Scala) or the various Haskell implementations.
Conal Eliott is a very interesting guy to read, however, you'll be lost if you're not already an experienced Haskeller..

Recently urWeb, Asana and perhaps OPA (not sure about this one) are using this paradigm to build web servers.

Hope it give enought pointers :)
Stephane


On Sat, Jun 18, 2011 at 3:27 AM, Rob Fell [via Haxe] <[hidden email]> wrote:


On 11:59 AM, sledorze wrote:

> Clean project pages!
> Thanks for the pointer, :)
>
> But what I'm looking for, is an existing cross-plateform abstraction
> (includes JS).
> Yeah, the event system is something we'll have to discuss at some
> point in the large.
>
> Stephane
>
> (Big big) P.S.:
>
> By 'FRP'; I wonder what you mean exactly.
> I first though you were refering toFunctional Reactive Programming
> (which I much like :) ) but it appears you weren't..
I was :-)
But perhaps simplistically?

My understanding of FRP is that using a time ordered sequence of
discrete states is a valid input stream / cascade.  In this example
other objects relying on Inputs can link directly to the IInputManager
methods without side effect (functional) and be automatically updated as
time changes (reactive).

However, IInputManager has only the "current" state publicly available
(and the remaining stream used privately to derive things like
downDurations etc).

So perhaps to properly qualify this interface as "FRP" we should add an
extra method - e.g:
IInputKeyboard.getSnapshot( age:Int ):IInputKeyboard

Or in the case of inputs we need to consider the true delta - i.e. all
the behavior that has occurred in between - e.g. an array of all input
snapshots to be processed?
IInputKeyboard.getDelta( age:Int ):Array<{ age:Int, snapshot:
IInputKeyboard }>

I'd welcome input :-)

>
> I've seen that Dion provides Event (hsl) interfaces and you provide a
> state based solution.
>
> I'm totally biased as I would use FRP (Functional Reactive
> Programming) but I don't think it's not a natural choice for most
> programmers and for all tasks..
>
> As for a state vs event based solution; I clearly think the latter is
> more expressive; as you can derive state from events (a fold) but not
> the other way around without relying on .. an event (the update to
> consult the state).
>
> Anyway still it's a matter of taste; we should strive for providing
> choice rather than dictature and help either case (when possible :) ).
>
>
>
> On Fri, Jun 17, 2011 at 7:36 PM, Rob Fell [via Haxe] <[hidden email]

> </user/SendEmail.jtp?type=node&node=6488371&i=0>> wrote:
>
>     Hi,
>
>     "awe6" features a UI abstraction: IInputManager
>     http://code.google.com/p/awe6/wiki/ComponentInputs
>
>     It provides mouse, keyboard and "virtual" joypads using a state / FRP
>     approach (rather than events) ... e.g:
>
>     is space pressed: IInputKeyboard.getIsKeyDown( EKey.SPACE ):Bool
>     how long has space been pressed: IInputKeyboard.getKeyDownDuration(
>     EKey.SPACE ):Bool
>     current mouse horizontal speed: IInputMouse.deltaX:Int
>
>     Might be useful (in part or full) if you like that style?
>
>     Best regards, Rob
>
>
>
>     On 11:59 AM, sledorze wrote:
>
>     > I'm looking for solutions in order to unify mouse / keyboard (at
>     least)
>     > management for our little project.
>     > Any input welcomed (lol)
>     >
>     > Stephane
>     >
>     >
>     > --
>     > View this message in context:
>     http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6487864.html
>     > Sent from the Haxe mailing list archive at Nabble.com.

>     >
>     >
>
>
>     --
>     haXe - an open source web programming language
>     http://haxe.org
>
>
>     ------------------------------------------------------------------------
>     If you reply to this email, your message will be added to the
>     discussion below:
>     http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6488062.html
>

>     To unsubscribe from Existing common input abstraction?, click here.
>
>
>
>
> --
> Stéphane Le Dorze
>
> Tel: <a href="tel:%2B33%20%280%29%206%2008%20%C2%A076%2070%2015" value="<a href="tel:%2B33608767015" value="<a href="tel:%2B33608767015" value="+33608767015" target="_blank">+33608767015" target="_blank"><a href="tel:%2B33608767015" value="+33608767015" target="_blank">+33608767015" target="_blank"><a href="tel:%2B33%20%280%29%206%2008%20%C2%A076%2070%2015" value="<a href="tel:%2B33608767015" value="+33608767015" target="_blank">+33608767015" target="_blank"><a href="tel:%2B33%20%280%29%206%2008%20%C2%A076%2070%2015" value="+33608767015" target="_blank">+33 (0) 6 08  76 70 15
>
>
>
> ------------------------------------------------------------------------
> View this message in context: Re: Existing common input abstraction?
> <http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6488371.html>
> Sent from the Haxe mailing list archive
> <http://haxe.1354130.n2.nabble.com/> at Nabble.com.


--
haXe - an open source web programming language
http://haxe.org



If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6489510.html
To unsubscribe from Existing common input abstraction?, click here.



--
Stéphane Le Dorze

Tel: <a href="tel:%2B33%20%280%29%206%2008%20%C2%A076%2070%2015" value="<a href="tel:%2B33608767015" value="<a href="tel:%2B33608767015" value="+33608767015" target="_blank">+33608767015" target="_blank"><a href="tel:%2B33608767015" value="+33608767015" target="_blank">+33608767015" target="_blank"><a href="tel:%2B33%20%280%29%206%2008%20%C2%A076%2070%2015" value="<a href="tel:%2B33608767015" value="+33608767015" target="_blank">+33608767015" target="_blank"><a href="tel:%2B33%20%280%29%206%2008%20%C2%A076%2070%2015" value="+33608767015" target="_blank">+33 (0) 6 08  76 70 15




View this message in context: Re: Existing common input abstraction?
Sent from the Haxe mailing list archive at Nabble.com.

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6491015.html
To unsubscribe from Existing common input abstraction?, click here.



--
Stéphane Le Dorze

Tel: +33 (0) 6 08  76 70 15


Reply | Threaded
Open this post in threaded view
|

Re: Existing common input abstraction?

Rob Fell
In reply to this post by sledorze
Thanks Stephane :-)

Yes, I find "FRP" (like all the good stuff) can often be a semantic
topic, but the "behavior as a consistent function of time" goal is what
I find so attractive (and simple).

With regards to UI, as input is discrete, surely snapshots (state +
time) are the appropriate course?  This then becomes one of the lowest
common denominators of the pull stream (forcing the application into a
discrete stepper / traversal / incremental update of behavior, or more
accurately a function of).

How that updater is efficiently processed is down to each behavior's
implementation, as GC or other optimisation on such a UI stream would be
impossible to dictate abstractly.  E.g. Mario moves left 5 times, right
3 times doesn't always equate to Mario just moving left 2 times (depends
who he met in between, or whether he accelerates etc).

Best regards, Rob


On 11:59 AM, sledorze wrote:

> FRP (or adaptative programming) is a computational model which should
> exhibit some specific behaviors.
> First it's functionnal, so it's made of combinators in order to build
> programs.
> Second it behaves like a pull model, so for a push implementation, to
> remain consistent, it should respect some graph height when
> propagating throught nodes (hence the priority queue in Stax).
> There's a lot of litterature around that you can find.
> Don't get caught by some naive implementation like Microsoft Rx, it is
> not real reactive programming (not consistent).
> You may look at Stax, FrTime, FlapJax, Froc (Ocaml), Reactive (Scala)
> or the various Haskell implementations.
> Conal Eliott is a very interesting guy to read, however, you'll be
> lost if you're not already an experienced Haskeller..
>
> Recently urWeb, Asana and perhaps OPA (not sure about this one) are
> using this paradigm to build web servers.
>
> Hope it give enought pointers :)
> Stephane
>
>
> On Sat, Jun 18, 2011 at 3:27 AM, Rob Fell [via Haxe] <[hidden email]
> </user/SendEmail.jtp?type=node&node=6490603&i=0>> wrote:
>
>
>
>     On 11:59 AM, sledorze wrote:
>
>     > Clean project pages!
>     > Thanks for the pointer, :)
>     >
>     > But what I'm looking for, is an existing cross-plateform
>     abstraction
>     > (includes JS).
>     > Yeah, the event system is something we'll have to discuss at some
>     > point in the large.
>     >
>     > Stephane
>     >
>     > (Big big) P.S.:
>     >
>     > By 'FRP'; I wonder what you mean exactly.
>     > I first though you were refering toFunctional Reactive Programming
>     > (which I much like :) ) but it appears you weren't..
>     I was :-)
>     But perhaps simplistically?
>
>     My understanding of FRP is that using a time ordered sequence of
>     discrete states is a valid input stream / cascade.  In this example
>     other objects relying on Inputs can link directly to the
>     IInputManager
>     methods without side effect (functional) and be automatically
>     updated as
>     time changes (reactive).
>
>     However, IInputManager has only the "current" state publicly
>     available
>     (and the remaining stream used privately to derive things like
>     downDurations etc).
>
>     So perhaps to properly qualify this interface as "FRP" we should
>     add an
>     extra method - e.g:
>     IInputKeyboard.getSnapshot( age:Int ):IInputKeyboard
>
>     Or in the case of inputs we need to consider the true delta - i.e.
>     all
>     the behavior that has occurred in between - e.g. an array of all
>     input
>     snapshots to be processed?
>     IInputKeyboard.getDelta( age:Int ):Array<{ age:Int, snapshot:
>     IInputKeyboard }>
>
>     I'd welcome input :-)
>
>     >
>     > I've seen that Dion provides Event (hsl) interfaces and you
>     provide a
>     > state based solution.
>     >
>     > I'm totally biased as I would use FRP (Functional Reactive
>     > Programming) but I don't think it's not a natural choice for most
>     > programmers and for all tasks..
>     >
>     > As for a state vs event based solution; I clearly think the
>     latter is
>     > more expressive; as you can derive state from events (a fold)
>     but not
>     > the other way around without relying on .. an event (the update to
>     > consult the state).
>     >
>     > Anyway still it's a matter of taste; we should strive for providing
>     > choice rather than dictature and help either case (when possible
>     :) ).
>     >
>     >
>     >
>     > On Fri, Jun 17, 2011 at 7:36 PM, Rob Fell [via Haxe] <[hidden
>     email]
>
>     > </user/SendEmail.jtp?type=node&node=6488371&i=0>> wrote:
>     >
>     >     Hi,
>     >
>     >     "awe6" features a UI abstraction: IInputManager
>     > http://code.google.com/p/awe6/wiki/ComponentInputs
>     >
>     >     It provides mouse, keyboard and "virtual" joypads using a
>     state / FRP
>     >     approach (rather than events) ... e.g:
>     >
>     >     is space pressed: IInputKeyboard.getIsKeyDown( EKey.SPACE
>     ):Bool
>     >     how long has space been pressed:
>     IInputKeyboard.getKeyDownDuration(
>     >     EKey.SPACE ):Bool
>     >     current mouse horizontal speed: IInputMouse.deltaX:Int
>     >
>     >     Might be useful (in part or full) if you like that style?
>     >
>     >     Best regards, Rob
>     >
>     >
>     >
>     >     On 11:59 AM, sledorze wrote:
>     >
>     > > I'm looking for solutions in order to unify mouse / keyboard (at
>     >     least)
>     > > management for our little project.
>     > > Any input welcomed (lol)
>     > >
>     > > Stephane
>     > >
>     > >
>     > > --
>     > > View this message in context:
>     >
>     http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6487864.html
>     > > Sent from the Haxe mailing list archive at Nabble.com.
>
>     > >
>     > >
>     >
>     >
>     >     --
>     >     haXe - an open source web programming language
>     > http://haxe.org
>     >
>     >
>     >    
>     ------------------------------------------------------------------------
>
>     >     If you reply to this email, your message will be added to the
>     >     discussion below:
>     >
>     http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6488062.html
>     >
>
>     >     To unsubscribe from Existing common input abstraction?,
>     click here.
>     >
>     >
>     >
>     >
>     > --
>     > Stéphane Le Dorze
>     >
>     > Tel: <a href="tel:%2B33%20%280%29%206%2008%20%C2%A076%2070%2015"
>     value="+33608767015" target="_blank">+33 (0) 6 08  76 70 15
>     >
>     >
>     >
>     >
>     ------------------------------------------------------------------------
>
>     > View this message in context: Re: Existing common input
>     abstraction?
>     >
>     <http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6488371.html>
>
>     > Sent from the Haxe mailing list archive
>     > <http://haxe.1354130.n2.nabble.com/> at Nabble.com.
>
>
>     --
>     haXe - an open source web programming language
>     http://haxe.org
>
>
>     ------------------------------------------------------------------------
>     If you reply to this email, your message will be added to the
>     discussion below:
>     http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6489510.html
>
>     To unsubscribe from Existing common input abstraction?, click here.
>
>
>
>
> --
> Stéphane Le Dorze
>
> Tel: <a href="tel:%2B33%20%280%29%206%2008%20%C2%A076%2070%2015"
> value="+33608767015" target="_blank">+33 (0) 6 08  76 70 15
>
>
>
> ------------------------------------------------------------------------
> View this message in context: Re: Existing common input abstraction?
> <http://haxe.1354130.n2.nabble.com/Existing-common-input-abstraction-tp6487864p6490603.html>
> Sent from the Haxe mailing list archive
> <http://haxe.1354130.n2.nabble.com/> at Nabble.com.

--
haXe - an open source web programming language
http://haxe.org