SFML community forums
General => Feature requests => Topic started by: phoenix4sfml on January 14, 2016, 05:12:13 pm
-
Haven't seen this asked for before... so here goes: how about the events code being expanded to include window movement events?
What do users think of this feature proposal?
I.e.:
- Add an enum entry to Event.hpp like Moved.
- Rename MouseMoveEvent to MoveEvent.
- Use MoveEvent for MouseMoved and Moved event types.
- Adding code to dispatch these new window moved events to the event retrieving methods of the Window class and any other appropriate places.
I realize I can get window position information and still react to window movement but having it be part of the normal events system/mechanism seems more elegant. Thank you.
-
The question is not really how to implement that, but simply: why? Do you have a use-case? If not, that's probably why it wasn't asked for before. ;)
-
That would not be possible under Windows (at least), because the calling thread is blocked until the move is done (same for resize). So basically you would get all the Moved events at once after the move is done.
-
...Do you have a use-case?...
Hi Hiura,
Thanks for asking.
My use case for this is having a window that's like a tank partially full of water. When the window moves, I want the water to move too - sloshing back and forth - like it were water in a tank that just got moved.
In this case, a perfect simulation - while it'd be nice - isn't necessary. So even if the underlying window management doesn't provide a real-time (or close to real-time) stream of movement events, just getting the final move delta is enough.
It was easy for me to code around not having these window-moved events, but I'd prefer using the event model supported by window.pollEvent() if it delivered these.
Is there a desire on the part of SFML development to move away from event-driven programming? I ask because maybe there's a more preferable paradigm. If not, then I'm curious to understand why there may be any resistance to expanding the SFML event model.
I'm not familiar with what Microsoft Windows provides in the way of window-movement information but at least in the X Window System there's the XConfigureEvent that apparantly provides this kind of event notification for window moves. No idea if X Window System developers later saw that as a mistake though.
Thanks again.
-
Hi, Phoenix4sfml!
It is possible to use events with the movement of the window but not with OS window movement. Have you considered allowing the window's client area to be dragged to move the window (or just use a dragable borderless window (http://en.sfml-dev.org/forums/index.php?topic=14391.msg101187#msg101187))?
-
Hi Hapax,
I do believe that the SFML events framework could be expanded to handle window movement and that this would be attractive even if only a single movement event was generated at the end of the window being moved.
As mentioned, I did work around not having window movements handled through the Event mechanism and I did it similarly to the code you'd linked. So my post isn't about whether window movements can be handled at all, but whether the SFML Event code (and paradigm) should be expanded to include window movements as events also.
Under Mac OS X (at least in the release I'm running), window repositioning isn't detectable through the Window::getPosition() method until after movement has stopped (whether by pausing a mouse drag or by releasing it). This sounds similar at least to what Laurant describes is the behavior under Windows.
I don't see the lack of detectability of intermediate movements as a strong enough argument against including window movement in the SFML events code. I do however see this behavior as worthy of documenting with verbiage like:
Note: event generation is operating environment dependent. Some platforms have sensors for which sensor events can be handled while others do not. Other events may have similar dependencies.
-
I do believe that the SFML events framework could be expanded to handle window movement and that this would be attractive even if only a single movement event was generated at the end of the window being moved.
I think a compounded WindowMoved event being generated when the window is released wouldn't go amiss but how often does a SFML application need to know when its outer window has been moved; its output probably wouldn't be any different.
However, just using getPosition() - as you mentioned - could be used to do this anyway.
This event-at-end-of-movement, however, does not apply to your original use-case example as that would need real-time feedback. Do you have one for this?
It may be possible to use getPosition() in a separate thread to get real-time feedback.