A couple suggestions

[GraphicsWhale]

snapping things to one side of the window

It makes sense for the graphics to access the framebuffer size, so this is a non-issue.

where if you only have access to an sf::Graphics, and the Window has been resized, would sf::Graphics know that the Window had been resized

You can't even do that with a RenderTarget. Actually, you can't even do that with the window! Resizing generates an event (ok, technically events go through the window, but there's no function to call). If your program has a proper structure, your rendering code will be notified about the resize.

What about if the window loses focus and you want to draw to it when this happens, if something either only has access to the Window, or only has access to the Graphics, you can't do this.

If your rendering code looks something like this:

void render(sf::RenderWindow& window)
{
    if (window.hasFocus())
    {
         [i]...[/i]
    }
}
 

Then you're probably doing something wrong.

I guess I'm just resistant to change unless I'm absolutely sure there won't be any negative effects, but unless I come up with a concrete thing that definitely will causes a problem, I'll leave it.

You shouldn't need a "concrete thing that definitely will causes a problem" to deal with a change for the better.

I mean, there's nothing inherently wrong with using the native API with OpenGL directly, but that doesn't mean that it isn't better to use a wrapper like SFML. Same thing with program structure (in this case, the problem isn't as severe, but it's pretty bad IMO), it might work for you right now, but it's still should be changed.

[GraphicsWhale]

It can be quite ugly when you need to use a Sound for something that's not a sound effect

A short tune that is constantly re-used benefits from being an Sound, but it's not a sound-effect.

But it's still sound, right?

The problem is entirely just the semantics. Just because there isn't an inherit issue with playback (but there can be, if you're misled to use the wrong class..), does not mean that the names shouldn't be changed. After all, your entire counter-argument was precisely about semantics as well. 

[Hapax]

The issue you have, then, is only with sf::Music.

An sf::Sound represents a sound in memory, as an sf::Image represents an image in memory, and an sf::Font represent a font in memory etc..

Whether this sound is and effect or music doesn't matter since they're all sound and this naming is precisely what it is.

sf::Music, however, is named after the more commonly used reason to used streamed audio, especially in games. It could be named sf::ExternalSound, which would still be semantically correct (and I wouldn't dislike that as much as sf::UnbufferedAudio), but it's uncommon to use it for anything other than music and it's easy to understand that sf::Music streams audio from somewhere, if you need to use it.
You mostly only really see the type at declarations anyway so as long as your variable name is descriptive, its type shouldn't matter that much.

[GraphicsWhale]

The issue you have, then, is only with sf::Music.

While sf::Music is the primary offender, sf::Sound still feels like it conveys a small amount of "this is for sound effects only" in it's name. That's why I'd prefer Audio in oppose to Sound, if the naming were to be changed (same amount of letters anyways). But as I said, it is mostly sf::Music.

Whether this sound is and effect or music doesn't matter since they're all sound and this naming is precisely what it is.

If the naming didn't matter, I would've suggested it, you would've said that you have no strong feelings one way or the other and that it's not worth anyone's time and we should all just move on from it. Clearly there are opinions about which names are superior.

sf::Music, however, is named after the more commonly used reason to used streamed audio, especially in games.

Exactly why I contest it's name. I'd much prefer it being named based off of what it does, and why it's different from it's alternatives, not it's most common usage.

It could be named sf::ExternalSound, which would still be semantically correct (and I wouldn't dislike that as much as sf::UnbufferedAudio)

Better, but the word "External" instead of "Streamed" or "Unbuffered" kinda negates any benefits. I suppose it might make the programmer have a moment of confusion wondering what an "external sound" is, look at the documentation, and finally figure it all out, but that's counter-intuitive. Plus.. it's.. kinda ugly.

it's easy to understand that sf::Music streams audio from somewhere, if you need to use it.

I wouldn't consider it easy if you have to look at the documentation.

You mostly only really see the type at declarations anyway so as long as your variable name is descriptive, its type shouldn't matter that much.

So we can go ahead and change the name of every class in SFML to be named after a fruit and it wont matter? Got it.

[Nexus]

GraphicsWhale: I understand your arguments, but I'm not sure you understand the scope of mine. For example, you have entirely ignored the Android API example and how choosing simple terms affects usage massively.

Just imagine we'd rename "Sound" to "BufferedAudio" and "Music" to "StreamedAudio" (as well as remaining "Sound" occurrences to "Audio" for consistency). The resulting class names in the Audio module will be a confusing mess:

BufferedAudio
StreamedAudio
AudioBuffer
AudioStream
AudioSource
AudioRecorder
AudioBufferRecorder

...and these are just class names. Any methods that exist now or in the future and that refer to classes will become more confusing, too.

The fact that "Music" may not be 100% precise is something you notice once, but from then on you know it. Complicating identifiers on the other hand is something that makes every developer's life more difficult. I'm having a rather pragmatic view here.

I'd really recommend you have a deeper look at the Android API (the link in my previous post) and imagine how things would look if a self-descriptive name instead of "Intent" was chosen. It will help you understand precisely what I mean

[GraphicsWhale]

Why not:

1. Use Sound instead of Audio.
2. Conversely to #1, change everything else from Audio to Sound.
3. Instead of BufferedAudio|StreamedAudio use something like Audio|StreamedAudio (might not be that effective, but worth mentioning).

If anything, simply changing sf::Music to sf::StreamedSound would make it a lot better than the naming scheme currently is.

[Hapax]

So we can go ahead and change the name of every class in SFML to be named after a fruit and it wont matter? Got it.

No. Not what I said at all. I even emphasized "that" to make my point more clear. It's easy to see "Music" as meaning a streamed sound. "Tomato" doesn't really give you any reasonable link to sound at all.

sf::Sound still feels like it conveys a small amount of "this is for sound effects only" in it's name.

I can't see how you came to this conclusion. It seems to be that whenever you hear "sound", you also hear the word "effect" and that doesn't make any sense.

If the naming didn't matter, I would've suggested it, you would've said that you have no strong feelings one way or the other and that it's not worth anyone's time and we should all just move on from it. Clearly there are opinions about which names are superior.

Would I? You seem to be misunderstanding what I'm writing. I have not stated whether I think Sound or Audio is better. I merely stated that its current name is accurate.

the word "External" instead of "Streamed" or "Unbuffered" kinda negates any benefits.

Which benefits? It shows that it has a different purpose to an "internal" sound and it's accurate. It's held outside of RAM.
Unbuffered, by the way, is technically inaccurate. Streamed sound is buffered.

I wouldn't consider it easy if you have to look at the documentation.

You shouldn't be using it if you haven't looked at the documentation.

[GraphicsWhale]

No. Not what I said at all. I even emphasized "that" to make my point more clear. It's easy to see "Music" as meaning a streamed sound. "Tomato" doesn't really give you any reasonable link to sound at all.

Are you saying your tomatoes don't sing to you..?

I can't see how you came to this conclusion. It seems to be that whenever you hear "sound", you also hear the word "effect" and that doesn't make any sense.

Most game libraries have "Sounds" much alike that in SFML. They are fairly heavy-weight, but are useful for small things, such as sound effects.

Things not used often or are too large to load are streamed. For example, in LOVE2D all music is streamed unless the parameter "static" is also passed.

Not completely related, but in Slick2D, Music has nothing to do with streaming, but instead the channel it's on (might be details I'm missing though, I haven't used this library in some time).

But generally, "sound"s are associated with RAM-cached audio sources. And such audio sources are used very often in games (most sounds you hear in games are considered sound effects anyways, not music).

Would I? You seem to be misunderstanding what I'm writing. I have not stated whether I think Sound or Audio is better. I merely stated that its current name is accurate.

1. Yes you would. In fact, you already have simply by contesting my opinion with your opinion.
2. You've stated your preference of the current system already.
3. The whole point of my argument, is that the name is not entirely accurate. So one of us is wrong. But don't automatically assume that it's me.

Which benefits? It shows that it has a different purpose to an "internal" sound and it's accurate. It's held outside of RAM.

Because it has no context to what it refers to by "external". External to what? The object? The class? The module? The library? The RAM? The computer? The earth? The solar system? The milky way?

Unbuffered, by the way, is technically inaccurate. Streamed sound is buffered.

And technically all of your objects are buffered with the cache. So I better go back and change BufferedAudio|UnbufferedAudio to BufferedBufferedAudio|BufferedUnbufferedAudio.

You shouldn't be using it if you haven't looked at the documentation.

Tell that to the people who don't read the documentation. I'm sure they'd be utmost excited to here about the existence of technical manuals that they intentionally chose not to read to begin with.

[GraphicsWhale]

I may have overstated my point in the past couple of posts.

I am not saying the API should be friendly to people who have no clue what they're doing. But such ambiguity between class names will likely cause people to not use the API correctly rather than bothering to look at the documentation (don't make yourself believe everyone actually looks in every little corner of the documents, all someone needs to see is "sf::Sound" or "sf::Music" written somewhere and they'll begin to learn only that class and ignore the other). At least they could stop and think "What's the difference between buffered and unbuffered sound/audio?" and possibly want to actually look at the documentation. 

[Hapax]

Most game libraries have "Sounds" much alike that in SFML. They are fairly heavy-weight, but are useful for small things, such as sound effects.
Things not used often or are too large to load are streamed. For example, in LOVE2D all music is streamed unless the parameter "static" is also passed.
Not completely related, but in Slick2D, Music has nothing to do with streaming, but instead the channel it's on (might be details I'm missing though, I haven't used this library in some time).
But generally, "sound"s are associated with RAM-cached audio sources. And such audio sources are used very often in games (most sounds you hear in games are considered sound effects anyways, not music).

Other libraries doing something doesn't mean that it's the right way to do something.
You did, here, seem to make a distinct between sounds being in RAM and music being the streamed audio. I think those distinction may be why those names were chosen for SFML.

It shows that it has a different purpose to an "internal" sound and it's accurate. It's held outside of RAM.

Because it has no context to what it refers to by "external". External to what? The object? The class? The module? The library? The RAM? The computer? The earth? The solar system? The milky way?

It doesn't have to necessarily specify exactly what it's doing. "BufferedAudio" doesn't say where it's being buffered. Your reply was odd 
My point was that it's accurate and differentiates from the 'other' type by describing why it's different.

Would I?

Yes you would.

You seem to be misunderstanding what I'm writing.

I better go back and change BufferedAudio|UnbufferedAudio to BufferedBufferedAudio|BufferedUnbufferedAudio.

No, because BufferedUnbufferedAudio isn't unbuffered.

You shouldn't be using it if you haven't looked at the documentation.

Tell that to the people who don't read the documentation. I'm sure they'd be utmost excited to here about the existence of technical manuals that they intentionally chose not to read to begin with.

I know. They'll come to the forum and ask why it isn't working and then they'll be (hopefully politely) directed to the documentation.

Are you saying your tomatoes don't sing to you..?

I'm not going to admit that in public!

[jamesL]

If your rendering code looks something like this:

void render(sf::RenderWindow& window)
{
    if (window.hasFocus())
    {
         [i]...[/i]
    }
}
 

Then you're probably doing something wrong.

ok, noob to SFML here (been doing sfml for about 4 weeks)

why is that code wrong  ?

according to this
http://www.sfml-dev.org/tutorials/2.3/window-inputs.php

sf::Keyboard::isKeyPressed(...)
"This function directly reads the keyboard state, ignoring the focus state of your window. This means that isKeyPressed may return true even if your window is inactive."

so from that documentation that's exactly what I've been doing in my code (checking if window has focus)

[GraphicsWhale]

why is that code wrong  ?

Because your game should be continuously updating regardless as long as it's running. Maybe pause it when minimize, but that's a change to your game's "state", not branch in the rendering code.

sf::Keyboard::isKeyPressed(...)
"This function directly reads the keyboard state, ignoring the focus state of your window. This means that isKeyPressed may return true even if your window is inactive."

so from that documentation that's exactly what I've been doing in my code (checking if window has focus)

I never said to ignore keyboard input, I just said that there doesn't need to be a branch in your rendering code, therefore only passing a graphics object instead of the whole window is a non-issue.

[Nexus]

jamesL: The code is not wrong from a functionality standpoint, but the design is questionable. The rendering code shouldn't care about windowing stuff. If there's a reason to not render, the application shouldn't call the render function in the first place.

As such, I agree that there isn't an inherent reason to mix graphics and windowing in the same class. Investigating the proposed approaches for SFML 3 can definitely be interesting.

[GraphicsWhale]

Other libraries doing something doesn't mean that it's the right way to do something.
You did, here, seem to make a distinct between sounds being in RAM and music being the streamed audio. I think those distinction may be why those names were chosen for SFML.

My point was the the notion of "Music" being something that streams it's audio is unique (AFAIK) to SFML. Maybe, just maybe, there's a reason why this naming scheme was not used in other libraries

It doesn't have to necessarily specify exactly what it's doing. "BufferedAudio" doesn't say where it's being buffered. Your reply was odd 
My point was that it's accurate and differentiates from the 'other' type by describing why it's different.

When you have a class that has a function to load a file, and a function to use it, the word "buffered" is pretty meaningful. Sure, it might not say to which point is it being buffered (the whole file, a small section, maybe even per-sample?), but most of the time it's referring to the whole file. "External" is not a good way to refer to something in the filesystem, so it's a lot less meaningful.

No, because BufferedUnbufferedAudio isn't unbuffered.

Does BufferedBufferedAudio|BufferedAudio tickle your fancy?

If the "permanent storage" (SSD or HDD) has cache, it would also be buffered there, too. Dang. Ok, what about BufferedBufferedBufferedAudio|BufferedBufferedAudio?

I know. They'll come to the forum and ask why it isn't working and then they'll be (hopefully politely) directed to the documentation.

Not sure why'd you want that.

[Hapax]

They'll come to the forum and ask why it isn't working and then they'll be (hopefully politely) directed to the documentation.

Not sure why'd you want that.

Want? No. The preference is that people read the documentation first. At minimum: try, google, read documentation, search forum, read documentation again, post on forum.

Does BufferedBufferedAudio|BufferedAudio tickle your fancy?

What? No. Why mention that they're buffered if they're both buffered? In this instance, they would both just be called Audio.

"External" is not a good way to refer to something in the filesystem

That's your opinion, of course, and I didn't say it was good. It just doesn't seem any worse than what you're suggesting. If this is your problem with "ExternalSound", I assume you liked the idea of "SoundOnFile"?

My point was the the notion of "Music" being something that streams it's audio is unique (AFAIK) to SFML. Maybe, just maybe, there's a reason why this naming scheme was not used in other libraries

I didn't say that music was only streamed. Music is sound so it can also be stored in memory without any inaccuracies. The idea of streamed sound being called Music is that the most common sound to stream is music. May I ask which sound you are streaming that isn't music that you find too confusing to label as music?

For example, in LOVE2D all music is streamed unless the parameter "static" is also passed.

This does seem to suggest that other libraries seem to default to music being a streamed sound.

My overall point then, really, is:
sf::Sound isn't incorrect in any way, although sf::Audio would work just as well. There is no reason to swap them though, since they amount to the same thing and would just break code for no reason.
sf::Music is a wrapper for a streamed sound and is named for its most common usage. It would be technically inaccurately named if you use it for anything other than what you define as music. I, personally, don't agree that it's the most apt name (this is my opinion; I don't know why you thought I thought otherwise) but is not difficult to 'overcome' and I am perfectly okay with it staying as "Music" but I might not vote for it if there's a better choice.