From f17a55db2e1b82fe9d7c342443036e15f6e7de01 Mon Sep 17 00:00:00 2001 From: follower Date: Tue, 18 Feb 2020 03:01:57 +1300 Subject: [PATCH] Use more standard terminology. Fix grammar. Change to use node relationship terminology ("sibling") that is both more standard[0] & more inclusive. Fix pluralisation (i.e. "Xs nodes" -> "X nodes"). [0] e.g. https://en.wikipedia.org/wiki/Tree_structure#Terminology_and_properties --- tutorials/plugins/editor/making_main_screen_plugins.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tutorials/plugins/editor/making_main_screen_plugins.rst b/tutorials/plugins/editor/making_main_screen_plugins.rst index 83a904d69..0500aa66e 100644 --- a/tutorials/plugins/editor/making_main_screen_plugins.rst +++ b/tutorials/plugins/editor/making_main_screen_plugins.rst @@ -79,7 +79,7 @@ UI element instantiation, and it will also manage the communication between them As a matter of fact, we wish to design each UI element in their own scene. Different scenes are not aware of each other unless they are both children of a -parent scene, yet they will then require ``get_node("../brother")`` accessors. +parent scene, yet they will then require ``get_node("../sibling")`` accessors. Such practice is more likely to produce errors at runtime, especially if these scenes do not share the same parent node. This is why, they should only be allowed to access their children. @@ -92,7 +92,7 @@ be instanced by ``main_screen_plugin.gd`` script, this one script will also connect each of them to the required signals. .. note:: If the ``main_screen_plugin.gd`` instantiates the UI scenes, won't - they be brothers nodes then? + they be sibling nodes then? Not necessarily: this script may add all UI scenes as children of the same node of the editor's scene tree - but maybe it won't. And the ``main_screen_plugin.gd``