book: Less usage of once_cell

book/listings/g_object_signals/2/custom_button/imp.rs

@@ -1,11 +1,11 @@
 use std::cell::Cell;
+use std::sync::OnceLock;
 
 use glib::subclass::Signal;
 use glib::Properties;
 use gtk::glib;
 use gtk::prelude::*;
 use gtk::subclass::prelude::*;
-use once_cell::sync::Lazy;
 
 // Object holding the state
 #[derive(Properties, Default)]
@@ -28,12 +28,12 @@ impl ObjectSubclass for CustomButton {
 #[glib::derived_properties]
 impl ObjectImpl for CustomButton {
     fn signals() -> &'static [Signal] {
-        static SIGNALS: Lazy<Vec<Signal>> = Lazy::new(|| {
+        static SIGNALS: OnceLock<Vec<Signal>> = OnceLock::new();
+        SIGNALS.get_or_init(|| {
             vec![Signal::builder("max-number-reached")
                 .param_types([i32::static_type()])
                 .build()]
-        });
-        SIGNALS.as_ref()
+        })
     }
     // ANCHOR_END: object_impl
 

book/src/g_object_signals.md

@@ -32,13 +32,7 @@ Let's see how we can create our own signals.
 Again we do that by extending our `CustomButton`.
 First we override the `signals` method in `ObjectImpl`.
 In order to do that, we need to lazily initialize a static item `SIGNALS`.
-Until [`std::sync::LazyLock`](https://doc.rust-lang.org/std/sync/struct.LazyLock.html) is stabilized, we use [`once_cell::sync::Lazy`](https://docs.rs/once_cell/latest/once_cell/sync/struct.Lazy.html) instead.
-
-This also means, we have to add the `once_cell` crate as dependency by executing:
-
-```
-cargo add once_cell
-```
+[`std::sync::OnceLock`](https://doc.rust-lang.org/std/sync/struct.OnceLock.html) ensures that `SIGNALS` will only be initialized once.
 
 Filename: <a class=file-link href="https://github.com/gtk-rs/gtk4-rs/blob/master/book/listings/g_object_signals/2/custom_button/imp.rs">listings/g_object_signals/2/custom_button/imp.rs</a>
 

book/src/main_event_loop.md

@@ -278,7 +278,15 @@ Since we already run the `glib` main loop on our main thread, we don't want to r
 For this reason, we **avoid** using the `#[tokio::main]` macro or using a top-level `block_on` call.
 Doing this will block one of the runtime's threads with the GLib main loop, which is a waste of resources and a potential source of strange bugs.
 
-Instead, the runtime is manually created and used where needed. Let's bind it to a static variable and initialize it lazily.
+Instead, the runtime is manually created and used where needed.
+It is convenient to bind the runtime to a global variable.
+In order to do that, we add the crate `once_cell`
+
+```
+cargo add once_cell
+```
+
+Let's bind it to a static variable and initialize it lazily with [`once_cell::sync::Lazy`](https://docs.rs/once_cell/latest/once_cell/sync/struct.Lazy.html).
 
 Filename: <a class=file-link href="https://github.com/gtk-rs/gtk4-rs/blob/master/book/listings/main_event_loop/9/main.rs">listings/main_event_loop/9/main.rs</a>
 
@@ -301,10 +309,10 @@ If we now press the button, we should find the following message in our console:
 Status: 200 OK
 ```
 
-We will not need `tokio`, `reqwest` or `ashpd` in the following chapters, so let's remove them again by executing:
+We will not need `tokio`, `once_cell`, `reqwest` or `ashpd` in the following chapters, so let's remove them again by executing:
 
 ```
-cargo remove reqwest tokio ashpd
+cargo remove tokio once_cell reqwest ashpd
 ```
 
 How to find out whether you can spawn an `async` task on the `glib` main loop?