Six GUI bugs I fixed in one day — how I made IONA OS actually usable From dead keyboard shortcuts to broken input to hardcoded data: a day of polish

Yesterday I spent a full day fixing six applications in IONA OS. None of them were completely broken. They all looked good, they all compiled, they all ran. But they were almost unusable.

This is the story of how I turned them into actual tools.

The problem — applications that looked good but didn't respond

IONA OS has a GUI compositor (glass), a desktop, and a suite of applications. They are written in Rust, using a custom GUI framework. They compile, they render, they look decent.

But:

• The keyboard shortcuts didn't work.


• Buttons were drawn but had no click regions.


• The shell had no keyboard input.


• Some applications showed hardcoded data next to real data.

This is the phase where a project goes from "looks like a product" to "is a product". Here's how I fixed it.

1. Monitor — q/r didn't work, and process names crashed the system

The Monitor app shows CPU, RAM, processes, and network stats. It had two problems:

1. Pressing q or r (quit/refresh) did nothing — the input handler was never connected.


2. Process names were truncated on raw bytes, not on character boundaries. If a process name contained multibyte UTF-8 (e.g., Chinese characters), the truncation could cut in the middle of a character and cause a crash.

Fix: I connected the input handler properly and replaced the byte‑based truncation with a UTF‑8 safe function that respects character boundaries.

// Before: crashed on multibyte chars

let name = &proc_name[..16];

// After: safe UTF-8 truncation

let name = safe_truncate(proc_name, 16);

Now Monitor is stable and responsive.

1. IONA Shell — the entire CLI was dead
   The shell is the heart of IONA OS — it controls dashboards, policies, recovery, services, operators, and the governor. It's a text‑based interface for everything.

But no keyboard input ever reached it.

The input loop was written, the rendering was working, but the event pipeline stopped before the shell. For weeks, I had been testing it with simulated input. Real users would have seen a frozen screen.

Fix: I traced the event chain from the kernel's keyboard driver through the GUI compositor to the shell. I found that key events were being delivered to the window but not forwarded to the CLI handler. I fixed the forwarding logic.

Now the shell is fully functional. Every screen (dashboard, policy, recovery, services, operator, governor) responds to real keyboard input.

1. Bluetooth — dead commands and silent failures
   Bluetooth had five commands: 1 (scan), 2 (pair), s (status), p (pair), c (connect), u (unpair). None of them worked. The key handler was written, but the format was dead — the event parser was looking for the wrong key codes.

Arrow navigation was also broken — it used old PS/2 key codes instead of modern USB HID codes. Only the mouse wheel worked.

Worse: when a command failed, it just returned (). No error message, no feedback.

Fix: I rewrote the key handler to use correct USB HID codes and added error display. Now every command shows a result or an error message.

// Before: silent failure

fn pair_device() { .. } // returned nothing

// After: error feedback

fn pair_device() -> Result { .. } // returns success or error

Now you can scan, pair, connect, disconnect, and unpair — and you know if it worked.

1. Sovereign Apps — AI chat dead, hardcoded data
   Sovereign Apps contains the AI Assistant and the Blockchain Monitor. The AI Assistant had a text input that was rendered but didn't accept keyboard input (same format‑dead bug). The Blockchain Monitor had a scroll region that didn't respond.

Separately, the MeshRadar panel showed Peers: 3 Online: 2 — hardcoded values. Next to it, the real mesh status was being updated, but users were seeing two different numbers.

Fix: I fixed the input handler for the AI chat and the scroll region. I also replaced the hardcoded values with real data from the mesh subsystem.

// Before: hardcoded

draw_text("Peers: 3 Online: 2");

// After: real data

draw_text(&format!("Peers: {} Online: {}", mesh_peers(), mesh_online()));

Now the AI Assistant works, the Blockchain Monitor scrolls, and the MeshRadar shows truth.

1. Benchmark — R or Enter didn't start the test
   The Benchmark app showed a prompt: Press R or Enter to start. But pressing R or Enter did nothing. Same bug — the format was dead.

Fix: I connected the prompt to the actual event handler. Now pressing R or Enter starts the benchmark.

1. Clock — Start/Reset buttons had no click region
   The Timer screen in the Clock app had Start and Reset buttons. They were drawn on the screen, but clicking them did nothing. Only keyboard shortcuts worked.

Fix: I added the missing click region. Now clicking the buttons works.

The pattern — and what I learned

All six bugs were variations of the same two problems:

Input events were not being forwarded — the rendering was correct, but the event pipeline stopped before reaching the application.

String handling was unsafe — byte‑based truncation can crash on multibyte UTF‑8.

I fixed the input forwarding in each application individually. Next, I plan to centralise this logic so it doesn't happen again.

What this means for IONA OS

IONA OS is now more than a kernel that boots. It's an operating system you can actually use.

The Monitor shows real data and responds to your keys.

The Shell is a fully functional CLI.

Bluetooth works.

The AI Assistant can be used.

The Benchmark is lansable.

The Clock Timer responds to clicks.

These fixes took one day. They made the difference between "it compiles" and "it works".

Why this matters

A system of operating that boots but has unusable applications is a demo. A system where every application responds to input and shows real data is a product.

IONA OS is now closer to a product than it's ever been.

Resources

Website: iona.zone

GitHub: github.com/Ionablokchain