Comment 11 for bug 726978

> I was not aware you do not welcome critical discussion
> about reasoning behind design decisions.

It didn't sound like a critical discussion to me - it sounded like you pulling more random thoughts about why your opinion is right out of thin air. There was a LOT of text, and not a lot of it was directly relevant to solving the issue at hand. Being concise and to the point is generally more effective than writing a 700 word essay in a comment. :)

Regardless of your intention, my point remains - both parties here have already made it clear what their opinions are, so until something is actually /done/, rehashing these ideas more is unlikely to be helpful.

> I warmly welcome your thoughts about the kind of research
> you would expect to get done on a question like this.

- A list of the 'most popular' music players that would be relevant to this discussion. I think we should concentrate on linux-based ones but it may be worth looking at some examples from windows and mac as well.
- For each of these players, examine:
-- What sort of shortcuts are set for playback controls when the window is focused. i.e. what keys are used, how are they sensitive to context, and how do they deal with interactions with other widgets like textboxes that may already have defined behaviors for them.
-- Whether these bindings override default behaviors or best practices on the platform/toolkit the player utilizes, and how the loss of functionality, if any, is compensated for, if at all.
-- How the player addresses or fails to address any usability/accessibility concerns that arise from such bindings and/or overrides.

That should give us an idea of "usual behavior", as you put it, along with any potential problems that might come up and their solutions.

This still doesn't address the coding side of things - unless there's some way to do this in code without having to manually attach bindings or exceptions to bindings everywhere, then the code maintenance burden would be too great to implement it regardless of common practice. I don't think this is likely to be the case though, since Banshee appears to implement space as play/pause in the manner you prescribe. Maybe I'll take a look at their code and see what they had to do to make it work right.