SFML 2.0 RC

[minirop]

the « problem » is that :

    enum Key
    {
        A,            ///< The A key

nothing before so A == 0.
So something like :

    enum Key
    {
        Unknown,
        A,            ///< The A key

should be enough (?)

[Marukyu]

Ah, good point. I guess it would still be a bit cleaner to replace Keyboard::Key(0) with Keyboard::Unknown though. I wouldn't only call it a "« problem »" though. :p
It is an issue that can limit the usefulness of KeyEvents quite a bit.

[Laurent]

It is indeed a major problem. I added sf::Keyboard::Unknown as suggested to solve it.

Thank you very much for your feedback

[Marukyu]

Thank you very much for the fix! Glad I could help. :3

[Tank]

Can you tell us why these 300 KB are so important?

300 KB are not really important, but we can kill two birds with one stone here probably:

1) Get rid of 300 KB.
2) Get rid of default font crash bug.

Maybe you still remember my proposal from the past when I suggested to force the user to load a font. I really don't think that it would be complicated or annoying, it's as simple as:

sf::Font font;
font.loadFromFile( "foobar.ttf" );
sf::Text text( L"Hello", 12, font );

It's not the same, but you do it with images and sounds too, which is very reasonable. I still find it problematic that the library provides unmanaged resources.

[Laurent]

Yes, I remember this solution everytime there's an issue with the default font. And I admit that it seems to be the best one so far.

However if I change anything in the public API, it must be done before SFML 2.0 is released... so I must take a decision quickly

[Tank]

Indeed. The only thing which is a little bit more annoying is providing a standard font. I see 2 options here:

1) sf::Font::makeStandardFont: Returns a new sf::Font, font data is included in sources. Pro: Easy. Con: 300 KB extra, always.
2) sf::makeDejaVuFont: Returns a new sf::Font, font data is included in separate(!) header only. Pro: 300 KB extra only if being included, which is intended if someone does it (not included by SFML itself). Con: Annoying to use in-place, see below.

Option 2 would be for sure a compromise and still easy enough, I think. Ex:

#include <SFML/Graphics/DejaVuFont.hpp>
sf::Font font = sf::makeDejaVuFont();

A big drawback is the following, which is invalid:

sf::Text text( L"I will crash :-(", 12, sf::makeDejaVuFont() );

I can't think of a real solution to satisfy everybody, except shared resource management through smart pointers, but I'm sure you're already screaming right now.

[binary1248]

I could live without a default built-in font. And since I'm too lazy to implement my own OS #ifdefs maybe there could be a sf::Font::loadSystemFont(sf::String) that looks for that font face in the system font directory? With clever use of environment variables it shouldn't be too hard

[Laurent]

1) sf::Font::makeStandardFont: Returns a new sf::Font, font data is included in sources. Pro: Easy. Con: 300 KB extra, always.
2) sf::makeDejaVuFont: Returns a new sf::Font, font data is included in separate(!) header only. Pro: 300 KB extra only if being included, which is intended if someone does it (not included by SFML itself). Con: Annoying to use in-place, see below.

I like option 2. But then it becomes similar to providing the font file directly, the only difference is that with a header it is compiled directly into the final application. But then why not go further, and provide a generic system to embed any data into the application?

I can't think of a real solution to satisfy everybody, except shared resource management through smart pointers, but I'm sure you're already screaming right now.

Indeed
Smart pointers are not a big deal, but what's annoying is that they exist in C++11/TR1/boost, but as SFML has to remain compatible with pure C++03, I would have to rewrite it myself. But the name and API of the shared_ptr class would then be different. It's definitely too messy.

I could live without a default built-in font. And since I'm too lazy to implement my own OS #ifdefs maybe there could be a sf::Font::loadSystemFont(sf::String) that looks for that font face in the system font directory? With clever use of environment variables it shouldn't be too hard

That's a very interesting feature, and to be honest until now I avoided it only because there was a default font. But now, with the mentionned issues, I guess it would be a good moment for investigating that.

I'll take a look at Qt's source code, and see if the related code is not too complicated.

[Laurent]

A drawback of the loadSystemFont solution is that it is impossible to guarantee that a given font will be available. Which leads to the "font family" system, ie. you give a more or less precise definition of the font that you want, with optional fallbacks, and the system finds the best match. It becomes already quite complicated.

[binary1248]

No no no... I didn't mean it to be that complicated. loadSystemFont should just be an extended version of loadFromFile that searches known paths automatically. Like loadFromFile it would return false if the font doesn't exist on the system. Passing an empty string (the default) to loadSystemFont would load the default font for the system, whatever you choose it to be.

This solution would work for 99.99% of the userbase of SFML.

Windows users are the easiest. All their fonts are in %WINDIR%/Fonts and they always have Arial installed if thats what you want as default.
Mac OS X users I presume have the same situation as Windows users.
Linux users, most of them use one of the popular distros, would also mostly have the same paths and font faces installed.

[Andrei15193]

the « problem » is that :

    enum Key
    {
        A,            ///< The A key

nothing before so A == 0.
So something like :

    enum Key
    {
        Unknown,
        A,            ///< The A key

should be enough (?)

A good option however it implies declaring another constant. Like you said:

#include <iostream>

enum TestEnum{a, b, c};

int main(){
    std::cout<<a<<" "<<b<<" "<<c<<std::endl;
    return 0;
}

Outputs: "0 1 2". However the following code fixes the issue for the enumeration start constant:

#include <iostream>

enum TestEnum{a = 1, b, c};

int main(){
    std::cout<<a<<" "<<b<<" "<<c<<std::endl;
    return 0;
}

Will output: "1 2 3". No extra constant required.

Docs: Other data types - C++.

[Laurent]

A good option however it implies declaring another constant.

We want a new constant. sf::Keyboard::Unknown is much better than sf::Keyboard::Key(0), isn't it?

No no no... I didn't mean it to be that complicated. loadSystemFont should just be an extended version of loadFromFile that searches known paths automatically. Like loadFromFile it would return false if the font doesn't exist on the system. Passing an empty string (the default) to loadSystemFont would load the default font for the system, whatever you choose it to be.

I'm wondering is this is relevant. I mean, if I write an application and plan to distribute it, I won't rely on a specific font being present on the user's system. Instead I'll provide the font with my application for 100% safety.
So who would use this feature?

[Andrei15193]

A good option however it implies declaring another constant.

We want a new constant. sf::Keyboard::Unknown is much better than sf::Keyboard::Key(0), isn't it?

I thought you wanted the enum to start from 1 and not from 0.

[Laurent]

I thought you wanted the enum to start from 1 and not from 0.

No we don't care. The problem to solve was that 'A' and unhandled keys had the same code.