SFML 2.0 RC

[Marukyu]

Building without Arial.hpp makes libsfml-graphics.so 269 KB on my system, so the inclusion of a default font file does add quite some size bloat, looking at it in relative numbers (>100% of the original size). While in absolute numbers, ~300 KB may indeed not be that much, I imagine only a small number of people actually use it, as most of them actually want to switch to their preferred font or write a customized bitmap text renderer.
It looks more like a debug feature to me that is primarily used by people who want a quick prototype program without any other resources, but it is not really something anyone would use in a large-scale project. I actually was not even aware of its presence and always assumed SFML would fail to display text if you didn't load a ttf file, until I checked out the source code.

[Laurent]

Although I agree with you, do you think it's worth making the API more complicated for this argument?

[Pakatius]

Hello,

While comparing Network/Http.hpp and Network/Http.h it seems some values are missing for sfHttpStatus enum:

diff -Naur LaurentGomila-CSFML-8e856b0.orig/include/SFML/Network/Http.h LaurentGomila-CSFML-8e856b0/include/SFML/Network/Http.h
--- LaurentGomila-CSFML-8e856b0.orig/include/SFML/Network/Http.h        2012-07-08 01:45:50.000000000 +0200
+++ LaurentGomila-CSFML-8e856b0/include/SFML/Network/Http.h     2012-07-08 01:48:19.000000000 +0200
@@ -56,6 +56,8 @@
     sfHttpCreated   = 201, ///< The resource has successfully been created
     sfHttpAccepted  = 202, ///< The request has been accepted, but will be processed later by the server
     sfHttpNoContent = 204, ///< Sent when the server didn't send any data in return
+    sfHttpResetContent   = 205, ///< The server informs the client that it should clear the view (form) that caused the request to be sent
+    sfHttpPartialContent = 206, ///< The server has sent a part of the resource, as a response to a partial GET request
 
     // 3xx: redirection
     sfHttpMultipleChoices  = 300, ///< The requested page can be accessed from several locations
@@ -68,12 +70,15 @@
     sfHttpUnauthorized = 401, ///< The requested page needs an authentification to be accessed
     sfHttpForbidden    = 403, ///< The requested page cannot be accessed at all, even with authentification
     sfHttpNotFound     = 404, ///< The requested page doesn't exist
+    sfHttpRangeNotSatisfiable = 407, ///< The server can't satisfy the partial GET request (with a "Range" header field)
 
     // 5xx: server error
     sfHttpInternalServerError = 500, ///< The server encountered an unexpected error
     sfHttpNotImplemented      = 501, ///< The server doesn't implement a requested feature
     sfHttpBadGateway          = 502, ///< The gateway server has received an error from the source server
     sfHttpServiceNotAvailable = 503, ///< The server is temporarily unavailable (overloaded, in maintenance, ...)
+    sfHttpGatewayTimeout      = 504, ///< The gateway server couldn't receive a response from the source server
+    sfHttpVersionNotSupported = 505, ///< The server doesn't support the requested HTTP version
 
     // 10xx: SFML custom codes
     sfHttpInvalidResponse  = 1000, ///< Response is not a valid HTTP one

[BMB]

Building without Arial.hpp makes libsfml-graphics.so 269 KB on my system, so the inclusion of a default font file does add quite some size bloat, looking at it in relative numbers (>100% of the original size). While in absolute numbers, ~300 KB may indeed not be that much, I imagine only a small number of people actually use it, as most of them actually want to switch to their preferred font or write a customized bitmap text renderer.
It looks more like a debug feature to me that is primarily used by people who want a quick prototype program without any other resources, but it is not really something anyone would use in a large-scale project. I actually was not even aware of its presence and always assumed SFML would fail to display text if you didn't load a ttf file, until I checked out the source code.

I second this. Though 300k may not be a lot, I just have this pet peeve on including anything I don't need. Just sort of an unexplained disgust.

[Laurent]

While comparing Network/Http.hpp and Network/Http.h it seems some values are missing for sfHttpStatus enum:

Since it can be added later without breaking the API, let's not discuss it in this thread

I second this. Though 300k may not be a lot, I just have this pet peeve on including anything I don't need. Just sort of an unexplained disgust.

Feel free to suggest a solution to solve this "problem"

[Ceylo]

I second this. Though 300k may not be a lot, I just have this pet peeve on including anything I don't need. Just sort of an unexplained disgust.

Personally I really don't care about 300 KB and I find it very convenient to be able to display text without caring about loading a font, although I agree that in large projects I would probably use a custom font, but SFML isn't for large projects only.

If the proposed solution does not involve more complexity I've nothing against it.

[Marukyu]

I have no experience with automatic building tools and how to supply them with parameters. What would adding something like a checkbox to cmake to toggle a certain compiler flag that switches inclusion of Arial.hpp for a project involve? How would it complexify the API? If it's too complicated, then it's probably not worth the effort for the potentially saved memory, but I will still keep manually commenting it out everytime I update SFML (which I do quite frequently throughout development). Even a compilation flag/macro (#define SFML_NO_BUILTIN_FONT?) without any cmake-visible option would help speed up that process.

[eXpl0it3r]

I have no experience with automatic building tools and how to supply them with parameters. What would adding something like a checkbox to cmake to toggle a certain compiler flag that switches inclusion of Arial.hpp for a project involve?

As I've stated before it's easy to exclude one file, but it's another thong to guarantee no crashes. Because you can't just remove it let all applications crash ugly if they try to use the default font and then blame the developer. One would implement a switch that changes more than just the exclusion.

[Laurent]

Disabling it at compile time is not a good option. Because I would then have to disable Font::getDefaultFont as well, and that would end up in two different (and incompatible) SFML APIs depending on how one compiled it. And the default version would still have it enabled anyway.

[Marukyu]

Ah well, it's probably not worth trying to find a clean solution to this then. I'll just keep manually removing it myself then, it's not a big deal.

[bastien]

I really like the Libertine fonts and they're free/libre/open source too.

Another license problem is that, as far as I can tell, you don't distribute the license with the binary dependencies. This is needed for the BSD license, for example.

[Laurent]

There's an issue on the tracker if you want to discuss free fonts further.

Another license problem is that, as far as I can tell, you don't distribute the license with the binary dependencies

I distribute a license.txt file, which contains a mention of every dependency and its license. But I think that I should put a direct link to the license text too.

[Pakatius]

While comparing Network/Http.hpp and Network/Http.h it seems some values are missing for sfHttpStatus enum:

Since it can be added later without breaking the API, let's not discuss it in this thread

Why you just don't apply the patch now?

If you apply it later, I'll have to update my code later...

[Laurent]

Oh wait, I just understood that these values are in the C++ version but not in the C one.

I thought you wanted to add new codes, sorry.

I'll do it as soon as I can.

[Marukyu]

I stumbled upon a problem while implementing an event-based remappable input system: SFML makes no distinction between unknown keypresses and "A" keypresses. While this might not be a big issue for QWERTY users, other keyboard layouts, particularly QWERTZ (which is what I am using) have lots of keys that are not correctly picked up by the sf::Window implementation and end up being incorrectly fired as "A" keypresses (specifically, the ÄÖÜß^<# keys on QWERTZ keyboards). I described the issue and a possible, hopefully non-API-breaking fix here. It basically involves adding an extra key (sf::Keyboard::Unknown or something like that) to the sf::Keyboard::Key enum and replacing instances of the bottom-catcher "return Keyboard::Key(0);" (which happens to be "A") in the sf::Window implementations with "return Keyboard::Unknown;".

This is quite a big issue in my opinion, and any kind of temporary "quick fix" would be better than having no way to eliminate incorrectly fired "A"-key events.