New class for SFML2: TextArea.

[Cierpliwy]

TextArea class:

One thing which is missing in SFML for me is more advanced text renderer which will be used for large, formatted and styled strings. They will use for example HTML-like style formatting because it's quite common and simple.

I've written small sample today which render justified text in selected area. I know it should inherit sf::Drawable, render to texture for better performance, support more functions etc. but I can do it later.

My implementation:
main.cpp (for test) - http://paste-it.net/public/v157f0e/
TextArea.h - http://paste-it.net/public/g53e138/
TextArea.cpp - http://paste-it.net/public/td62458/

How it looks like:


What do you think about that idea?

Edit: Now I see this topic should be in Feature Request.

[Laurent]

This kind of class still looks a little bit too high-level to me.

[Cierpliwy]

But what about people who won't write something like this by themselves because it will be to hard to do it. I know it's high level, it's hard to maintain but... it's really important. In every basic game there is a need to draw huge parts of formatted texts: letters, quests, briefings...

But, let's hear about others opinions as well.

[Thiziri]

I think they will find this feature in the wiki (if you put it inside) !  

[Cierpliwy]

My bad that i've never visited SFML Wiki Now I understand why Laurent doesn't accept my idea.

thiziri: I'll try to write such an extension

[Nexus]

But what about people who won't write something like this by themselves because it will be to hard to do it. I know it's high level, it's hard to maintain but... it's really important.

Yes, but it's not in scope of SFML. The library provides basic multimedia functionality, so that we don't have to use several low-level libraries and rewrite everything again and again. Your class, however, is in my opinion beyond SFML's application area.

Why only adding a TextArea and not other GUI components as well? A button is used very often, too, for instance. But a complete GUI framework is definitively complex, and Laurent has enough other things to do.

Anyway, the TextArea looks quite good. I think, the SFML wiki isn't a bad idea, there are already similar projects. I'm sure SFML users can benefit from it!

[Cierpliwy]

Why only adding a TextArea and not other GUI components as well?

I'm creating TextArea to use it everywhere when it is possible, also in controls, widgets and windows. It won't depend on anything and be as simple as possible.

[Cierpliwy]

Ok.. I programmed a bit. It was about ~500 lines of code to implement basic TextArea class.

What i have done:

Added tags:
<b></b>
<u></u>
<i></i>
<size=xx></size>, where xx is number: 09, 12, 89
<color=xxx.xxx.xxx></color>, where xxx is number: 001, 034, 234
<align=x></align>, where x is: c-center, l-left, r-right, j-justify

Problems:
- if tags are inside word, word can split up.
- if word width is higher then rectangle width there is undefined behavior.
- space between lines.
- you need add enter before </align> tab otherwise last line will be aligned improperly.

To Laurent:
- What about a sf::Text feature which will easily give you metrics for special characters like: space, tab, new line.
- I miss std::string functions in sf::String, such as substr().
- Do you control bold effect in fonts? As you can see in the picture, small font with bold style are too fat.

What I want to do:
- Add link tag <l> which will will don't split up two linked words
- Rewrite some parts of code to be more clearly and have better performance.
- Render to texture.
- If implementation will be stable I'll rewrite comments in source code (now they are unfortunately in polish).
- Fixed tab size?

Demo render:


Parse time: ~0.15 s.
Render time: ~0.02 s.

How to use:

Create object TextArea and set string, rect and font. After that, before rendering parse the text. In main application loop render it.

Code: [Select]


//This code before rendering:
TextArea ta;
TextArea ta;
ta.SetRectArea( sf::FloatRect(20,20,780,580) );
ta.SetFont( font );
ta.SetString( myString );
ta.Parse();

//This code between app.Clear() and app.Display():
ta.Render(app);


Put this files in your project:
- http://paste-it.net/public/q98ffc4/
- http://paste-it.net/public/jc6dcfd/

I'm waiting for your opinions and propositions.

[Thiziri]

OMGad, that's impressive ! :shock:
Congratulations !  

PS: My text formating fonction looks like tiny compared to your class... :oops:

[Laurent]

That's awesome, I think you will make many users happy

- What about a sf::Text feature which will easily give you metrics for special characters like: space, tab, new line.

Tabulation is currently 4 spaces. As discussed in another topic, it may be handled differently in the future.
Space metrics can be retrieved with Font::GetGlyph, like any other character.
Line spacing can be retrieved with Font::GetLineSpacing.

- I miss std::string functions in sf::String, such as substr().

I know. I'm not 100% satisfied with the sf::String API, I'm hoping to find a better solution one day.

- Do you control bold effect in fonts? As you can see in the picture, small font with bold style are too fat.

Yes I can control the weight of the bold style. I'll do some tests to find the best value.

[Cierpliwy]

I know. I'm not 100% satisfied with the sf::String API, I'm hoping to find a better solution one day.

It would be really cool to operate on string by using only sf::Strings functions. Now I have to convert sf::String to std::wstring which takes time.

Please tell me what features should I add to TextArea class!

[Nexus]

Great work! I especially like the ability to colorize text parts!
You really have got a lot of possibilities with your class.

Nevertheless, I have to comment some important things:

Take care of const-correctness.
The following methods do not change their argument, so pass them as const-references.

Code: [Select]

void SetFont( sf::Font &font );
void SetString( sf::String &string);
In the same way, the getters should return references to const plus be const-qualified, since they don't modify the instance.

Code: [Select]

sf::Font& GetFont();
sf::String& GetString();
Provide constructors.
It would be nice to initialize the TextArea in the way it will be used, for example with the string, the rect area and the font as arguments. I suggest that the font is defaulted to sf::Font::GetDefaultFont() in case no explicit font is specified. So, one doesn't have to call SetFont() when using SFML's Arial.

Ensure object validity and consistent state.
The current default constructor creates an invalid instance. That means that using the public interface (methods GetString() and GetFont()) leads to undefined behaviour because you dereference null pointers. Either you make sure there is always an object with a valid string and font (by not providing a default constructor or setting those attributes to default values). The alternative is to return pointers or throw assertions at failure.

Besides, of the member function SetString() I expect that it adapts the internal text. But this isn't the case. In my opinion, Parse() should be private, as it is an implementation detail. The public interface should be responsible that a new string is automatically parsed and decomposed into the sf::Text chunks. Hereby, the next call to Render() already draws the new text.

By the way, what is the method BlockDebug() for?

[Cierpliwy]

Yep, I coded version 0.1 in hurry so quality of code is much lower then it should be.

BlockDebug() is simple function for my debug purposes Call it after Parse() method and you'll see what it does.

[Laurent]

I fixed the bold weight.

[xarxer]

Don't know if it's already been done but this should definately be mentioned in some tutorial or wiki!  
Truely great work