8000 Fixed accidental removal of tooltip when displaying text with message() by tomaszkax86 · Pull Request #1651 · colobot/colobot · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Fixed accidental removal of tooltip when displaying text with message() #1651

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

Merged
merged 4 commits into from
May 12, 2024

Conversation

tomaszkax86
Copy link
Contributor

Fixes #1649

@tomaszkax86 tomaszkax86 linked an issue Apr 6, 2024 that may be closed by this pull request
label->SetName(name);
if (removeTooltip)
{
auto p = name.find("\\");
Copy link
Contributor
@hexagonrecursion hexagonrecursion May 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we actually rely on the tooltip-removing ability of this method? Where? How? Why? If this only displays the "main" part of the text, what displays the tooltip?

If we don't need this, we can just remove the whole find&substr part and simply always call label->SetName(name, false);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From my understanding, labels remove the tooltip part of the text by default. This might be to allow sharing of texts between labels and other controls that do display tooltips. So if you had a button with text "New player\\Create new player profile", a button would have "New player" text and "Create new player profile" tooltip. But if you set this to a label, it would only display "New player" and had no tooltip.

I don't know why it's done like this, I find this very clunky and confusing; tooltip should always be separate from the main text. But I wrote this code to preserve existing behavior, even if it's weird, in order to hopefully not introduce any new bugs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found an example, where we do depend on tooltip removal

This appears to contain both the tooltip for the slider and the label:

stringsEvent[EVENT_INTERFACE_AUTOSAVE_SLOTS] = TR("Autosave slots\\How many autosave slots you'll have");

psl = pw->CreateSlider(pos, ddim, -1, EVENT_INTERFACE_AUTOSAVE_SLOTS);
psl->SetState(STATE_SHADOW);
psl->SetLimit(1.0f, 10.0f);
psl->SetArrowStep(1.0f);
pos.y += ddim.y/2;
GetResource(RES_EVENT, EVENT_INTERFACE_AUTOSAVE_SLOTS, name);
pl = pw->CreateLabel(pos, ddim, 0, EVENT_LABEL1, name);

image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding boolean flags that make a subroutine do something different hurts readability.

  • When reading foo(..., false) one has to find the declaration of foo() before one can get any hints as to what false does.
  • It is difficult to do a text search (grep) for all places where the subroutine is called with false.

It is often preferable to add a new subroutine instead of adding a boolean flag to an existing subroutine. I suggest adding a CreateLabelRaw() method instead of adding the removeTooltip flag. CreateLabelRaw() would not strip the tooltip, CreateLabel() would keep the existing behaviour.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. This is already confusing, no point in making this worse. I'll add a separate factory method for raw labels.

While at it, I think SetName() should be refactored into SetText(), SetTooltip() and SetTextTooltip(). It's not clear at all what SetName() does unless we analyze the code and GetName() only returns the text part which is even more confusing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Turns out that refactoring SetName() will take a lot more work than I anticipated. I'd leave it the way it is, it can be addressed in a separate issue. I did the other change though.

Copy link
Contributor
@hexagonrecursion hexagonrecursion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have tested the changes and found a bug.

When I run the following code at first everything works as expected:

extern void object::New()
{
	message("foo\\bar");
	wait(1);
	message("foo\\bar");
	wait(1);
	message("foo\\bar");
}

image

But after one of the messages times-out the other two loose the part after the backslash:

image

I think this line is the culprit:

pl1->SetName(pl2->GetName());

@hexagonrecursion
Copy link
Contributor

Is this ready for review?

@tomaszkax86
Copy link
Contributor Author

I think current fix is enough for now, unless you found new bugs or something it's ready for review.

Changing SetName() and its weirdness will require proper refactoring. I'll make a separate issue for that.

Copy link
Contributor
@hexagonrecursion hexagonrecursion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested this patch. It appears to work

@tomaszkax86 tomaszkax86 merged commit c56d240 into dev May 12, 2024
17 checks passed
@tomaszkax86 tomaszkax86 deleted the 1649-the-message-instruction-and-character-escaping branch May 12, 2024 11:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

The message() instruction and character escaping.
3 participants
0