White Paper

Ang dokumentong ito ay malalim na tumatalakay sa disenyo ng arkitektura, pagpili ng teknolohiya, at pangunahing lohika ng pagpapatupad ng mga mahahalagang tampok ng WSL Dashboard, na naglalayong magbigay ng teknikal na pananaw para sa mga developer at advanced na user.

1. Pangkalahatang-ideya ng Arkitektura

Gumagamit ang WSL Dashboard ng klasikong arkitektura na responsive UI-driven + asynchronous backend tasks, na ginagamit ang type system at ownership model ng Rust language upang matiyak ang memory safety at mataas na concurrency performance.

Mga Pangunahing Component

• Frontend (UI): Declarative interface batay sa Slint. Ang UI thread ay responsable sa rendering at user interaction.
• Backend (Runtime): Asynchronous runtime batay sa Tokio. Responsable sa pamamahagi at pagpapatupad ng system commands (CLI), file I/O, at network listening.
• Communication: Ang UI thread at asynchronous tasks ay nakikipag-ugnayan nang mahusay at thread-safe sa pamamagitan ng Channel (MPSC) at Shared State (Arc/Mutex/RwLock).

2. Mga Dahilan sa Pagpili ng Teknolohiya

Bakit Pumili ng Rust?

• Performance: Zero-cost abstractions, nai-compile sa native machine code, walang GC jitter.
• Memory safety: Inaalis ang buffer overflow at data race sa compile time, napakahalaga para sa mga tool na may kinalaman sa system-level operations (gaya ng disk migration, network configuration).
• Binary size: Static na pag-link ng lahat ng dependencies, gumagawa ng single-file portable executable program.

Bakit Pumili ng Slint + Skia?

• Declarative syntax: Ang paglalarawan ng interface ay hiwalay sa lohika, madaling mapanatili ang code.
• Skia rendering: Direktang ginagamit ang GPU acceleration (sa pamamagitan ng Skia engine), nagbibigay ng sub-pixel level na kalinawan ng teksto at makinis na animation effects.
• Mababang overhead: Kumpara sa Electron o WPF, napakaliit ng runtime overhead ng Slint.

3. Mga Mahahalagang Teknikal na Pagpapatupad

3.1 Pag-detect at Pag-parse ng WSL Instances

Nakukuha ng app ang status ng instance nang real-time sa pamamagitan ng pagtawag sa wsl.exe --list --verbose at pag-parse sa output nito (paghawak sa UTF-16 encoding).

• Bottom-level decoding: Sariling mahusay na encoding decoder, tinitiyak na maaaring tama ang pag-parse ng output sa iba't ibang locale na Windows environment.
• Status synchronization: Gumagamit ng dual synchronization mechanism ng periodic polling + operation trigger.

3.2 Disk Image Migration (VHDX Move)

Ginagamit ng migration function ang import-export mechanism ng WSL, ngunit may mataas na abstraction at atomic processing.

• Transactional guarantee: Bago magsimula ang migration, ilo-lock ng app ang target na distribution sa pamamagitan ng Mutex, pinipigilan ang data corruption dahil sa concurrent operations.
• Awtomatikong pagrehistro: Pagkatapos makumpleto ang migration, awtomatikong ire-redirect ng app ang VHDX path at ire-rehistro ang distribution, walang kailangang manual intervention ng user.

3.3 Port Forwarding at Firewall Automation

Ang network function ay hindi lamang simpleng netsh interface portproxy call.

• Rule lifecycle management: Awtomatikong dini-detect ng app ang mga umiiral na firewall rules. Kapag gumagawa ang user ng forwarding, gumagamit ang app ng Windows API o CLI upang sabay na gumawa ng inbound exception rules.
• Awtomatikong pagkuha ng IP: Sa pamamagitan ng pag-parse sa wsl hostname -I results, awtomatikong nami-map ang virtual network IP sa pagitan ng host at instance.

3.4 USBIP Integration

Ginagamit ang command line interface ng usbipd-win.

• Elevation handling: Ang bind operation ay nangangailangan ng administrator rights, ipinapatupad ng backend logic ang eleganteng UAC elevation request forwarding.
• Status state machine: Panloob na pinapanatili ang USB device connection state machine, tinitiyak ang traceability ng Attach/Detach process.

3.5 Resource Monitoring at Lightweight

Sinusubaybayan ng app ang sariling resource usage sa pamamagitan ng pagtawag sa native Windows APIs (gaya ng GetProcessMemoryInfo).

• Pinakamagaan: Sa tray silent mode, aktibong nilalabas ng app ang hindi kinakailangang UI resources. Para sa standard character sets tulad ng English, maaaring kasing-baba ng 10MB ang memory usage; para sa kumplikadong character sets tulad ng Chinese-Japanese-Korean, dahil kailangang mag-load ng malalaking font rendering cache, humigit-kumulang 38MB ang usage.

4. Mga Indikator ng Performance Optimization

Indikator	Target/Nasukat	Paraan ng Optimization
Bilis ng pagsisimula	< 500ms	Pre-compile ang Slint interface, bawasan ang runtime parsing.
Base memory (tray)	~10MB	Bawasan ang background polling frequency, ilabas ang rendering cache ayon sa pangangailangan.
CPU usage (idle)	< 0.1%	Gumamit ng Windows event-driven model, iwasan ang walang laman na polling loop.
Render frame rate	60 FPS	Skia GPU acceleration, sub-pixel level anti-aliasing rendering.

5. Backend Task Distribution Logic

Upang matiyak ang kinis ng UI, lahat ng mabibigat na operasyon (gaya ng pag-export ng VHDX) ay ipinamamahagi sa pamamagitan ng asynchronous tasks:

1. Request wrapping: Ini-wrap ng UI thread ang user operations bilang Command messages.
2. Message channel: Ipinadadala sa backend task handler sa pamamagitan ng tokio::sync::mpsc.
3. Status feedback: Pagkatapos makumpleto ng backend task, ina-update ang UI sa pamamagitan ng callback o shared state. Tinitiyak ng disenyong ito na kahit sa pagproseso ng GB-sized na backup tasks, ang interface ay nakaka-respond pa rin nang real-time sa user clicks.

6. Mga Pagsasaalang-alang sa Seguridad

• Atomic operations: Para sa mga kritikal na instance unregistration at migration, ipinapatupad ang pre-validation.
• UAC elevation management: Humihingi lamang ng permission kapag kinakailangan (gaya ng pag-bind ng USB device), sumusunod sa prinsipyo ng least privilege.
• Local storage: Ang configuration ay nakaimbak lamang sa lokal na ~\.wsldashboard, walang anumang cloud synchronization, pinoprotektahan ang privacy ng user.