Custom made event handling

[Meteorhead]

I think many people would welcome the idea of a custom made messages could be passed to threads constructed from sf::Thread. sf::Window can accept messages coming from the OS, react to them, and also put the controlling thread to sleep until a message arrives.

Would it be possible to have an sf::EventHandler class, that is practically this functionality, only without a window (so practically not making a hidden window, only for a message handler), and be able to pass messages between threads, with the possibility of puting one thread to sleep until it recieves a custom message?

By custom messages I mean templated events (or any type of event that allows custom data to be carried along with it) that the user can use as he/she sees fit.

This would be the basis of proper event-based application design.

So far the event system is only usable for OS-window communication.

[Nexus]

Don't you look for something like Boost.Signals2?

[Laurent]

And why would it have to be in SFML rather than in user code? This is a very specific feature, and not related to multimedia programming.

[kaa#rad]

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

[Nexus]

Please open new threads for new features, instead of necromancing one that had its rest for 7 years.

It's not clear what you're looking for -- is it a separate thread for event handling, or a timeout for wait(), or something else? You don't describe any use case, but you assume what you want to achieve is only possible with one specific implementation.

Polling from one thread is not a real limitation, as you can easily pass SFML events to other threads for processing (e.g. using message queues).