Window improvement

[NoIdea]

Hi all, I would like to propose one more Function for sf::Window and a few more Event :

It would be nice to be able to change the style without recreating the window : to have something like :

void sf::Window::ChangeStyle(sf::Style);

Furthermore, it would also be appreciated to have something like system specific events.

Would it be possible to improve ResizeEvent and have a function EnableResizeRepeat(bool); ?

This function would enable Resize Event to be emitted even when the window is not already completely resized.
I've already talked about that on a other forum and it seemed there were technical difficulties but thanks to threads they might be avoidable :

Laurent told me that windows blocks the process when the window is sizing.

Would it be possible to have these features for SFML2 ?

[Laurent]

Hi

void sf::Window::ChangeStyle(sf::Style);

I don't see anything against it.

Furthermore, it would also be appreciated to have something like system specific events.

What do you mean?

Would it be possible to improve ResizeEvent and have a function EnableResizeRepeat(bool); ?

This function would enable Resize Event to be emitted even when the window is not already completely resized.
I've already talked about that on a other forum and it seemed there were technical difficulties but thanks to threads they might be avoidable

No, it's not possible. Threads are not an option if you talk about handling it internally. Only user code can work around this limitation.

[NoIdea]

I don't see anything against it.

Perfect : We won't see the window being recreated when it is just the style that changed.

What do you mean?

I mean like this in SDL.

No, it's not possible. Threads are not an option if you talk about handling it internally. Only user code can work around this limitation.

Do you know how ? I searched and couldn't find anything.

[Laurent]

I mean like this in SDL.

Ok. So my answer is no
Unless you tell me why you need it, and maybe then it would be better to officially add the missing events to sf::Event, rather than providing raw access to system specific events.

Do you know how ? I searched and couldn't find anything.

Separate drawing and event handling in two separate threads.

[NoIdea]

Separate drawing and event handling in two separate threads.

What if I want to do something else when the window starts resizing ? Do you have a link that would explain how windows blocks the process ?

Let's suppose I wanted to pass to fullscreen as soon as the user starts resizing the screen, how could I achieve that ?

Ok. So my answer is no Smile
Unless you tell me why you need it, and maybe then it would be better to officially add the missing events to sf::Event, rather than providing raw access to system specific events.

What about WM_COPY Message could'nt that be delt with inside SFML, or even timer messages...
This kind of event permits the user to get Events that do not neccesarily have to do with the window to deal with them at the same time (it would be a waste to add another test with TranslateMessage and Dispatch message for nothing).

[Laurent]

Do you have a link that would explain how windows blocks the process ?

No, but it's probably a while loop that calls the window's event callback until the resize operation is finished.

Let's suppose I wanted to pass to fullscreen as soon as the user starts resizing the screen, how could I achieve that ?

I don't know, maybe you should investigate further on your side and see what's the best solution, and what could be added to SFML to help you implement this solution.

What about WM_COPY Message could'nt that be delt with inside SFML, or even timer messages...

There are tons of messages, but most of them are irrelevant. Do you actually need these events, or are they just random examples?

This kind of event permits the user to get Events that do not neccesarily have to do with the window to deal with them at the same time

But it's not portable, and OS-specific messages can be very hard to handle. If users need a more complete windowing system, they can use Qt or similar libraries.

(it would be a waste to add another test with TranslateMessage and Dispatch message for nothing)

You don't need to run a separate event loop on your side. You can subclass the window, which means inserting your own event callback into the events chain.

[NoIdea]

No, but it's probably a while loop that calls the window's event callback until the resize operation is finished.

Does this mean we can register a callback function ? If so, how ?

There are tons of messages, but most of them are irrelevant. Do you actually need these events, or are they just random examples?

These are random examples that could be used : Even in regular Textbox, there is a copy and paste function.
I don't really see why it shouldn't be implemented and in some cases it might be usefull :
-It's only one Event so it will not messy the API
-It is very easy to implement.
-It can even be usefull for a Textbox !

You don't need to run a separate event loop on your side. You can subclass the window, which means inserting your own event callback into the events chain.

Didn't really get that, but I guess that by searching, I'll find out...

[Laurent]

Does this mean we can register a callback function ? If so, how ?

At low-level, you catch a window's events with a callback that the OS automatically calls when something happens. SFML has its own callback internally, then it translates the messages to sf::Event and store them until you call GetEvent.
See below for registering your own callback.

These are random examples that could be used : Even in regular Textbox, there is a copy and paste function.

SFML is not really made for that purpose. Like I said, there are other windowing APIs much more complete.

I don't really see why it shouldn't be implemented and in some cases it might be usefull :
-It's only one Event so it will not messy the API
-It is very easy to implement.
-It can even be usefull for a Textbox !

It's easy for me, but then it's so complicated for users.

Didn't really get that, but I guess that by searching, I'll find out...

Every window has an event callback attached to it, to which it can send its events. It's easy to setup (one call). SFML windows already have an event callback, which is attached by SFML to catch the windows events and translate them to sf::Event. But you can install your own callback between the window and the SFML callback, that's what SFML does when you pass an external window (a window that SFML didn't create): it still has its original event callback, plus the SFML one. If you're interested I can show you how to do it.

[NoIdea]

At low-level, you catch a window's events with a callback that the OS automatically calls when something happens. SFML has its own callback internally, then it translates the messages to sf::Event and store them until you call GetEvent.

I only found DefWindowProc and haven't completely understood it all (if I understand well it permits you to register a function that will process all Events and not a specific event).

It's easy for me, but then it's so complicated for users.

But what if some users ask for it ?! It won't even messy the public API !

Every window has an event callback attached to it, to which it can send its events. It's easy to setup (one call). SFML windows already have an event callback, which is attached by SFML to catch the windows events and translate them to sf::Event. But you can install your own callback between the window and the SFML callback, that's what SFML does when you pass an external window (a window that SFML didn't create): it still has its original event callback, plus the SFML one. If you're interested I can show you how to do it.

I'm quite interested thanks for spending so much time.

[Laurent]

I only found DefWindowProc and haven't completely understood it all (if I understand well it permits you to register a function that will process all Events and not a specific event).

DefWindowProc is the default event callback, the one that you must call from your own event callback when you're not interested in the event, to let the OS do its job.
An event callback is attached to a window when creating its class (WNDCLASS), with the lpfnWndProc member. If you want to insert your own event callback after the window is created, use SetWindowLongPtr with the GWLP_WNDPROC flag; and don't forget to call the initial event callback in your own one (instead of DefWindowProc).

But what if some users ask for it ?!

I'm waiting. I mean, for someone who really needs it of course
I'll never add a feature that might be useful in the future.

[NoIdea]

DefWindowProc is the default event callback, the one that you must call from your own event callback when you're not interested in the event, to let the OS do its job.
An event callback is attached to a window when creating its class (WNDCLASS), with the lpfnWndProc member. If you want to insert your own event callback after the window is created, use SetWindowLongPtr with the GWLP_WNDPROC flag; and don't forget to call the initial event callback in your own one (instead of DefWindowProc)

If I understand well, I need to add another function that will be called for each Event ? This function will then check if it is a WM_SIZING message (and call whatever function I want) and if not it calls the DefWindowProc ?
Isn't this system a bit heavy just to get one message ?

I'm waiting. I mean, for someone who really needs it of course Smile
I'll never add a feature that might be useful in the future.

I do if I don't want to check CTRL + C by myself ... There's a way around it by checking if both keys are pressed and then deal with it...but it so much simpler using the OS.

[Laurent]

If I understand well, I need to add another function that will be called for each Event ? This function will then check if it is a WM_SIZING message (and call whatever function I want) and if not it calls the DefWindowProc ?

Yes, except that you don't call DefWindowProc, but the callback installed by SFML (that you get back when you install your own callback). Otherwise SFML will not catch any event.

Isn't this system a bit heavy just to get one message ?

Why? It's just an extra indirection, there nothing heavy there.

I do if I don't want to check CTRL + C by myself ... There's a way around it by checking if both keys are pressed and then deal with it...but it so much simpler using the OS.

So you're saying that you do need to handle the copy event?

[NoIdea]

Yes, except that you don't call DefWindowProc, but the callback installed by SFML (that you get back when you install your own callback). Otherwise SFML will not catch any event.

How can I know the Callback function installed by SFML ?

So you're saying that you do need to handle the copy event?

Yes, but not the timer. But there might be someone who will want to handle the timer event and not the copy event...


Forgot to ask, is there the same problem with linux when resizing the window ? If so, how can I deal with it ?

[Laurent]

How can I know the Callback function installed by SFML ?

that you get back when you install your own callback

Forgot to ask, is there the same problem with linux when resizing the window ? If so, how can I deal with it ?

I think so. Same solution as Windows

[NoIdea]

Thank you very much. I'll try that. Just thought of it, what are the technical limitations if you made a function that took a functor that would be executed when WM SIZING is emitted ?
In that case, the process wouldn't be blocked. Can this be a solution ?