Currently all the Reflex haddock links are broken. Figure out how to fix the haddock linking so it points to the correct place (maybe this simply requires Reflex 0.5 to be released).

Currently animation is supported by supplying sysTicksEvent, which when subscribed to fires a tick event every frame. This is pretty wasteful, especially for UI things that only need to update once every 1/12th of a second. It would be great to have a function like:

newClockEvent 
  :: ReflexSDL2 t m 
  => Word32 
  -- ^ The frame rate of the timer/clock event. The event
  -- will fire every accumulation of this many milliseconds.
  -> m (Event t ())

We shouldn't expect users to pack their reader data into r of ReflexSDL2T r t m.
Instead we should hide the SystemEvents reader, write Class.hs and Base.hs
modules - like MonadSDL2 or something.
See src/Reflex/SDL2.hs line 160

• Opened on trigger-event
• Closed on no-more-user-data
• Closed on trigger-event
• Closed on master

TLDR: The overly loose bounds are fixed in the newer versions of the library but they need to be fixed in 0.1.0.0 as well through a hackage metadata revision to stop Cabal from generating faulty build plans and giving users a bad time.

reflex-sdl2 0.1.0.0 is missing version bounds. This may be fixed in later versions, but this still causes issues.

Cabal will still try to build 0.1.0.0 when a user hasn't explicitly asked for newer versions and cabal fails to generate build plans for newer versions.

For example, right now Cabal can't generate a build plan for reflex-sdl2 0.3.0.0 on GHC 9.2.4
Ordinarily when a new GHC version comes out and a library needs to bump bounds to get things working again, all versions of the dependency fail to build on the new GHC version, but because of the loose bounds on 0.1.0.0, versions 0.2.0.0 and 0.3.0.0 fail but Cabal can see no reason why 0.1.0.0 should fail, so it generates a build plan that includes incompatible dependency versions (because the bounds are too loose to exclude them) leading to opaque dependency compilation errors for the user.

It took me a while to notice that Cabal was trying to build 0.1.0.0 and then due to similar past experiences I figured it out. For a less experienced person they may chalk it up to a fundamentally broken library and give up.

Loose bound issues have to be fixed retroactively through Hackage revisions.

There do not seem to be any compatibility issues for this library between 0.5 and 0.6, with there only being a depreciation of MonadDynamicWriter in Main.hs, however, this is not an issue for using the package as a library

Some updates were made to the stack config that require 2.3.0 to avoid a bug compiling on windows. We need to bring the nix config up to parity. @dalaing can you take this? Or guide me through the process? Thanks :)

The dependency upper bounds are getting a touch old.

I tried to build under GHC 9.2.4 but couldn't get a build plan. However when compiling with --allow-newer everything compiled without issue.
I haven't tested, so it isn't certain to actually work with --allow-newer on, but still it's a promising sign that the only issue may just be over-restrictive bounds.

I think there are a lot of opportunities to wrap sdl2 functions in Dynamic or Eventful versions. For example there are all the window attribute getter/setter functions that could be done this way.

I'm not 100% sure this is where I'd like to go, as the library user could decide not to use that stuff - and then it becomes cruft. So ¯_(ツ)_/¯

Hey there. So because I wasn't able to use delay like I suggested in another issue, I came up with a new way to measure the FPS of my game.

Whenever the function getRecurringTimerEventWithEventCode is used in my code, I believe that an event is created that continues to fire even after I have quit SDL and my renderers etc. I know it is this function, because A: replacing the event with never (or any other event) stops this behaviour and B: changing the interval time manipulates the speed at which messages are posted to my terminal.

I expect that the messages are caused due to my functions of the game still firing even after it has closed, and that because SDL is no longer running I can no longer render anything, however, even if I use the event for absolutely nothing and simply bind it I continue to get messages about the video subsystem. Simply using this function is causing these messages, and so I cannot even gate the event to stop things happening after the program has closed as it's the event itself that's the problem.

Thanks!

There should be a v0.1.0.0 tag at 8f7f554, to make it easier to see what’s changed here since the version on Hackage, if nothing else.

Maybe move CI to gitlab?

Just a quick one, I think that it'd be very helpful if Reflex-SDL allowed Trigger Events so that I could call the standard Reflex function delay. I know that reflex-sdl has it's own implementation, but it's not the easiest to use.

Thanks!

Then we can remove this from here, since it's provided by reflex itself.
See src/Reflex/SDL2.hs line 114

• Opened on trigger-event
• Found on no-more-user-data
• Closed on no-more-user-data
• Found on master
• Closed on trigger-event
• Closed on master