Various semantic updates; prefer "godot-rust" over "gdext"

Remove Godot 3->4 differences, no longer relevant today.

Author: Bromeon

.github/ISSUE_TEMPLATE/outdated.md

@@ -9,6 +9,6 @@ assignees: ''
 
 <!-- 
 Please include a brief overview of the API change and which documentation will need to be updated to reflect this.
-If you happen to have a link to the gdext PRs, that's a bonus.
+If you happen to have a link to the godot-rust PRs, that's a bonus.
 -->
 

ReadMe.md

@@ -1,6 +1,6 @@
 # The godot-rust book
 
-The godot-rust book is a user guide for **gdext**, the Rust bindings to Godot 4.
+This book is a user guide for **godot-rust**, the Rust bindings to Godot 4.
 It covers a large part of the concepts and complements [the API docs][gdext-docs].
 There is also [gdnative-book] for Godot 3.
 
@@ -56,7 +56,7 @@ and read the [contributing guidelines][gdext-contribute].
 
 ## License
 
-Like gdext itself, the gdext book is licensed under [MPL 2.0][mpl].
+Like godot-rust itself, the godot-rust book is licensed under [MPL 2.0][mpl].
 
 [book-web]: https://godot-rust.github.io/book
 [gdext]: https://github.com/godot-rust/gdext

src/SUMMARY.md

@@ -38,7 +38,7 @@
   - [`Resource` savers and loaders](recipes/resource-saver-loader.md)
   - [Custom node icons](recipes/custom-icons.md)
 - [Ecosystem](ecosystem/index.md)
-- [Contributing to gdext](contribute/index.md)
+- [Contributing to godot-rust](contribute/index.md)
   - [Philosophy](contribute/philosophy.md)
   - [Dev tools and testing](contribute/dev-tools.md)
   - [Code and API conventions](contribute/conventions.md)

src/contribute/conventions.md

@@ -88,7 +88,7 @@ We use separators starting with  `// ---` to visually divide sections of related
 1. Avoid tuple-enums `enum E { Var(u32, u32) }` and tuple-structs `struct S(u32, u32)` with more than 1 field. Use named fields instead.
 
 2. Derive order is `#[derive(GdextTrait, ExternTrait, Default, Copy, Clone, Eq, PartialEq, Ord, PartialOrd, Hash, Debug)]`.
-   - `GdextTrait` is a custom derive defined by gdext itself (in any of the crates).
+   - `GdextTrait` is a custom derive defined by godot-rust itself (in any of the crates).
    - `ExternTrait` is a custom derive by a third-party crate, e.g. `nanoserde`.
    - The standard traits follow order _construction, comparison, hashing, debug display_.
      More expressive ones (`Copy`, `Eq`) precede their implied counterparts (`Clone`, `PartialEq`).
@@ -127,7 +127,7 @@ Concerns both `#[proc_macro_attribute]` and the attributes attached to a `#[proc
 
 The reason for this choice is that each attribute maps nicely to a map, where values can have different types.
 This allows for a recognizable and consistent syntax across all proc-macro APIs. Implementation-wise, this pattern is
-directly supported by the `KvParser` type in gdext, which makes it easy to parse and interpret attributes.
+directly supported by the `KvParser` type in godot-rust, which makes it easy to parse and interpret attributes.
 
 
 [lib-public-api]: https://godot-rust.github.io/docs/gdext/master/godot/#public-api

src/contribute/dev-tools.md

@@ -40,7 +40,7 @@ Use `dok` instead of `doc` to open the page in the browser.
 
 ### Unit tests
 
-Because most of gdext interacts with the Godot engine, which is not available from the test executable, unit tests
+Because most of godot-rust interacts with the Godot engine, which is not available from the test executable, unit tests
 (using `cargo test` and the `#[test]` attribute) are pretty limited in scope. They are primarily used for Rust-only logic.
 
 Unit tests also include [doctests], which are Rust code snippets embedded in the documentation.
@@ -122,7 +122,8 @@ cargo fmt
 
 ## Continuous Integration
 
-If you want to have the full CI experience, you can experiment as much as you like on your own gdext fork, before submitting a pull request.
+If you want to have the full CI experience, you can experiment as much as you like on your own fork of the repository, before
+submitting a pull request.
 
 
 ### Manually trigger a CI run

src/contribute/index.md

@@ -5,10 +5,10 @@
   ~ file, You can obtain one at https://mozilla.org/MPL/2.0/.
 -->
 
-# Contributing to gdext
+# Contributing to godot-rust
 
 This chapter provides deeper information for people who are interested in contributing to the library.
-In case you are simply using gdext, you can skip this chapter.
+In case you are simply _using_ godot-rust, you can skip this chapter.
 
 If you haven't already, please read the [Contributing guidelines] in the repository first.
 The rest of this chapter explains developer tools and workflows in more detail. Check out the respective subchapters.

src/contribute/philosophy.md

@@ -9,11 +9,11 @@
 
 Different gamedev projects have different goals, which determines how APIs are built and how they support various use cases.
 
-Understanding the vision behind gdext allows users to:
+Understanding the vision behind godot-rust allows users to:
 
 - decide whether the library is the right choice for them
 - comprehend design decisions that have influenced the library's status quo
-- contribute in ways that align with the project, thus saving time.
+- contribute in ways that align with the project.
 
 
 ## Mission statement
@@ -27,7 +27,7 @@ It focuses on a productive workflow for the development of games and interactive
 ```
 
 In our case, pragmatism means that progress is driven by solutions to real-world problems, rather than theoretical purity.
-Engineering comes with trade-offs, and gdext in particular is rather atypical for a Rust project. As such, we may sometimes deviate
+Engineering comes with trade-offs, and godot-rust is rather atypical for a Rust project. As such, we may sometimes deviate
 from Rust best practices that may apply in a clean-room setting, but fall apart when exposed to the interaction with a C++ game engine.
 
 At the end of the day, people use Godot and Rust to build games, simulations or other interactive applications. The library should be designed
@@ -38,12 +38,12 @@ In many ways, we follow [similar principles as the Godot engine][godot-contribut
 
 ## Scope
 
-gdext is primarily a _binding_ to the Godot engine. A priority is to make Godot functionality accessible for Rust developers, in ways
+godot-rust is primarily a _binding_ to the Godot engine. A priority is to make Godot functionality accessible for Rust developers, in ways
 that exploit the strengths of the language, while minimizing the friction.
 
 Since we are not building our own game engine, features need to be related to Godot. We aim to build a robust core for everyday workflows,
 while avoiding overly niche features. Integrations with other parts of the gamedev ecosystem (e.g. ECS, asset pipelines, GUI) are out of
-scope and best implemented as extensions.
+scope and [best implemented as extensions][ecosystem].
 
 
 ## API design principles
@@ -94,3 +94,4 @@ This aligns ideas early and saves time on approaches that may not work.
 [wiki-yagni]: https://en.wikipedia.org/wiki/YAGNI
 [lib-ergonomics-panics]: https://godot-rust.github.io/docs/gdext/master/godot/#ergonomics-and-panics
 [godot-contributor-best-practices]: https://docs.godotengine.org/en/stable/contributing/development/best_practices_for_engine_contributors.html
+[ecosystem]: ../ecosystem

src/godot-api/builtins.md

@@ -49,7 +49,7 @@ Here is an exhaustive list of all built-in types, by category. We use the GDScri
 
 ### Rust mapping
 
-Rust types in the gdext API represent the corresponding Godot types in the closest way possible. They are used in parameter and return type
+Rust types in the library's API represent the corresponding Godot types in the closest way possible. They are used in parameter and return type
 position of API functions, for example. They are accessible through `godot::builtin`, and most symbols are also part of the prelude.
 
 Most builtins have a 1:1 equivalent (e.g. `Vector2f`, `Color` etc.). The following list highlights some noteworthy mappings:

src/godot-api/functions.md

@@ -7,7 +7,7 @@
 
 # Calling functions
 
-In general, the gdext library maps Godot functions in a way that feels as idiomatic as possible in Rust. Sometimes, signatures differ from
+In general, the godot-rust library maps Godot functions in a way that feels as idiomatic as possible in Rust. Sometimes, signatures differ from
 GDScript, and this page will go into such differences.
 
 
@@ -101,7 +101,7 @@ let button = dialog.add_button("Yes");
 
 Because Rust does not support default parameters, we have to emulate the other calls differently. We decided to use the builder pattern.
 
-Builder methods in gdext receive **the `_ex` suffix**. Such a method takes all required parameters, like the base method. It returns a builder
+Builder methods in the library receive **the `_ex` suffix**. Such a method takes all required parameters, like the base method. It returns a builder
 object, which offers methods to set the optional parameters by their name. Eventually, a `done()` method concludes the builder and returns the
 result of the Godot function call.
 

src/godot-api/index.md

@@ -8,7 +8,7 @@
 # Using the Godot API
 
 In this chapter, you will learn how to interact with the Godot engine from Rust code. After introducing you to builtins and objects, we will
-delve into engine API calls and discuss gdext-specific idioms surrounding them.
+delve into engine API calls and discuss godot-rust specific idioms surrounding them.
 
 If you are interested in exposing your own Rust symbols to the engine and to GDScript code, check out the chapter
 [Registering Rust symbols](../register/index.md). It is however strongly recommended to read this chapter first, as it introduces vital concepts.