TextureProgressBar has always visible Gizmo when setting Fill Mode to 4, 5 or 8

[KaenguruuDev]

Tested versions

Reproducible in: v4.3.stable.mono.official [77dcf97] (Latest)

System information

Godot v4.3.stable.mono - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 Ti (NVIDIA; 32.0.15.6094) - AMD Ryzen 7 5800X 8-Core Processor (16 Threads)

Issue description

When selecting either "Clockwise", "Counter Clockwise" or "Clockwise and Counter Clockwise" as the FillMode, a cross is displayed in the center of the rect. This does not disappear, even when selecting another node or left clicking somewhere else in the scene view. Additionally, the crosshair is also visible when the TextureProgressBar node is used in an EditorPlugin.

Steps to reproduce

1. Add a TextureProgressBar to your scene.
2. Set it's Fill Mode to either "Clockwise", "Counter Clockwise" or "Clockwise and Counter Clockwise"
3. A crosshair will show up in the center. If you now click somewhere else or select another node, it will not disappear.

Minimal reproduction project (MRP)

Mrp.zip

[AThousandShips]

This is done by design, but should probably be something you can configure, and not do when used in plugins etc:

godot/scene/gui/texture_progress_bar.cpp

Lines 538 to 553 in 4788f54

	// Draw a reference cross.
	if (Engine::get_singleton()->is_editor_hint()) {
	Point2 p;
	if (nine_patch_stretch) {
	p = get_size();
	} else {
	p = progress->get_size();
	}
	p *= get_relative_center();
	p += progress_offset;
	p = p.floor();
	draw_line(p - Point2(8, 0), p + Point2(8, 0), Color(0.9, 0.5, 0.5), 2);
	draw_line(p - Point2(0, 8), p + Point2(0, 8), Color(0.9, 0.5, 0.5), 2);
	}

[KaenguruuDev]

A few questions:

1. What is the purpose of that reference cross?
2. Should Plugins be handled like if the node was in an actual "game scene"?
3. Would it make sense if it was more an option to enable the reference cross independent from what FillMode is selected?

[AThousandShips]

1. It's to help you align things I'd say
2. That would be hard, though we could use is_part_of_edited_scene, will see if I can test that out some
3. I'd say that'd be the most useful solution

[arkology]

I think this maybe could be reworked to use Marker2D as internal node.

[arkology]

I made dirty but working prototype and this is how it may look:

	4.4dev2	Prototype
1024x1024
48x48

And you should be able to access crosshair from code as internal Marker2D child node.

I change crosshair visibility inside set_fill_mode(), so you should be able to change Marker2D visibility after setting fill mode.

[arkology]

Another possible solution - add editor-only metadata to set crosshair visibility.

[KaenguruuDev]

Sorry for not answering for so long I got distracted again. Does your prototype allow for disabling the crosshair even in the normal editor (without having to attatch a tool script or something to the node)?

[arkology]

Sorry for not answering for so long I got distracted again. Does your prototype allow for disabling the crosshair even in the normal editor (without having to attatch a tool script or something to the node)?

No, I did not add/change any methods. You still should change visibility of internal Marker2D node using script. Having additional parameters or methods for this looks like overkill.
Also there is controversial moment - should it be always added (for consistency) or only for editor?
Moreover, Marker2D is Node2D and TextureProgressBar is Control.
So this is not an ideal solution at the moment, and the implementation details should be discussed in more detail.

[arkology]

Oh, it looks like this problem was reported a few years ago.
See #46266