-
Notifications
You must be signed in to change notification settings - Fork 28
First import fixes #155
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
First import fixes #155
Conversation
@@ -0,0 +1,195 @@ | |||
extends Control |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this not want:
@tool
class_name Drag
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh good catch!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK based on the comment below, we want @tool
but not class_name
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly, I just added a fixup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would assume that since Drag
is only loaded from DragManager
, which is itself a @tool
script, then it's not strictly necessary here. But I don't really understand the intricacies of @tool
.
@@ -1,5 +1,4 @@ | |||
@tool | |||
class_name DragDropArea |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the effect of this change – does it prevent the class being visible to the end user?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With this, the class is not registered by name in ClassDB and it can't be referenced directly in other scripts, it must be preloaded. Also, if the script extends Node or a subclass of Node, it won't appear in the UI to the end user when adding a node.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another advantage: it won't collide with classes defined by the end user in the project. Our current Types class has a good chance to conflict given the generic name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll add this explanation to the commit message.
FWIW, I wrote a very similar series in https://github.com/endlessm/godot-block-coding/tree/T35494-godot-4.3-importing last week. With that I was able to import on 4.3 with no warnings or errors. |
var _preview_block: Control | ||
var _snap_points: Array[Node] | ||
var _delete_areas: Array[Rect2] | ||
var action: DragManager.DragAction: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since DragAction
is only used in this class, you can move the enum
here and avoid a circular dependency between DragManager
and Drag
.
@@ -1,5 +1,7 @@ | |||
extends EditorInspectorPlugin | |||
|
|||
const BlockCodePlugin = preload("res://addons/block_code/block_code_plugin.gd") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason for this is actually pretty ugly. It's to get access to the BlockCodePlugin.main_panel
static singleton. It would be better to pass in the handler so that's not needed. I started working on it but set it aside for the moment.
3b82304
to
036f5e9
Compare
Ouch! I didn't saw that branch, sorry. Which one would you like to favour? |
@@ -158,7 +160,7 @@ static func get_categories(blocks: Array[Block], extra_categories: Array[BlockCa | |||
# Accessing a static Callable from a static function fails in 4.2.1. | |||
# Use the fully qualified name. | |||
# https://github.com/godotengine/godot/issues/86032 | |||
cats.sort_custom(CategoryFactory._category_cmp) | |||
cats.sort_custom(_category_cmp) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This invalidates the comment above it. If I read godotengine/godot#86032, I think this will fail on 4.2.1 with an anonymous class. It would be worth testing in 4.2.1. Then I think either we keep the global CategoryFactory
class or change the requirements to 4.2.2.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohh, I'm blind today. Let's keep the global class for now, with a comment.
These are now always preloaded in the scripts that depend on them. Makes the plugin work again after enabling it. https://phabricator.endlessm.com/T35574
036f5e9
to
c5290bb
Compare
Oh, this is fine. I just pushed it this morning when I saw this PR. I had planned to poke at it a bit more, but since you've got it going here we might as well finish it off. I would consider cherry picking this. Also, as mentioned in a comment above, in my version of breaking out the Drag class, I also moved the I can split out the changes to build |
c5290bb
to
69a7c6b
Compare
@dbnicholson thanks! Cherry-picked the instructions tree change. Tested everything again by copying to a new project and the plugin enables fine. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugh. Apparently GUT does not exit with a failure on syntax errors:
[INFO]: using [/home/runner/.local/share/godot/app_userdata/Block Coding Plugin] for temporary output.
Godot version: 4.2.2
GUT version: 9.2.1
SCRIPT ERROR: Parse Error: Could not find type "BlockCategory" in the current scope.
at: GDScript::reload (res://tests/test_category_factory.gd:12)
ERROR: Failed to load script "res://tests/test_category_factory.gd" with error "Parse error".
at: load (modules/gdscript/gdscript.cpp:2726)
[WARNING]: Ignoring script res://tests/test_category_factory.gd because it does not extend GutTest
res://tests/test_instruction_tree.gd
* test_single_node_text
* test_root_depth_text
* test_child_node_text
* test_sibling_node_text
* test_tree_node_text
* test_script_no_nodes
* test_script_no_entry_blocks
* test_basic_script
SCRIPT ERROR: Invalid call. Nonexistent function 'insert_snapped_block' in base 'Nil'.
at: test_basic_script (res://tests/test_instruction_tree.gd:[13](https://github.com/endlessm/godot-block-coding/actions/runs/10062323917/job/27814558872?pr=155#step:5:14)4)
[Orphans]: 16 new orphans in test.
* test_multiple_entry_script
SCRIPT ERROR: Invalid call. Nonexistent function 'insert_snapped_block' in base 'Nil'.
at: test_multiple_entry_script (res://tests/test_instruction_tree.gd:162)
[Orphans]: 16 new orphans in test.
* test_signal_script
SCRIPT ERROR: Invalid call. Nonexistent function 'insert_snapped_block' in base 'Nil'.
at: test_signal_script (res://tests/test_instruction_tree.gd:195)
[Orphans]: [14](https://github.com/endlessm/godot-block-coding/actions/runs/10062323917/job/27814558872?pr=155#step:5:15)5 new orphans in test.
[Orphans]: 177 new orphans in script.
10/10 passed.
I think all the Nonexistent function 'insert_snapped_block' in base 'Nil'.
are due to reverting c59e48e but not adjusting the tests. That can be fixed separately. However, Could not find type "BlockCategory" in the current scope.
is almost certainly caused by these changes and should be fixed. I'll try to look at making sure GUT fails in these scenarios.
@dbnicholson ouch, so the CI was giving a false positive. Let me fix the one corresponding to this PR. |
I found bitwes/Gut#210 upstream. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good now. I'll take a look at the SnapPoint fix separately.
Except for: - The resources: they must be classes - Block and subclasses: they are accessed by class using the ClassDB - SnapPoint: there is an "is SnapPoint" check - the CategoryFactory (bug in Godot 4.2.1) With this, the class is not registered by name in ClassDB and it can't be referenced directly in other scripts, it must be preloaded. Also, if the script extends Node or a subclass of Node, it won't appear in the UI to the end user when adding a node. Another advantage: it won't collide with classes defined by the end user in the project. Our current Types class has a good chance to conflict given the generic name. Also: delete PackedSceneTreeNode and PackedScene abandoned resources.
This static function has nothing to do with the DragManager class since it's simply walking a tree of Nodes and looking for a Block that has a non-empty scope property set. I'm not sure it really fits in InstructionTree either, but that's a better fit at least. This avoids some dependency issues between DragManager, its inner Drag class, and BlockCanvas. https://phabricator.endlessm.com/T35494
23eccb7
to
626ab89
Compare
https://phabricator.endlessm.com/T35574