Show Posts
1
Feature requests / Re: Custom made event handling
« on: June 24, 2019, 10:46:42 pm »
Hi, I like the same feature. 
It is obvious that I need it due to the fact that window control (event-handling & window-update) should be in one thread, afai-understand; for MAC-OSX it must be also the thread of the main-function (afaiu too).
If this is so and I do not want to poll for SFML-events, I cannot react on other events than the SFML given one; I cannot react on timeouts for instance (precondition: using API function sf::Window::waitEvent() ).
afai-see this function is the only way to give time/control fully back to the OS; this is - in my opinion - the best way to save process-time and have a full event driven system/process-program.
But if I can't wake up this by myself (other thread, e.g. via timeout), it could not work fully by using the waitEvent() function.
I - as many others too which I assume - would like to handle SFML in that way. It only needs a user-specific signal-event for instance, may be more than one event (e.g. with user-event-id) and "waitEvent" should be come back, if this is called - thread-save, because this must be done by another thread of course.
Hope I do not have some fully misunderstandings.
Thanks if you understand me and my wishes belonging to an event-driven thread. (It may be similar like wait for multiple events in a select() function of linux/POSIX).
It is obvious that I need it due to the fact that window control (event-handling & window-update) should be in one thread, afai-understand; for MAC-OSX it must be also the thread of the main-function (afaiu too).
If this is so and I do not want to poll for SFML-events, I cannot react on other events than the SFML given one; I cannot react on timeouts for instance (precondition: using API function sf::Window::waitEvent() ).
afai-see this function is the only way to give time/control fully back to the OS; this is - in my opinion - the best way to save process-time and have a full event driven system/process-program.
But if I can't wake up this by myself (other thread, e.g. via timeout), it could not work fully by using the waitEvent() function.
I - as many others too which I assume - would like to handle SFML in that way. It only needs a user-specific signal-event for instance, may be more than one event (e.g. with user-event-id) and "waitEvent" should be come back, if this is called - thread-save, because this must be done by another thread of course.
Hope I do not have some fully misunderstandings.
Thanks if you understand me and my wishes belonging to an event-driven thread. (It may be similar like wait for multiple events in a select() function of linux/POSIX).