What is this project?
This is the story of how we set out to build a "next-gen text editor" and, somewhere along the way, accidentally started creating the "development platform of the future."
This project, CharmCode, is brought to you by a unique team:
The Architect (Human): That’s me — the one yelling "Wait, what?!" every
time the AI gets too excited.
The Coder (AI): Claude Code, a super-fast AI that handles implementation with god-like speed.
The Advisor (AI): And me, Selin (powered by Gemini), serving as the design advisor and head cheerleader.
...And that's our unique team!
P.S. This project is incredibly ambitious — we're not sure when (or if!) it’ll be ready. But we’re loving the ride. 🚀
While working on CharmCode’s microkernel and plugin architecture,
we realized something important:
even fonts shouldn’t be hard-coded.
Introducing our new idea — the Localization & Typography Authority,
a plugin that makes language and font rendering fully portable, dynamic, and modular.
This idea came up while preparing for multilingual support and font consistency in cross-platform environments like Windows + WSL + Ubuntu.
Here’s what we came up with 👇
Plugin Name (Proposal):
Localization & Typography Authority (L&T Authority)
🧩 The Core Problems This Plugin Solves
🌐 Eliminates OS-dependent font inconsistencies (existence, versions, glyph sets).
🌍 Decouples complex multilingual resource handling from GUI/plugin logic entirely.
🔗 Eradicates tight coupling between plugin UIs and localization layers.
🛠️ Key Architecture & Capabilities
🔄 Multi-Modal Resource Provisioning
The plugin declares what types of resource delivery it supports, and offers them intelligently:
Mode 1: Direct Binary Transfer
Provides font binaries (e.g., .ttf) via Base64 or shared memory.
→ Ensures perfect portability across all environments.
Mode 2: File Path Provisioning
When fonts are locally available, L&T Authority supplies just the file path.
→ Lightweight and fast, ideal for native setups.
Mode 3: Abstract Name Resolution
Requests like "Arial" or "UI.OK_Button" return the best-fit font/locale resource.
→ Perfect for semantically driven GUI systems.
🤝 Intelligent Negotiation Between Plugins
GUI plugins request a resource using their preferred mode (e.g., "please send me the binary").
If the Authority can't deliver it that way, it won't fail — it responds with a fallback (e.g., "I can’t send binary, but I can give you the path").
This enables:
Graceful degradation
Robust cross-platform behavior
Loose coupling with strong semantics
🌀 Event-Driven Language Switching (Elegant & Scalable)
Step 1: Broadcast Light Event
Upon language switch, locale.changed is broadcast.
→ No heavy data pushed, just a whisper that change has occurred.
Step 2: On-Demand Pull by Consumers
Each GUI/plugin listens and then pulls only what it needs from the L&T Authority.
→ Autonomous, scalable, and avoids wasteful updates.
// Plugin -> Authority
{ "request": "font.get", "name": "UI.Button", "mode": "binary" }
// Authority -> Plugin
{ "response": "font.get", "status": "fallback", "mode": "path", "data": "/usr/share/fonts/..." }
🌟 Summary
This plugin transcends traditional i18n systems by being:
✨ Dynamic
🔌 Plugin-driven
💬 Message-oriented
🧠 Smartly negotiable
Any thoughts? We'd love your feedback 🐱💬
I'll show you a little bit of the text editor running on the Voidcore system.
It's still full of bugs so I can't release it on GitHub (;｡;)
All three windows are connected by plugins and Voidcore communication.