Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"visible_characters" property of Label and RichTextLabel behave differently; discrepancy between whether they acknowledge spaces or not. #34775

Open
Tracked by #39144
decaf-doctor opened this issue Jan 3, 2020 · 4 comments · Fixed by #34874

Comments

@decaf-doctor
Copy link

Godot version:
3.1.1
OS/device including version:
Ubuntu 16.04 LTS ...I've been too lazy to upgrade 😳
Issue description:
The visible_characters property in the node type Label ignores spaces, though the same property on the node type RichTextLabel acknowledges spaces as characters. This is a discrepancy in behavior that can be frustrating.
Steps to reproduce:
Just play with the aforementioned properties. See attached example project.

Minimal reproduction project:
visible-characters-bug.zip

@thebluefish
Copy link

thebluefish commented Jan 3, 2020

I suspect the issue is with how it's splitting words. Each word actually counts spaces separately, yet they're not considered for chars_total.

I tried a small fix which seemed to work. https://github.com/godotengine/godot/blob/master/scene/gui/label.cpp#L227

Adding the following line here:

chars_total += from->space_count;

My machine's git is currently broken and I'm not going to try editing this for PR-worthiness using the web editor. I also haven't tested for other whitespace characters (or know if this even matters). Hope it helps none-the-less.

@akien-mga
Copy link
Member

Reopening as #34874 was reverted due to a regression (#35668).

@akien-mga akien-mga reopened this Jan 28, 2020
@akien-mga akien-mga removed this from the 3.2 milestone Jan 28, 2020
@akien-mga akien-mga added enhancement and removed bug labels Jan 28, 2020
@Calinou
Copy link
Member

Calinou commented May 19, 2020

Related to #27896.

@belzecue
Copy link

belzecue commented Dec 18, 2021

Discovered this in 3.4.1.

I see this is getting fixed one way or another, to bring the two into alignment, but here's my user story anyway:

Had a Label that I was subtracting whitespace from:

var sentence: String = "\n\n" + iDic.text_stream if (iDic.newline and bool(counter)) else iDic.text_stream

var space_chars: int = sentence.count(" ") + sentence.count("\n") # 'visible_characters' property count excludes spaces
var visible_chars: int = visible_characters
# Add new text to parent
text += sentence

# Do lead in
self.state = states.LEAD_IN
yield(tree.create_timer(lead_in), "timeout")
# tween/type
tween.interpolate_property(
	self,
	"visible_characters",
	visible_chars,
	visible_chars + sentence.length() - space_chars,
	duration,
	Tween.TRANS_LINEAR,
	Tween.EASE_IN_OUT,
	0
)
tween.start()

This tweened the new text perfectly.

Decided to upgrade from Label to RichTextLabel, and found that it was stopping prematurely before the end of the new text. Wondered if RichTextLabel was handling "visible characters" differently to Label and confirmed it by not removing space chars from my calculation...

visible_chars + sentence.length(), #- space_chars,

And now it prints the full new text.

The doco says the "visible_characters" property should behave the same way for both:

LABEL: "Restricts the number of characters to display. Set to -1 to disable."
RICHTEXTLABEL: "The restricted number of characters to display in the label. If -1, all characters will be displayed."

So this is very confusing for those who don't know to search issues on Godot's Github.

Going forward, I agree that spaces SHOULD be counted as "visible". Under the hood, there might be valid reasons not to, but I was very surprised to see this design decision when learning how to use Labels, me coming from a long programming background.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants