Separating event generation and the window.

[Lolilolight]

Hi, with SFML this is the window which produce events, but what if the application have no window.

We are forced to create an invisible window to get events and if we have multiple windows we are forced to call the pollEvent function twice instead of once.

You intend to manage multiple windows screens, so, I think it should be good to separate events generation and the window like SDL does.

[Lo-X]

I don't get why you need events if you have no windows. I don't even see how such a thing is possible. An event without a related window is just like pedals if you don't have a bike.

[eXpl0it3r]

All events are related to a window. Mouse or keyboard events only happen within the window. Resize and focus events are only for the window.
As such, this suggestion makes no sense.
That the joystick events act slightly different has its own reason.

For keyboard, mouse and joystick we have dedicated classes.

If you want a callback system, then this an entirely different request.

Better state what you actually want, instead of the useless "like library XYZ does".

[Lolilolight]

No, you can use your keyboard on a console to type commands, you can also use your mouse to copy or past text for exemple, they are not related to the window so. x)
Only resize, close, lostFocus, gaignedFocus, mouseEntered, mouseLeft, ... are related to the window.

[Laurent]

No, you can use your keyboard on a console to type commands, you can also use your mouse to copy or past text for exemple, they are not related to the window so

These events are related to the console window... Typing or pasting text only makes sense in a window.

Anyway, instead of arguing, explain why you request this feature.

[Lolilolight]

I want to get events from the console.

[Laurent]

And...? Please explain what you want to do.

[Gambit]

Provide usage cases. You could very well be wanting a feature that you do not need, nor would benefit SFML as a whole.

[Lolilolight]

I've a game with no window (for exemple) just the console, a snake by example, and I want that if I press a key, the snake change of direction.

PS : It can be a console or another window type from another os, no matter what.
The only thing we can do  now is to recreate another classe for window and events. (I think event's are depending on the OS, not on the window or the console, right ?)

So I suggest to get event directly from the os and not from the window to have only one responsability for the window and one responsability for the event collector.

[Hiura]

If you have a console you have a window.... SFML is not ncurses. Have a look at http://ndk-xx.sourceforge.net/ instead.

[Grimshaw]

Yeah, use a multimedia library to make a console game makes sense. If you want to make a console game with SFML, then make a custom console with a proper RenderWindow so you can leverage all SFML features.

[Laurent]

I've a game with no window (for exemple)

Ok so you don't have any use case for this feature, and opened this thread just to say something?

So I suggest to get event directly from the os

And how do you think you can get events from the OS? With a window.

[Lolilolight]

Ok so we always need a window to get events, you can't create two different classes for the window and for the events.

Arf. :/

I'm actually coding a engine and, I want to respect the principe of "single responsability for each class", so, I want to have two interfaces (instead of one), one to generate events and another to display the window.

[Nexus]

I'm actually coding a engine and, I want to respect the principe of "single responsability for each class", so, I want to have two interfaces (instead of one), one to generate events and another to display the window.

If only the logical structure is the concern, you can still separate responsibilities:

// Your rendering interface
class Renderer
{
public:
    explicit Renderer(sf::RenderWindow& window);
    void Draw(const GameObject& obj);
};

// Your user-input interface
class Input
{
public:
    explicit Input(sf::Window& window);
    void PollEvents();
    void RegisterCallback(...);
};

[Hiura]

You know, those theoretical principles are nice on paper but sometimes you have to put them aside if you don't want a super complex design. If you split every interface to an atomic set of operations you'll end up with huge interface boundaries and a lot of interdependencies.

Make yourself a treat for Christmas : http://www.amazon.com/The-Deadline-Novel-Project-Management/dp/0932633390