Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Window improvement  (Read 6712 times)

0 Members and 1 Guest are viewing this topic.

NoIdea

  • Full Member
  • ***
  • Posts: 149
    • View Profile
Window improvement
« on: October 30, 2010, 04:43:07 pm »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Window improvement
« Reply #1 on: October 30, 2010, 06:03:48 pm »
Hi

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

I don't see anything against it.

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

What do you mean?

Quote
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.
Laurent Gomila - SFML developer

NoIdea

  • Full Member
  • ***
  • Posts: 149
    • View Profile
Window improvement
« Reply #2 on: October 30, 2010, 06:12:32 pm »
Quote
I don't see anything against it.


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

Quote
What do you mean?


I mean like this in SDL.

Quote
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Window improvement
« Reply #3 on: October 30, 2010, 06:15:11 pm »
Quote
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.

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

Separate drawing and event handling in two separate threads.
Laurent Gomila - SFML developer

NoIdea

  • Full Member
  • ***
  • Posts: 149
    • View Profile
Window improvement
« Reply #4 on: October 30, 2010, 06:19:48 pm »
Quote
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 ?

Quote
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Window improvement
« Reply #5 on: October 30, 2010, 06:44:57 pm »
Quote
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.

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

Quote
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?

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

Quote
(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.
Laurent Gomila - SFML developer

NoIdea

  • Full Member
  • ***
  • Posts: 149
    • View Profile
Window improvement
« Reply #6 on: October 30, 2010, 06:52:31 pm »
Quote
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 ?

Quote

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 !

Quote
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Window improvement
« Reply #7 on: October 30, 2010, 07:03:07 pm »
Quote
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.

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

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

Quote
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.
Laurent Gomila - SFML developer

NoIdea

  • Full Member
  • ***
  • Posts: 149
    • View Profile
Window improvement
« Reply #8 on: October 30, 2010, 07:24:27 pm »
Quote
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).

Quote
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 !

Quote
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Window improvement
« Reply #9 on: October 30, 2010, 07:31:02 pm »
Quote
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).

Quote
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.
Laurent Gomila - SFML developer

NoIdea

  • Full Member
  • ***
  • Posts: 149
    • View Profile
Window improvement
« Reply #10 on: October 30, 2010, 07:44:58 pm »
Quote
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 ?

Quote
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Window improvement
« Reply #11 on: October 30, 2010, 08:09:41 pm »
Quote
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.

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

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

Quote
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?
Laurent Gomila - SFML developer

NoIdea

  • Full Member
  • ***
  • Posts: 149
    • View Profile
Window improvement
« Reply #12 on: October 30, 2010, 08:39:07 pm »
Quote
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 ?

Quote
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Window improvement
« Reply #13 on: October 31, 2010, 12:34:11 am »
Quote
How can I know the Callback function installed by SFML ?

Quote from: "Laurent"
that you get back when you install your own callback


Quote
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 ;)
Laurent Gomila - SFML developer

NoIdea

  • Full Member
  • ***
  • Posts: 149
    • View Profile
Window improvement
« Reply #14 on: October 31, 2010, 10:08:25 am »
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 ?

 

anything