push Events...

[eXpl0it3r]

The event processing should be reserved for system events and nothing more. As Laurent points out adding customization to it will make things only ugly and serve the people using it no big advantage, since the system will most likely still be limited for their needs.

A better and more common approach is to implement your own message bus and/or command pattern, that way you have the maximum flexibility to adjust things to your specific needs and you can easily feed the system events into the message bus - event fake system events.

[GraphicsWhale]

Why? Because I already have 7000 lines of c++-98 and I dont want to mix them with -11 just to have a lambda function. And also because I master -98 programming but never really got interested in the new stuff. But I will...

The only benefit to using C++98 over C++11 is support for outdated compilers.

Indeed it's exactly what I do.
The goal of this topic is to propose new features in the SFML library so people with the same needs dont have to write again and again the same thing on top of the library, right ?

Just adding a pushEvent function, and maybe adding a customizable field in the Event structure, would do the trick just fine

I disagree. SFML events should be used solely for events generated by SFML, not by the application.

Also, there is no clean way of doing customizable events. You're pretty much stuck with creating your own event system if you want custom events.

[cantor]

I have to disagree.

You have user data streams, you have custom audio streams, you have the capacity to create your own Drawable and Transformable object, I dont see any good reason why you shouldn't have custom events, or at least a smart way of making them - not involving reinventing the wheel every time.

[GraphicsWhale]

You have user data streams, you have custom audio streams

And it makes sense. Why limit the ability to load resources to just whatever kinds of files SFML can decode? The underlying APIs support it. It's also fairly easy to implement.

you have the capacity to create your own Drawable and Transformable object

Again, there's nothing about the underlying APIs (in this case, OpenGL) that prohibits custom shapes, and it's pretty easy to implement custom shapes.

I dont see any good reason why you shouldn't have custom events

What limitation is SFML imposing on you by not letting you create your own event type? And it's not like there's any demand for such a feature.

or at least a smart way of making them

What do you mean?

not involving reinventing the wheel every time.

It's really not too terribly difficult to implement a simple event system. There is no clean way to achieve what you want, so you'd be much better off making your own anyways.

[Laurent]

Then show us this "smart way" please

[cantor]

I disagree. SFML events should be used solely for events generated by SFML, not by the application.

What, no... Look at my second post, the HandleHOTAS class, what is wrong with it ? Even Laurent said he would do the same if I understood right. A click is a click. I see nothing wrong.

Maybe what you really mean is to use the internal std::queue<Event> for internal events only.

[GraphicsWhale]

A click is a click. I see nothing wrong.

SFML's event system is simply to forward events from the OS to your application. If you want to support some non-standard device as well, you're going to have to create your own event system.

Plus, and I have yet to see any suggestions yet, how could you possibly go about implementing such as a feature? For custom events, the size of sf::Event needs to be known when SFML is being compiled, which means we aren't left with many options (and all of the options are sub-optimal). And I can't see any realistic use of pushing an event such as MouseButtonPressed/MouseButtonReleased, which would make real mouse clicks and controller "mouse clicks" ambiguous, which is also a bad idea.

[cantor]

A click is a click. I see nothing wrong.

SFML's event system is simply to forward events from the OS to your application. If you want to support some non-standard device as well, you're going to have to create your own event system.

Plus, and I have yet to see any suggestions yet, how could you possibly go about implementing such as a feature? For custom events, the size of sf::Event needs to be known when SFML is being compiled, which means we aren't left with many options (and all of the options are sub-optimal). And I can't see any realistic use of pushing an event such as MouseButtonPressed/MouseButtonReleased, which would make real mouse clicks and controller "mouse clicks" ambiguous, which is also a bad idea.

For non-standard devices, a RenderWindow::pushEvent (Event &) is all that is necessary.


For Custom Events, you have multiple solutions :

1) Add a Event::UserEvent enum , a void *userData field, which is deallocated in the ~Event destructor.
 Then you just need to event.userdata = static_cast<void*> new MyEvent (stuff); I agree it's not very sexy.


2) Make "Event" a template parameter. Constraint this template parameter to be a subclass of Event (this can be done even with C++-98). This is not an easy solution in a library though

[Nexus]

As mentioned, the sf::Event queue carries operating system events only. The sf::Event type itself was never conceived to be filled by users, let alone be extensible for custom events. The existing interface gives you certain guarantees and invariants¹. Loosening it, or worse, bloating both the sf::Event and the sf::Window APIs in order to support user-defined events is not only a bad idea because it adds complexity most users won't benefit from², but also because there's no reasonable way of bringing custom events to a common denominator. The proposed void* + cast + dynamic allocation approach is very ugly, not type-safe and slow. Everybody can write that better, but one needs to know the concrete use case, which SFML is too abstract for.

_________
¹ sf::Event guarantees which union members can be read, depending on the value of the type member.
² Those who did benefit could easily write a wrapping queue themselves -- knowing the STL, it's a trivial task done in a matter of minutes. And one gains much more flexibility than any solution built into SFML.

[GraphicsWhale]

1) Add a Event::UserEvent enum , a void *userData field, which is deallocated in the ~Event destructor.
 Then you just need to event.userdata = static_cast<void*> new MyEvent (stuff); I agree it's not very sexy.

That solution is too.. C-ish.

2) Make "Event" a template parameter. Constraint this template parameter to be a subclass of Event (this can be done even with C++-98). This is not an easy solution in a library though

The problem here is that that would require either:

- Your custom event structure to be compiled alongside the SFML source.
- Any SFML source that uses the event structure to be moved into header files.

[Jesper Juhl]

+1 @Nexus.

[cantor]

Okay then.. Let's do nothing at all! 

Maybe this awsome library is awesome as it is

[Jesper Juhl]

Some things you could look at:

The Thor Input module.
D-Bus.
libsigc++.
Qt signals and slots.

[eXpl0it3r]

Well since you're not willing to use modern C++, you'll pretty much do a lot of hard work and write ugly code.

[SeriousITGuy]

Safe yourself the hassle and just use Sigc++. I wanted to write something similar the last months and it was a big pain. Then I found Sigc++ and I am happy with it.