Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: New RichText class  (Read 16870 times)

0 Members and 1 Guest are viewing this topic.

Xorlium

  • Jr. Member
  • **
  • Posts: 84
    • View Profile
Re: New RichText class
« Reply #30 on: March 11, 2013, 09:07:38 pm »
Hi,

Nice class. Unicode doesn't work for me (using linux) and I only see squares instead of the normal stuff. I also had to change the end of lines from windows to unix in the source.txt.

Not sure how to deal with that though...

Thanks.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6254
  • Thor Developer
    • View Profile
    • Bromeon
Re: New RichText class
« Reply #31 on: March 11, 2013, 09:41:35 pm »
I  have taken a look at your code, here are some tips, roughly sorted by importance:
  • Don't use the namespace sf for SFML extensions -- it might confuse people.
  • Consider the rule of three (might be the reason for the mistake mentioned by Raycast). In particular, is there a reason why define the copy constructor? For the destructor, there seems to be none. Always let the compiler generate these member functions for you if possible.
  • If you define the copy constructor, don't forget to copy the base classes.
  • #ifndef nullptr will not work, since nullptr is no macro. And you are not allowed to define macros with the name of C++ keywords.
  • Use the constructor initializer list instead of assignments.
  • To avoid the code duplication in the case statements of RichText::setString(), you could use a function.
  • With the right literal, you needn't specify the template argument at std::max<unsigned int>(size, 1) -- take std::max(size, 1u) instead.
  • If you need string streams to either read or write, take std::ostringstream or std::istringstream.
  • Constructors only need to be explicit if they can be called with one argument (but there may be code styles who always write explicit, but then it should also be there for the default constructor).
  • Don't mix unsigned int and unsigned.
  • Sometimes the return type is on a separate line, sometimes not.

I like the fact that you never use manual memory management and work with STL containers! :)
« Last Edit: March 11, 2013, 09:45:36 pm by Nexus »
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: first SFML book

TechRogue

  • Jr. Member
  • **
  • Posts: 63
    • View Profile
Re: New RichText class
« Reply #32 on: March 12, 2013, 06:41:24 pm »
In order:

  • Would namespace sfe be more appropriate? That's what the original class used; I wasn't sure if it was the standard for this type of thing
  • I don't think there is a reason I defined the copy constructor, actually. I defined the destructor because I thought it would default to private otherwise...is that not the case?
  • Good call. I'm going to look into removing the copy constructor I defined anyway.
  • Laurent already mentioned the #define nullptr issue. I'll go through and replace them with NULL.
  • What is the reason behind preferring the initialization list? I didn't know there was a difference, except when assigning const and reference members.
  • Okay. :)
  • I didn't know about the u suffix. That's very handy.
  • I take it i/ostringstreams are more lightweight than normal stringstreams?
  • Good to know. To be honest I'm only using explicit constructors because sf::Text does.  ;)
  • I thought unsigned int and unsigned were the same.  :-\
  • Having return types on a separate line is a coding standard of mine in my personal projects. I must have missed a few when I was cleaning up the code.

Thanks for all the feedback! :D

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6254
  • Thor Developer
    • View Profile
    • Bromeon
Re: New RichText class
« Reply #33 on: March 13, 2013, 12:48:48 pm »
Quote from: TechRogue
Would namespace sfe be more appropriate?
Yes :)

Quote from: TechRogue
I defined the destructor because I thought it would default to private otherwise...is that not the case?
No, it is public by default.

Quote from: TechRogue
What is the reason behind preferring the initialization list? I didn't know there was a difference, except when assigning const and reference members.
You express the intent more clearly: Direct variable initialization. When using assignments, you default-construct them (for class types) and overwrite them later. There are many cases where you can't use assignments (no default constructor, base classes, constants, references, non-copyable and non-movable types), so I recommend to be consistent. Especially since assignments don't bring an advantage, unless you actually need delayed initialization.

Quote from: TechRogue
I take it i/ostringstreams are more lightweight than normal stringstreams?
Slightly, and again you express more clearly that only either input or output is required. If you accidentally call an operation of the other kind, the compiler yields an error. Of course, it's not a big issue, but it doesn't cost anything (except thinking 5s about what is needed) ;)

Quote from: TechRogue
I thought unsigned int and unsigned were the same.  :-\
They are, but you should use one of them consistently in your code. Just a matter of code style, again no big issue.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: first SFML book

Foaly

  • Sr. Member
  • ****
  • Posts: 453
    • View Profile
Re: New RichText class
« Reply #34 on: March 13, 2013, 08:37:42 pm »
Somebody (I don't remember who...) one the wiki once used the namespace sftools:: for classes like this. I don't want to start a discussion on what's more suitable. I just found that it clearly states, that it's not part of SFML. So I thought I throw it in there if you still look for one.

namespace Jav {}

  • Newbie
  • *
  • Posts: 1
    • View Profile
    • Email
Re: New RichText class
« Reply #35 on: April 18, 2020, 09:38:29 pm »
Great class Mr. Roque. Its amazing what you have done. Only problem is text wrapping.

I am actually observing your code, editing the style, using newer cpp constructs like for each loop and such. Removing unneeded if statements, compacting the code, and compiling along the way to ensure it is the same results. All with the aim to add text wrapping.

Note that SFML should do better. It is nearly version 3 and they still havent added text wrapping and rich text directly in the library. They should look at the android graphics api, TextView, ListView, and such. These are regularly used ui constructs!

I am here on my Windows XP, no graphics acceleration, and finding it hard to write a simple ui. I am working like 4, 5 days and cant pass the ui stage. A ChessBoard, with pieces, movable, with 2 Text Box Fields.

Started using GDI, studied it in one day, then another day to devise a design structure for it. Then came to a dead end, when I ready to add the pieces, which NEED transparency.

 So I began studying OpenGL. OpenGL and DirectX I studied in the past but failed to create any app with them. Now studying it again I was once again overwhelmed! Managed to set up the Context. Studying GDI elevater my understanding. But all I did was draw a rectangle and make it spin. I realized immediately I would have problems loading textures{chessboard, chesspieces}, and Object orient them like what I did with GDI; by giving each object a mem_ctx; Worse of all, OpenGl and GDI werent compatible, unless I want SlowGL. And how to render text with OpenGL????? 1.1 ????

I had to say later to OpenGL and reconsider GDI+  which I read was slow. After all DirectWrite and stuff is vista and up. I was staying away from SFML because I mastered it already. I created a draugh game and Chess game with it already. I wanted to grow my knowledge to the lowerlevels of graphics. I tried GDI+. Surprisely I never used it before in the past. I was gravitated by the advertisement of it on MSDN. Even though the documentation of it is well less than GDI, it was breath taking. They told you how much it has improved and improved and improved over GDI. When I checked it out, my heart sank. It literally tooks SECONDS for GDI+ to draw 8 Chess pieces. It really should be called GDI-; Why it has to be software implemented I dont know! But it is TOTALLY UNUSABLE on my machine.

So, out of desperation, I had to use SFML; my old friend. The one that taught me graphics programming. SFML 2.5.1.

It took me some time to install it. Only sfml as a library, tells you to give the linker symbolic names. sfml-graphics. There is no lib file called that. But now I know I can bypass setting lib directory, and simply selected the real lib file! Or I can do it how SFML says. either way.

But my real problem with SFML is the dll. What is the purposed of shared libraries if you cant share them! Why must I recopy those file into every app directory? They should be located from a centralized path, that one file can be shared. And finding and copying the files is simply troublesome. Especially when Sfml asks for dll not created by sfml. such as libgcc.

Anyhow, I finally got sfml working. Begin creating my drawables. Then another dead end. SFML does not do textwrapping. This is stupid! Performance wise, it best sfml does the drawing and wraps text in the iterations. Rather than have us use calculateCharacterPos which I am sure does an iteration on every call. Also sfml doesnt support editable text. Again take a page from Android! Lucking they provide a const sf::String& which is safely casted to non const.

Great. I can wrap text now. Then when I look at my use and the text looks bland. If only I could draw red text and then white text. Then it came to my realization that this wasnt going to be my easy moment. I thought about it and found nothing good.

So I tried back GDI as it is compatible with SFML. DrawText does textwrapping, but no rich text. GetTextExtentExPoint32 promised to give me measurements but was very cumbersome! TextOut can do rich yext but no text wrapping. And I could maths out how to do my everythinh any of these graphics engines.

To do rich text in a console app is very easier. For example, syntax highlighting. Why is the real graphics engines not allowing me this ease. And again, I am no where near learning to draw text with OpenGL.

Luckily I found a library on the internet that Roque metioned. Unfortunately I never got it to work. And it is not very very rich rich text. for example, he was exploding texts into Lines. So a line can only be in one color. Not enough for syntax highlighting or my needs. But I loved how he used the stream operator to stream in the state of the text and stuff.

Needless to say, I couldnt implement his idea. So I searched again and saw Roque's library. and got it working. And it was more beautiful than the illustration on the Net.

Thank you Roque. But SFML needs to do better! They should implement a TextBox, with text wrapping and rich text abilities. It makes no sense I am creating 50 sf::Text to display one string.