Remove trailing whitespace and irregular whitespace

tutorials/plugins/android/android_plugin.rst

@@ -6,10 +6,10 @@ Creating Android plugins (Godot 4.0+)
 Introduction
 ------------
 
-Android plugins are powerful tools to extend the capabilities of the Godot engine 
-by tapping into the functionality provided by the Android platform and ecosystem. 
+Android plugins are powerful tools to extend the capabilities of the Godot engine
+by tapping into the functionality provided by the Android platform and ecosystem.
 
-Mobile gaming monetization is one such example since it requires features 
+Mobile gaming monetization is one such example since it requires features
 and capabilities that don't belong to the core feature set of a game engine:
 
 -  Analytics
@@ -40,7 +40,7 @@ the default, rendering plugins for Godot 3.2.0 incompatible with Godot 4.0.
 
 As a prerequisite, make sure you understand how to set up a :ref:`custom build environment<doc_android_custom_build>` for Android.
 
-At its core, a Godot Android plugin is a `Android archive library <https://developer.android.com/studio/projects/android-library#aar-contents>`_ (*aar* archive file) 
+At its core, a Godot Android plugin is a `Android archive library <https://developer.android.com/studio/projects/android-library#aar-contents>`_ (*aar* archive file)
 with the following caveats:
 
 -  The library must have a dependency on the Godot engine library (``godot-lib.x.y.aar``). A stable version is made available for each Godot release.
@@ -50,7 +50,7 @@ with the following caveats:
 Building a Android plugin
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
-**Prerequisite:** `Android Studio <https://developer.android.com/studio>`_ is strongly recommended as the IDE to use to create Android plugins. 
+**Prerequisite:** `Android Studio <https://developer.android.com/studio>`_ is strongly recommended as the IDE to use to create Android plugins.
 The instructions below assumes that you're using Android Studio.
 
 1.  Follow `these instructions <https://developer.android.com/studio/projects/android-library>`__ to create an Android library module for your plugin.
@@ -74,17 +74,17 @@ The instructions below assumes that you're using Android Studio.
     -   Add the ``<application></application>`` tag if it's missing.
 
     -   In the ``<application>`` tag, add a ``<meta-data>`` tag setup as follow::
-        
-            <meta-data 
-                android:name="org.godotengine.plugin.v1.[PluginName]" 
+
+            <meta-data
+                android:name="org.godotengine.plugin.v1.[PluginName]"
                 android:value="[plugin.init.ClassFullName]" />
 
         Where ``PluginName`` is the name of the plugin, and ``plugin.init.ClassFullName`` is the full name (package + class name) of the plugin loading class.
 
-5.  Add the remaining logic for your plugin and run the ``gradlew build`` command to generate the plugin's ``aar`` file. 
+5.  Add the remaining logic for your plugin and run the ``gradlew build`` command to generate the plugin's ``aar`` file.
     The build will likely generate both a ``debug`` and ``release`` ``aar`` files. Depending on your need, pick only one version (usually the ``release`` one) which to provide your users with.
 
-**Note:** The plugin's ``aar`` filename must match the following pattern: ``[PluginName]*.aar`` 
+**Note:** The plugin's ``aar`` filename must match the following pattern: ``[PluginName]*.aar``
 where ``PluginName`` is the name of the plugin in camel case (e.g: ``GodotPayment.release.aar``).
 
 Loading and using a Android plugin
@@ -106,12 +106,12 @@ Bundling GDNative resources
 A Android plugin can define and provide C/C++ GDNative resources, either to provide and/or access functionality from the game logic.
 The GDNative resources can be bundled within the plugin ``aar`` file which simplifies the distribution and deployment process:
 
-    -   The shared libraries (``.so``) for the defined GDNative libraries will be automatically bundled by the ``aar`` build system. 
+    -   The shared libraries (``.so``) for the defined GDNative libraries will be automatically bundled by the ``aar`` build system.
 
-    -   Godot ``*.gdnlib`` and ``*.gdns`` resource files must be manually defined in the plugin ``assets`` directory. 
+    -   Godot ``*.gdnlib`` and ``*.gdns`` resource files must be manually defined in the plugin ``assets`` directory.
         The recommended path for these resources relative to the ``assets`` directory should be: ``godot/plugin/v1/[PluginName]/``.
 
-For GDNative libraries, the plugin singleton object must override the ``org.godotengine.godot.plugin.GodotPlugin::getPluginGDNativeLibrariesPaths()`` method, 
+For GDNative libraries, the plugin singleton object must override the ``org.godotengine.godot.plugin.GodotPlugin::getPluginGDNativeLibrariesPaths()`` method,
 and return the paths to the bundled GDNative libraries config files (``*.gdnlib``). The paths must be relative to the ``assets`` directory.
 At runtime, the plugin will provide these paths to Godot core which will use them to load and initialize the bundled GDNative libraries.
 

tutorials/plugins/editor/making_plugins.rst

@@ -28,7 +28,7 @@ The first thing you need for the editor to identify a new plugin is to
 create two files: a ``plugin.cfg`` for configuration and a tool script with the
 functionality. Plugins have a standard path like ``addons/plugin_name`` inside
 the project folder. Godot provides a dialog for generating those files and
-placing them where they need to be. 
+placing them where they need to be.
 
 In the main toolbar, click the ``Project`` dropdown. Then click
 ``Project Settings...``. Go to the ``Plugins`` tab and then click
@@ -87,7 +87,7 @@ like this:
 .. _doc_making_plugins_template_code:
 .. tabs::
  .. code-tab:: gdscript GDScript
- 
+
     tool
     extends EditorPlugin
 
@@ -100,7 +100,7 @@ like this:
         pass
 
  .. code-tab:: csharp
- 
+
     #if TOOLS
     using Godot;
     using System;
@@ -152,7 +152,7 @@ clicked. For that, we'll need a simple script that extends from
 
 .. tabs::
  .. code-tab:: gdscript GDScript
- 
+
     tool
     extends Button
 
@@ -163,7 +163,7 @@ clicked. For that, we'll need a simple script that extends from
         print("You clicked me!")
 
  .. code-tab:: csharp
- 
+
     using Godot;
     using System;
 
@@ -194,7 +194,7 @@ dialog. For that, change the ``custom_node.gd`` script to the following:
 
 .. tabs::
  .. code-tab:: gdscript GDScript
- 
+
     tool
     extends EditorPlugin
 
@@ -209,7 +209,7 @@ dialog. For that, change the ``custom_node.gd`` script to the following:
         remove_custom_type("MyButton")
 
  .. code-tab:: csharp
- 
+
     #if TOOLS
     using Godot;
     using System;
@@ -261,7 +261,7 @@ add the following content to it:
 
 .. tabs::
  .. code-tab:: gdscript GDScript
- 
+
     [plugin]
 
     name="My Custom Dock"
@@ -271,7 +271,7 @@ add the following content to it:
     script="custom_dock.gd"
 
  .. code-tab:: csharp
- 
+
     [plugin]
 
     name="My Custom Dock"
@@ -308,7 +308,7 @@ The script could look like this:
 
 .. tabs::
  .. code-tab:: gdscript GDScript
- 
+
     tool
     extends EditorPlugin
 
@@ -332,7 +332,7 @@ The script could look like this:
         dock.free()
 
  .. code-tab:: csharp
- 
+
     #if TOOLS
     using Godot;
     using System;
@@ -341,7 +341,7 @@ The script could look like this:
     public class CustomDock : EditorPlugin
     {
         Control dock;
-    
+
         public override void _EnterTree()
         {
             dock = (Control)GD.Load<PackedScene>("addons/my_custom_dock/my_dock.tscn").Instance();

tutorials/plugins/editor/spatial_gizmos.rst

@@ -9,9 +9,9 @@ Introduction
 Spatial gizmo plugins are used by the editor and custom plugins to define the
 gizmos attached to any kind of Spatial node.
 
-This tutorial will show you the two main approaches to defining your own custom 
-gizmos. The first option works well for simple gizmos and creates less clutter in 
-your plugin structure, while the second one will let you store some per-gizmo data. 
+This tutorial will show you the two main approaches to defining your own custom
+gizmos. The first option works well for simple gizmos and creates less clutter in
+your plugin structure, while the second one will let you store some per-gizmo data.
 
 .. note:: This tutorial assumes you already know how to make generic plugins. If
           in doubt, refer to the :ref:`doc_making_plugins` page.
@@ -19,17 +19,17 @@ your plugin structure, while the second one will let you store some per-gizmo da
 The EditorSpatialGizmoPlugin
 ----------------------------
 
-Regardless of the approach we choose, we will need to create a new 
+Regardless of the approach we choose, we will need to create a new
 :ref:`EditorSpatialGizmoPlugin <class_EditorSpatialGizmoPlugin>`. This will allow
-us to set a name for the new gizmo type and define other behaviors such as whether 
+us to set a name for the new gizmo type and define other behaviors such as whether
 the gizmo can be hidden or not.
 
 This would be a basic setup:
 
 ::
-    
-    # MyCustomGizmoPlugin.gd 
-    
+
+    # MyCustomGizmoPlugin.gd
+
     extends EditorSpatialGizmoPlugin
 
     func get_name():
@@ -54,8 +54,8 @@ This would be a basic setup:
         remove_spatial_gizmo_plugin(gizmo_plugin)
 
 
-For simple gizmos, just inheriting :ref:`EditorSpatialGizmoPlugin <class_EditorSpatialGizmoPlugin>` 
-is enough. If you want to store some per-gizmo data or you are porting a Godot 3.0 gizmo 
+For simple gizmos, just inheriting :ref:`EditorSpatialGizmoPlugin <class_EditorSpatialGizmoPlugin>`
+is enough. If you want to store some per-gizmo data or you are porting a Godot 3.0 gizmo
 to 3.1+, you should go with the second approach.
 
 
@@ -66,7 +66,7 @@ The first step is to, in our custom gizmo plugin, override the :ref:`has_gizmo()
 method so that it returns ``true`` when the spatial parameter is of our target type.
 
 ::
-    
+
     # ...
 
     func has_gizmo(spatial):
@@ -77,7 +77,7 @@ Then we can override methods like :ref:`redraw()<class_EditorSpatialGizmoPlugin_
 or all the handle related ones.
 
 ::
-    
+
     # ...
 
     func _init():
@@ -88,9 +88,9 @@ or all the handle related ones.
         gizmo.clear()
 
         var spatial = gizmo.get_spatial_node()
-        
+
         var lines = PackedVector3Array()
-        
+
         lines.push_back(Vector3(0, 1, 0))
         lines.push_back(Vector3(0, spatial.my_custom_value, 0))
 
@@ -98,15 +98,15 @@ or all the handle related ones.
 
         handles.push_back(Vector3(0, 1, 0))
         handles.push_back(Vector3(0, spatial.my_custom_value, 0))
-        
+
         gizmo.add_lines(lines, get_material("main", gizmo), false)
         gizmo.add_handles(handles, get_material("handles", gizmo))
 
     # ...
 
 Note that we created a material in the `_init` method, and retrieved it in the `redraw`
-method using :ref:`get_material()<class_EditorSpatialGizmoPlugin_method_get_material>`. This 
-method retrieves one of the material's variants depending on the state of the gizmo 
+method using :ref:`get_material()<class_EditorSpatialGizmoPlugin_method_get_material>`. This
+method retrieves one of the material's variants depending on the state of the gizmo
 (selected and/or editable).
 
 So the final plugin would look somewhat like this:
@@ -128,9 +128,9 @@ So the final plugin would look somewhat like this:
         gizmo.clear()
 
         var spatial = gizmo.get_spatial_node()
-        
+
         var lines = PackedVector3Array()
-        
+
         lines.push_back(Vector3(0, 1, 0))
         lines.push_back(Vector3(0, spatial.my_custom_value, 0))
 
@@ -138,7 +138,7 @@ So the final plugin would look somewhat like this:
 
         handles.push_back(Vector3(0, 1, 0))
         handles.push_back(Vector3(0, spatial.my_custom_value, 0))
-        
+
         gizmo.add_lines(lines, get_material("main", gizmo), false)
         gizmo.add_handles(handles, get_material("handles", gizmo))
 
@@ -153,16 +153,16 @@ Alternative approach
 --------------------
 
 In some cases we want to provide our own implementation of :ref:`EditorSpatialGizmo<class_EditorSpatialGizmo>`,
-maybe because we want to have some state stored in each gizmo or because we are porting 
+maybe because we want to have some state stored in each gizmo or because we are porting
 an old gizmo plugin and we don't want to go through the rewriting process.
 
-In these cases all we need to do is, in our new gizmo plugin, override 
+In these cases all we need to do is, in our new gizmo plugin, override
 :ref:`create_gizmo()<class_EditorSpatialGizmoPlugin_method_create_gizmo>`, so it returns our custom gizmo implementation
 for the Spatial nodes we want to target.
 
 ::
 
-    # MyCustomGizmoPlugin.gd 
+    # MyCustomGizmoPlugin.gd
     extends EditorSpatialGizmoPlugin
 
     const MyCustomSpatial = preload("res://addons/my-addon/MyCustomSpatial.gd")
@@ -187,16 +187,16 @@ This way all the gizmo logic and drawing methods can be implemented in a new cla
 
     extends EditorSpatialGizmo
 
-    # You can store data in the gizmo itself (more useful when working with handles)  
+    # You can store data in the gizmo itself (more useful when working with handles)
     var gizmo_size = 3.0
 
     func redraw():
         clear()
 
         var spatial = get_spatial_node()
-        
+
         var lines = PackedVector3Array()
-        
+
         lines.push_back(Vector3(0, 1, 0))
         lines.push_back(Vector3(gizmo_size, spatial.my_custom_value, 0))
 

tutorials/plugins/editor/visual_shader_plugins.rst

@@ -118,11 +118,11 @@ all you need to initialize your plugin.
                 vec4 iy = vec4(Pi0.yy, Pi1.yy);
                 vec4 iz0 = vec4(Pi0.z);
                 vec4 iz1 = vec4(Pi1.z);
-                
+
                 vec4 ixy = permute(permute(ix) + iy);
                 vec4 ixy0 = permute(ixy + iz0);
                 vec4 ixy1 = permute(ixy + iz1);
-                
+
                 vec4 gx0 = ixy0 * (1.0 / 7.0);
                 vec4 gy0 = fract(floor(gx0) * (1.0 / 7.0)) - 0.5;
                 gx0 = fract(gx0);
@@ -130,7 +130,7 @@ all you need to initialize your plugin.
                 vec4 sz0 = step(gz0, vec4(0.0));
                 gx0 -= sz0 * (step(0.0, gx0) - 0.5);
                 gy0 -= sz0 * (step(0.0, gy0) - 0.5);
-                
+
                 vec4 gx1 = ixy1 * (1.0 / 7.0);
                 vec4 gy1 = fract(floor(gx1) * (1.0 / 7.0)) - 0.5;
                 gx1 = fract(gx1);
@@ -138,7 +138,7 @@ all you need to initialize your plugin.
                 vec4 sz1 = step(gz1, vec4(0.0));
                 gx1 -= sz1 * (step(0.0, gx1) - 0.5);
                 gy1 -= sz1 * (step(0.0, gy1) - 0.5);
-                
+
                 vec3 g000 = vec3(gx0.x, gy0.x, gz0.x);
                 vec3 g100 = vec3(gx0.y, gy0.y, gz0.y);
                 vec3 g010 = vec3(gx0.z, gy0.z, gz0.z);
@@ -147,7 +147,7 @@ all you need to initialize your plugin.
                 vec3 g101 = vec3(gx1.y, gy1.y, gz1.y);
                 vec3 g011 = vec3(gx1.z, gy1.z, gz1.z);
                 vec3 g111 = vec3(gx1.w, gy1.w, gz1.w);
-                
+
                 vec4 norm0 = taylorInvSqrt(vec4(dot(g000, g000), dot(g010, g010), dot(g100, g100), dot(g110, g110)));
                 g000 *= norm0.x;
                 g010 *= norm0.y;
@@ -158,7 +158,7 @@ all you need to initialize your plugin.
                 g011 *= norm1.y;
                 g101 *= norm1.z;
                 g111 *= norm1.w;
-                
+
                 float n000 = dot(g000, Pf0);
                 float n100 = dot(g100, vec3(Pf1.x, Pf0.yz));
                 float n010 = dot(g010, vec3(Pf0.x, Pf1.y, Pf0.z));
@@ -167,11 +167,11 @@ all you need to initialize your plugin.
                 float n101 = dot(g101, vec3(Pf1.x, Pf0.y, Pf1.z));
                 float n011 = dot(g011, vec3(Pf0.x, Pf1.yz));
                 float n111 = dot(g111, Pf1);
-                
+
                 vec3 fade_xyz = fade(Pf0);
                 vec4 n_z = mix(vec4(n000, n100, n010, n110), vec4(n001, n101, n011, n111), fade_xyz.z);
                 vec2 n_yz = mix(n_z.xy, n_z.zw, fade_xyz.y);
-                float n_xyz = mix(n_yz.x, n_yz.y, fade_xyz.x); 
+                float n_xyz = mix(n_yz.x, n_yz.y, fade_xyz.x);
                 return 2.2 * n_xyz;
             }
         """

tutorials/plugins/gdnative/gdnative-cpp-example.rst

@@ -132,7 +132,7 @@ To generate and compile the bindings, use this command (replacing ``<platform>``
 with ``windows``, ``linux`` or ``osx`` depending on your OS):
 
 To speed up compilation, add `-jN` at the end of the SCons command line where `N` is the number of CPU threads you have on your system. The example below uses 4 threads.
- 
+
 .. code-block:: none
 
     cd godot-cpp