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

Property completion can't be filtered #101201

Open
KoBeWi opened this issue Jan 7, 2025 · 6 comments
Open

Property completion can't be filtered #101201

KoBeWi opened this issue Jan 7, 2025 · 6 comments

Comments

@KoBeWi
Copy link
Member

KoBeWi commented Jan 7, 2025

Tested versions

4.4 dev7

System information

W10

Issue description

tween_property() method provides completion for property names. The problem is that you can't search for a property.

godot.windows.editor.dev.x86_64_jKcuqVgt8Q.mp4

As soon as you type something, the completion popup switches to properties of the current object instead of property names. If you try to start with quote, the completion disappears completely.

Steps to reproduce

  1. Add this code in a script
func _ready() -> void:
	var tw := create_tween()
	tw.tween_property($icon, 

($icon is a Sprite2D)
2. Try to filter a property in autocompletion popup

Minimal reproduction project (MRP)

N/A

@Cere-dev
Copy link

Cere-dev commented Jan 7, 2025

I'm almost sure that's because the engine/GDScript doesn't know yet the type of the Node you are referring to.
If you prepare the node beforehand it will autocomplete properly.
Tested with (using a Node3D I had in another project):

extends Node3D

@onready var icon: Node2D = $icon

# Called when the node enters the scene tree for the first time.
func _ready() -> void:
	var tw := create_tween()
	tw.tween_property(icon,
Image

@KoBeWi
Copy link
Member Author

KoBeWi commented Jan 7, 2025

Maybe it doesn't know the type, but it's able to show the list of properties. If it shows the list, the list should be usable.

@Cere-dev
Copy link

Cere-dev commented Jan 7, 2025

Maybe it doesn't know the type, but it's able to show the list of properties. If it shows the list, the list should be usable.

How can show properties of something it still doesn't know what type is?
As the docs says, the dollar sign is like get_node, and get_node still needs to specify which type of node it is (for example, when casting) if you want to edit any property of it.
From the total respect! ✊

@KoBeWi
Copy link
Member Author

KoBeWi commented Jan 7, 2025

On the video I attached you can see that the list of properties does display, you just can't filter it.

@Cere-dev
Copy link

Cere-dev commented Jan 7, 2025

On the video I attached you can see that the list of properties does display, you just can't filter it.

Yep, it displays Node class properties, not Node2D, as get_node expects to return a Node. It still doesn't know you are trying to tween a property of another type of Node.
As a guy who works daily basis with Python, this could be a expected behavior from GDScript. Forces to have a good praxis on how to reference the nodes in use to avoid reference or type issues.
I'm taking a look into the code and check if there's something we can do to reference the object properties we pass at tween_property, as it expects a NodePath as param.

Edit: I just saw you were the guy who help wrote the tween_property lol, I'm sorry if it annoyed you or something, just trying to help on the development.

I'm looking at gdscript_editor.cpp, maybe the issue is in these blocks of code when getting the object.

Edit: Maybe it helps, i confirm native_type of tweened object is Node no matter what you put, unless you cast explicitly.
before cast:
Image
after cast:
Image

@HolonProduction
Copy link
Member

Can reproduce. The problem doesn't really appear when using auto brace (or quotation) closing. When quotes are not auto closed this scenario produces an unclosed string which the parser will never leave since it will encounter EOF before a closing quotation mark. The completion context necessary for the list, only gets produced after the parameter is parsed which it never is in this case. We should probably look into phrase level recovery for the parser when doing autocompletion. There are some other issues that would benefit from this as well.

Very dirty workaround, put this comment at the end of all your files:

#"

Well I guess that's not really an option 😅

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

No branches or pull requests

3 participants