Deryks _dev

Prove the toolchain works

Text appears in your terminal.

Open editor/src/main.rs. It contains what cargo newgenerated:

editor/src/main.rsthe whole file

fn main() {
    println!("Hello, world!");
}

fn declares a function. main is where every Rust program starts. println! ends in ! because it's amacro, not a function — it's rewritten into other code at compile time, which is how it can accept any number of arguments of any type. You'll meet a few macros; the ! is always the tell.

cd editor && cargo run
→ Hello, world!

An empty window

A blank 800×600 window opens on your desktop.

Replace the entire file with this. It's the smallest possible eframeapplication:

editor/src/main.rsreplacing the whole file

use eframe::egui;

struct Editor;

impl eframe::App for Editor {
    fn ui(&mut self, _ui: &mut egui::Ui, _frame: &mut eframe::Frame) {}
}

fn main() -> eframe::Result {
    let options = eframe::NativeOptions {
        viewport: egui::ViewportBuilder::default().with_inner_size([800.0, 600.0]),
        ..Default::default()
    };

    eframe::run_native("editor", options, Box::new(|_cc| Ok(Box::new(Editor))))
}

Three things are worth understanding here, and one is not.

struct Editor; — this declares a type calledEditor that currently holds no data at all. This is your application. Not a window, not a widget: a plain data type that you will hang everything else off. Right now it's empty, which is honest — your editor knows nothing yet.

impl eframe::App for Editor — a trait implementation. A trait is a contract: a list of functions a type must provide in order to be used somewhere. eframe::App is the contract for "something eframe can run as an application," and its one requirement is a function called ui. By writing this block you're saying: Editor can behave as an App, and here's the proof. If you get the signature wrong, the compiler rejects it — you cannot half-implement a trait.

fn ui(&mut self, …) — the function eframe calls to draw a frame. The body is empty {}, so nothing is drawn, so the window is blank. Note &mut self. Ignore it for now; stage 5 is entirely about that one token.

The underscores in _ui and _frame tell the compiler "I know I'm not using this parameter, don't warn me." Drop the underscore on an unused variable and you'll get a warning — a small example of how much Rust nags you, and how much of that nagging turns out to be useful.

cargo run
→ a blank window titled "editor"
First build takes ~30 seconds — it's compiling all 414 crates. Later builds are 1–2 seconds.

Draw something

The word "editor" appears in the window.

Fill in that empty ui body:

editor/src/main.rsin impl eframe::App for Editor

impl eframe::App for Editor {
    fn ui(&mut self, _ui: &mut egui::Ui, _frame: &mut eframe::Frame) {}
    fn ui(&mut self, ui: &mut egui::Ui, _frame: &mut eframe::Frame) {
        egui::CentralPanel::default().show(ui, |ui| {
            ui.heading("editor");
        });
    }
}

A panel is a region of the window. CentralPanel takes whatever space is left after other panels claim theirs; later you'll add a top panel for tabs and a bottom one for a status bar, and the central panel will shrink to fit around them automatically.

.show(ui, |ui| { … }) takes a closure — an anonymous function, written between the pipes. Read it as "inside this panel, do the following." Everything you call on the inner ui gets laid out top to bottom, in the order you write it. There is no layout file and no positioning: the order of your statementsis the layout.

cargo run
→ the window now says editor in large text

Give it something to remember

A line of text you chose appears below the heading.

This stage takes three separate edits, in three different parts of the file. They're below one at a time — do them in order, and don't run anything until all three are in, because the file won't compile in between.

First edit. An editor needs a buffer, so give Editor a field.Replace the empty struct Editor; from stage 2 — don't add alongside it, or you'll define the same name twice and the compiler will say so:

editor/src/main.rstop of the file

use eframe::egui;

struct Editor;
struct Editor {
    text: String,
}

impl Default for Editor {
    fn default() -> Self {
        Self {
            text: "Hello, editor.\n".to_owned(),
        }
    }
}

Second edit — now draw that text. One line, under the heading:

editor/src/main.rsin fn ui, under the heading

        egui::CentralPanel::default().show(ui, |ui| {
            ui.heading("editor");
            ui.label(&self.text);
        });

Third edit, and a different part of the file. Down in main,Box::new(Editor) no longer works: Editor has a field now, so the bare name is just a type, not a value you can put in a box. Miss this one and you get error[E0423]: expected value, found struct `Editor`.

editor/src/main.rsat the bottom of main

    eframe::run_native("editor", options, Box::new(|_cc| Ok(Box::new(Editor))))
    eframe::run_native(
        "editor",
        options,
        Box::new(|_cc| Ok(Box::new(Editor::default()))),
    )

It grew from one line to five only because::default() pushed it past rustfmt's line width, socargo fmt breaks the arguments out. Nothing semantic changed — the same call, wrapped.

String vs &str. Rust has two string types and the difference matters constantly. "Hello, editor.\n" written literally in your source is a &str — a borrowed view of text baked into your compiled binary. It's fixed size and you cannot grow it. AString is owned, heap-allocated, and can grow. A text buffer must grow, so the field is a String, and .to_owned() is what copies the literal into one.

You'll see .to_string(), .to_owned(), andString::from() used for this. They're equivalent here..to_owned() is the most precise about intent: I am taking ownership of a copy.

impl Default for Editor — another trait, this one from Rust's standard library. It means "there is a sensible starting value for this type."Self is shorthand for the type you're implementing on, soSelf { … } constructs an Editor. That's why maincan now say Editor::default().

ui.label(&self.text) — draw the string. The& means borrow it: let the label read your text without taking it away from you. If you wrote self.text without the &, you'd be handing the String over permanently and the compiler would stop you. Ownership is coming into focus.

cargo run
→ "Hello, editor." under the heading. You can't type in it. It's a label.

Make it editable — the stage that fails first

Understand &mut by getting it wrong, on purpose.

A label can't be edited, so swap it for a text box. Try the obvious thing — keep the& you already know:

editor/src/main.rsin fn ui, replacing the label

            ui.heading("editor");
            ui.label(&self.text);
            ui.add(egui::TextEdit::multiline(&self.text));

cargo check
— faster than cargo run, and it won't produce a binary. Use it whenever you're arguing with the compiler.

It doesn't compile. Here's the actual output, verbatim:

error[E0308]: mismatched types
   --> src/main.rs:19:46
    |
 19 |             ui.add(egui::TextEdit::multiline(&self.text));
    |                    ------------------------- ^^^^^^^^^^ types differ in mutability
    |                    |
    |                    arguments to this function are incorrect
    |
    = note: expected mutable reference `&mut dyn TextBuffer`
                       found reference `&String`

This is the heart of Rust. Every value has one owner, and access is granted throughborrows, of which there are exactly two kinds:

The rule underneath: many readers, or one writer — never both at once.That single rule is what lets Rust eliminate data races at compile time, and it's the rule you'll spend the next month arguing with. Make the fix:

editor/src/main.rssame line, in fn ui

            ui.add(egui::TextEdit::multiline(&mut self.text));

Read that as: here is my buffer — you may write directly into it. When the user presses a key, egui pushes that character into your String. There is no copy, no synchronisation step, no "read the value back out afterwards."

And now &mut self from stage 2 makes sense. You can only hand out&mut self.text if you hold exclusive access to self in the first place — a shared borrow can't be upgraded into an exclusive one. That token in the signature is a permission slip, and without it typing would be impossible.

Worth doing: change &mut self to &selfin the ui signature and run cargo check again. You'll get two errors, not one — the borrow error, and a complaint that your ui no longer matches the signatureeframe::App requires. Two different lessons in one mistake. Put it back after.

While you're here, make it look like a code editor — monospaced, full width:

editor/src/main.rsin fn ui, expanding the TextEdit

            ui.add(
                egui::TextEdit::multiline(&mut self.text)
                    .font(egui::TextStyle::Monospace)
                    .desired_width(f32::INFINITY),
            );

cargo run
→ Type in it. This is a text editor now, for a generous definition of "editor".

Prove there's only one source of truth

A live byte count that you never wired up to anything.

One more line, below the text box:

editor/src/main.rsin fn ui, below the TextEdit

                    .desired_width(f32::INFINITY),
            );
            ui.label(format!("{} bytes", self.text.len()));

cargo run
→ a byte counter that moves as you type

This is immediate mode, and it's why we chose egui. In aretained mode toolkit (GTK, Qt, the DOM) you'd create a text box object, register a callback, and keep your data in sync with the widget's copy. Two sources of truth, and most GUI bugs living in the gap. The egui README puts it directly:

"In a retained GUI you create a button, add it to some UI and install some on-click handler (callback)… By contrast, in immediate mode you show the button and interact with it immediately, and you do so every frame."

"You don't have to worry about app state and GUI state being out-of-sync… because the GUI isn't storing any state — it is showing the latest state immediately."

— emilk/egui README

"Every frame" is the model you code against, not what actually happens. egui "only repaints when there is interaction (e.g. mouse movement) or an animation, so if your app is idle, no CPU is wasted" (README FAQ).