Tweak: Improved Documentation and README.MD

docs/appdev/custom_apps.md

@@ -1,8 +1,13 @@
-# Creating a Custom App (Step-by-Step)
+<div align="center">
+  <h1>Creating a Custom App</h1>
+  <p><em>A step-by-step tutorial on writing a new graphical C application.</em></p>
+</div>
+
+---
 
 This guide explains how to write a new "Hello World" application locally, compile it as an `.elf` binary into the `bin/` folder, and launch it inside BoredOS.
 
-## Step 1: Write the C Source
+## 📝 Step 1: Write the C Source
 
 Applications reside entirely in the `src/userland/` directory. Create a new file, for example, `src/userland/gui/hello.c`.
 
@@ -44,7 +49,7 @@ int main(void) {
 }
 ```
 
-## Step 2: Edit the Makefile
+## ⚙️ Step 2: Edit the Makefile
 
 Now you need to tell the build system to compile `hello.c`. Fortunately, the `src/userland/Makefile` is designed to detect new C files largely automatically!
 
@@ -56,7 +61,7 @@ Now you need to tell the build system to compile `hello.c`. Fortunately, the `sr
     Since you placed the file in `gui/hello.c`, the wildcard logic will pick it up automatically.
 3.  The Makefile will generate `bin/hello.elf` during the build phase.
 
-## Step 3: Bundle it into the OS
+## 📦 Step 3: Bundle it into the OS
 
 The main overarching `Makefile` (in the project root) takes binaries from `src/userland/bin/*.elf` and places them into the `iso_root/bin/` directory, while also adding them to `limine.conf` as loadable boot modules.
 
@@ -69,11 +74,14 @@ The main overarching `Makefile` (in the project root) takes binaries from `src/u
     make clean && make run
     ```
 
-## Step 4: Run it inside BoredOS
+## 🚀 Step 4: Run it inside BoredOS
 
 1.  When BoredOS boots, launch the **Terminal** application.
 2.  The OS automatically maps built applications to standard shell commands. Simply type your application's filename (without the `.elf` extension).
 3.  Type `hello` in the terminal and press Enter.
-4. Your custom window will appear!
+4.  Your custom window will appear!
 
-*you can also open your app by opening the file explorer and navigating to the bin directory and double clicking the executable.*
+> [!NOTE]
+> You can also open your app by opening the file explorer, navigating to the `bin` directory, and double-clicking the executable.
+
+---

docs/appdev/sdk_reference.md

@@ -1,8 +1,13 @@
-# Userland SDK Reference
+<div align="center">
+  <h1>Userland SDK Reference</h1>
+  <p><em>Custom libc implementations and system calls in BoredOS.</em></p>
+</div>
+
+---
 
 BoredOS provides a custom `libc` implementation necessary for writing userland applications (`.elf` binaries). By avoiding a full-blown standard library like `glibc`, the OS ensures a minimal executable footprint tailored strictly to the existing kernel features.
 
-## The Custom libc Structure (`src/userland/libc/`)
+## 🛠️ The Custom libc Structure (`src/userland/libc/`)
 
 The SDK comprises a few key files containing wrappers around kernel system calls:
 
@@ -11,13 +16,14 @@ The SDK comprises a few key files containing wrappers around kernel system calls
 -   `syscall.h` / `syscall.c`: The raw interface to issue `syscall` assembly instructions, routing requests to the kernel.
 -   `libui.h` / `libui.c`: Graphical interface commands (creating windows, drawing pixels, events).
 
-## System Calls Overview
+## 🖧 System Calls Overview
 
 When a userland application wants to interact with the hardware (print to screen, read a file, create a window), it must ask the kernel via a **System Call**.
 
 In BoredOS (`x86_64`), system calls are issued using the `syscall` instruction. The kernel intercepts this instruction and inspects the processor's RAX register to figure out *what* the application wants to do.
 
 The custom `libc` provides `syscallX` wrapper functions that abstract the assembly details:
+
 ```c
 // Example: Performing a minimal system call from userland
 int sys_write(int fd, const char *buf, int len) {
@@ -25,7 +31,7 @@ int sys_write(int fd, const char *buf, int len) {
 }
 ```
 
-### Notable System Calls
+### 📌 Notable System Calls
 
 -   **`SYS_WRITE` (1)**: Currently acts as a generic output mechanism for `printf`, typically routing text to the kernel's serial output for debugging, or to an active text-mode console.
 -   **`SYS_GUI` (3)**: The primary multiplexer for all window manager operations. The arguments define subcommands (like `UI_CREATE_WINDOW`, `UI_FILL_RECT`).
@@ -33,4 +39,7 @@ int sys_write(int fd, const char *buf, int len) {
 -   **`SYS_EXIT` (60)**: Terminates the current process and returns control to the kernel.
 -   **`SYSTEM_CMD_YIELD` (43)**: Instructs the process scheduler to pause the current process and let another process run.
 
-If you are developing a new application, **do not invoke syscalls manually**. Instead, include `stdlib.h` and use the C functions provided.
+> [!IMPORTANT]
+> If you are developing a new application, **do not invoke syscalls manually**. Instead, include `stdlib.h` and use the C functions provided.
+
+---

docs/appdev/ui_api.md

@@ -1,12 +1,17 @@
-# UI API (`libui.h`)
+<div align="center">
+  <h1>UI API (<code>libui.h</code>)</h1>
+  <p><em>Interact with the BoredOS Window Manager (WM).</em></p>
+</div>
+
+---
 
 For an application to be visible on the screen, it must interact with the BoredOS Window Manager (WM). The tools required for this are located in `src/userland/libc/libui.h` and `libui.c`.
 
-## Core Concepts
+## 🧠 Core Concepts
 
 The UI library sends requests (via `SYS_GUI`) to the kernel to reserve an area on the screen (a `Window`) and then issues commands to color specific pixels within that area. The kernel is responsible for compositing this area over other windows.
 
-## Example: Creating a Window
+## 🪟 Example: Creating a Window
 
 First, include the library and define an event structure:
 
@@ -29,7 +34,7 @@ int main(void) {
 }
 ```
 
-## Drawing Primitives
+## 🎨 Drawing Primitives
 
 The library offers functions to mutate the window's internal buffer. After issuing drawing commands, you **must** instruct the kernel to push the changes onto the screen.
 
@@ -49,7 +54,7 @@ Available rendering methods:
 -   `ui_draw_string(id, string, x, y, color)`: Render text using the kernel's built-in font.
 -   `ui_update_region(id, x, y, w, h)`: A targeted version of `ui_swap_buffers` that only updates a specific area, saving performance.
 
-## Handling the Event Loop
+## 🔄 Handling the Event Loop
 
 Graphical applications are event-driven. They stay alive inside a `while (1)` loop, periodically asking the kernel if the user clicked the mouse or pressed a key inside their window.
 
@@ -83,3 +88,5 @@ Graphical applications are event-driven. They stay alive inside a `while (1)` lo
         syscall1(SYSTEM_CMD_YIELD, 0);
     }
 ```
+
+---