To me, this is not a discussion about my particular application, but about the workings of SFML. I hope this is OK, and maybe even encouraged?
The reason I keep posting about this is not to annoy you, but because, the more I look at this, the more inconsistent it seems.
So to be able to use sf::Input, one would have to pop all the corresponding events in his event loop, even if he doesn't use them? That doesn't make sense.
I am not sure what you mean. Since one can't pick and choose which event type will be popped next, all of them will be popped in order, whether they are handled or not. You still need to pop "unused" events for sf::Input to work, as it is.
sf::Input is real-time while events are queued, so I can't do anything to force sf::Input to be synchronized with your own event handling, which could happen a long time after the event was actually triggered.
I will refrain from commenting on the first part of the sentence, since that is entirely up to the implementation, which is exactly what we're discussing. The second part, about your inability to ensure when the event handling takes place, seems equally true for both approaches, though.
Maybe the problem is that I don't understand the purpose of sf::Input completely, because I am less experienced, or maybe even not as clever as you. But it was this part of the documentation that gave me the the understanding that sf::Input could be used as a substitute for manually handling "is down":
A better strategy for this is to set a boolean variable to true when the key is pressed, and clear it when the key is released. Then at each loop, if the boolean is set, you move your character. However it can become annoying to use extra variables for this, especially when you have a lot of them. That's why SFML provides easy access to real-time input, with the sf::Input class.
When I read that I thought "Oh, wow! That is so cool!", because I too think it is annoying to have to bloat my program code with redundant bool values to see if a key is down. But as it stands, sf::Input does not free users from that task - at least not in all situations.
But even if you should happen to agree with me on all points, I understand why you might still be reluctant to change it: You might be breaking someone else's code, in ways I can't even begin to imagine, and you might be opening up a new can of worms in the form of new bugs to solve, when you really would rather get on with SFML 2.
So my recommendation still stands:
Document when sf::Input is unsuitable for handling "is down" in SFML 1, with the added recommendation that you also document that a proper GetEvent loop must be in place for sf::Input to work. This is not obvious from the documentation, and might lead a beginner to try handling events with sf::Input only.
Figure out a better, easier to understand approach for SFML 2. My personal wish would be for a true automatic "is down" bool substitute.
And lastly, thank you for taking the time to listen to my arguments. I hope you will appreciate and consider my input. I only took the time to put it forward because I appreciate SFML so much.
