New global inputs in SFML 2

[Nexus]

One looking for mouse coordinates would look first for the Mouse class than for the Window. It's expected that mouse stuff is obtained from the Mouse class.

sf::Window::GetCursorPosition() is the counterpart to sf::Window::SetCursorPosition(). So you needed to put that into sf::Mouse, too. sf::Mouse would be connected with sf::Window, although it is intended to represent the global state.

[Laurent]

I would return true as long as the cursor is in the window and the button is pressed.

Fine, but then it's slightly more complex than what sf::Input did.

Consider a shooter: As long as the left mouse button is held down, the player fires. When he clicks somewhere outside the window (for any reason), this shouldn't trigger the weapon. You can't work with events here unless you store bool flags on your own.

Working with events and flags is a common technique, now it's just that SFML no longer does it for you.
In this situation, I think the programmer will rather track the focus events to disable many other things in the game when the window loses focus, so there's no problem in fact.

That's what I thought too, but then, people will always use sf::Window::GetCursorPosition() and sf::Mouse::GetPosition() is hardly ever used.

I could use it in the Shader example

And as you stated, it is not optimal with respect to the symmetry, if people still need the window to get the mouse state, but not the keyboard or joystick state.

So... no solution?

[Nexus]

Fine, but then it's slightly more complex than what sf::Input did.

Wasn't sf::Input at least intended to behave like this (but maybe due to the sf::Event background, there were technical deviations, not to say bugs)?

Working with events and flags is a common technique, now it's just that SFML no longer does it for you.

We're spoiled, I know

In this situation, I think the programmer will track the focus events to disable many other things in the game when the window loses focus, so there's no problem in fact.

Maybe I should do that too in Thor. I could manually look for focus events and stop the realtime input if the window has no focus. If people want to react to input outside the window, they can still complain, this should be easily configurable. Relying on the user-side handling of focus events is not a good idea when callbacks are involved, because then every listener function would have to check if the call is valid.

I don't know how well you know my Action system, but the intention is to make it easy for the user to react to both one-time events and "realtime events" (that is, a condition of a realtime state is true).

So... no solution?

It seems like sf::Mouse::GetPosition() only for global state would be the cleanest solution, but be prepared for tons of questions "why doesn't this return the mouse position?"

But I'll spend some more thoughts on it... In case I have another idea (unlikely), I would inform you

[gsaurus]

One looking for mouse coordinates would look first for the Mouse class than for the Window. It's expected that mouse stuff is obtained from the Mouse class.

sf::Window::GetCursorPosition() is the counterpart to sf::Window::SetCursorPosition(). So you needed to put that into sf::Mouse, too. sf::Mouse would be connected with sf::Window, although it is intended to represent the global state.

And instead, we have window connected to Mouse.
I still don't like those cursor methods on the Window  :roll:, it's a bit out of context. I personally would prefer to have get/set position on Mouse, with overloading to make it relatively to a window.

As alternative I though on something like TransformToLocal  & TransformToGlobal instead of those Get/SetCursorPosition. This way Window becomes independent of the Mouse, and Mouse can stick with global independent coordinates.
The drawback is requiring an extra step to get window mouse coordinates.

[Nexus]

I still don't like those cursor methods on the Window  :roll:

You are right, users probably associate mouse and cursor functionality first with sf::Mouse.

As alternative I though on something like TransformToLocal  & TransformToGlobal instead of those Get/SetCursorPosition.

Or just sf::Window::GetPosition(). There is already a SetPosition(), anyway.

[Laurent]

Wasn't sf::Input at least intended to behave like this (but maybe due to the sf::Event background, there were technical deviations, not to say bugs)?

sf::Input was meant to record/accumulate what happens with events. It was never supposed to adjust states according to what happened unfocused, but... yeah in the end it just looked buggy

But I'll spend some more thoughts on it... In case I have another idea (unlikely), I would inform you

Thanks!

I still don't like those cursor methods on the Window  , it's a bit out of context. I personally would prefer to have get/set position on Mouse, with overloading to make it relatively to a window.

That sounds good indeed... maybe I should try this direction. What I don't like is that something specific to a window would have to be specialized (I'm talking about the OS specific imlpementation) in sf::InputImpl (the backend of sf::Mouse) instead of sf::WindowImpl, like all other window-related functions. But yeah, it's an internal detail.

As alternative I though on something like TransformToLocal & TransformToGlobal instead of those Get/SetCursorPosition. This way Window becomes independent of the Mouse, and Mouse can stick with global independent coordinates.
The drawback is requiring an extra step to get window mouse coordinates.

It's an interesting concept as well, but in the end I don't think it would be a good solution.

Or just sf::Window::GetPosition(). There is already a SetPosition(), anyway.

If you mean "window cursor = global cursor + window position", then you'd get wrong results because it wouldn't take the window decorations in account.

[Nexus]

That sounds good indeed... maybe I should try this direction.

I also think this is a good solution. To make it clear, you could provide differently named functions instead of overloads:

Code: [Select]

static Vector2i GetPosition(const Window& relativeToWhich);
static Vector2i GetDesktopPosition();

What I don't like is that something specific to a window would have to be specialized (I'm talking about the OS specific imlpementation) in sf::InputImpl (the backend of sf::Mouse) instead of sf::WindowImpl, like all other window-related functions. But yeah, it's an internal detail.

You could still make a private function in sf::Window and call it from sf::Mouse. You need a friend, but compared with the alternative, this seems like an acceptable price to pay

If you mean "window cursor = global cursor + window position", then you'd get wrong results because it wouldn't take the window decorations in account.

True, that just came into my mind, should have thought about it more

[Tronic]

The way I see it (application programmer POV), there should be two modes:

Mouse pointer mode:
- Used when the user needs to point and click things
- The pointer behaves normally
- A function to get the pointer position (desktop coordinates, e.g. 0x0...1920x1080)
- A function to get the pointer position within the window (possibly negative or greater than the window dimensions, and may not always correspond 1:1 to desktop pixels, consider e.g. compositing WMs)
- Different cursors possible for different windows/areas (handled by the GUI)
- ButtonPress and other such events that store the pointer position at the time the event occurred (necessary for precise clicks)

Relative motion mode:
- Used in FPS games and with various GUI widgets (e.g. draggable spinctrls)
- Cursor hidden (or doesn't move)
- A function to get the number of dots the mouse has moved since the last time it was read
- When switching back to pointer mode, the cursor is made visible at the position where it was before switching to relative movement

In an ideal case dots are much more precise than pixels: 2000 DPI mice are common but a few people would want just one inch of movement to move the cursor all the way across the screen and more. Also, there is no acceleration nor smoothing applied to dots, where pixels are suspect to the usual Xorg/Windows/OSX processing. This also has implications when touchscreens or other such input devices are used.

[Laurent]

I've implemented the new Mouse::Set/GetPosition functions, and removed Window::Set/GetCursorPosition.

[Groogy]

And I've already committed the wrap for it to rbSFML  

I'm on FIRE!

[Nexus]

Sounds good! I think I can now begin with the adaption of my Action system.

You chose the overload of GetPosition() instead of a more clear GetDesktopPosition()... Don't you think this might confuse users, especially beginners that expect the mouse position to be relative to the the window, when they use the most simple call sf::Mouse::GetPosition()?

[Laurent]

You chose the overload of GetPosition() instead of a more clear GetDesktopPosition()... Don't you think this might confuse users, especially beginners that expect the mouse position to be relative to the the window, when they use the most simple call sf::Mouse::GetPosition()?

That will be a good test to see if users read the doc

[Nexus]

That will be a good test to see if users read the doc

You already know the test result, don't you?
But in the end, your forum is flooded with beginner questions

Just thought it is never a bad idea to make the interface expressive enough, so that the documentation need only be considered in case of doubt.

[Laurent]

I agree.

Maybe I'll think about it again in a few weeks (people will hate me if I change the same code everyday).

[Groogy]

(people will hate me if I change the same code everyday)

People like me? :twisted:

Though I would be a bit annoyed because if you overload a function like that then I have to mimic that polymorphism by using variable length argument on the bindings method... And that is a lot trickier than just simply wrap a function. And if you then on the same day would change that to a not overloaded function. That would mean my hard work would be for nothing... Yeah... hate is a good word