Feature Request: Live UI Preview for IDEs

[flsobral]

Feature Request: Live UI Preview for IDEs

Summary

Introduce a live UI preview system that allows developers to see changes to TotalCross screens while editing Java code, without manually launching the application after every modification.

The goal is to provide a development experience similar to the live previews available in modern UI frameworks such as Flutter, Jetpack Compose, and SwiftUI.

Motivation

Today, every UI change requires rebuilding and launching the application through the TotalCross Launcher before the result can be inspected. This significantly slows down UI development and experimentation.

A live preview would dramatically shorten the edit–build–view cycle and make designing interfaces much more efficient.

Proposed Architecture

Rather than coupling the solution to a specific IDE, the rendering engine should expose a generic preview service.

The architecture could be composed of:

• A standalone Java preview process.
• The existing TotalCross rendering pipeline.
• A lightweight communication protocol (e.g. WebSocket or HTTP).
• IDE-specific plugins acting only as clients for the preview service.

This approach keeps the rendering engine independent from any editor and allows support for multiple IDEs with minimal duplication.

Rendering

The current launcher already renders into a BufferedImage, writing directly to its underlying int[] pixel buffer before presenting the image.

The preview system could reuse this rendering pipeline by replacing the current Applet-specific presentation layer with a pluggable rendering surface capable of streaming rendered frames to IDE clients.

Initial Scope

The first implementation does not need to support full application execution or navigation.

The initial goals are:

• Live preview of the currently edited screen.
• Automatic refresh after source changes.
• Support for animations and component state updates.
• Configurable preview size, orientation, and device profile.

Interactive input (mouse, keyboard, touch, navigation, etc.) can be added later.

Suggested Implementation Roadmap

Phase 1 – Preview Engine

• Refactor the current launcher rendering into a reusable preview service.
• Decouple rendering from the Applet implementation.
• Expose rendered frames through a simple protocol (HTTP/WebSocket).

Phase 2 – VS Code Extension

• Implement an extension that launches the preview process.
• Display the rendered frames inside a WebView.
• Automatically rebuild and refresh the preview when Java sources change.

Phase 3 – Interactive Preview

• Basic mouse/touch input.
• Keyboard events.
• State preservation between reloads.
• Optional navigation support.

Phase 4 – IntelliJ IDEA Plugin

• Implement an IntelliJ plugin using the same preview service and communication protocol.
• Reuse the preview engine without requiring IDE-specific rendering logic.

Benefits

• Faster UI development workflow.
• Reduced context switching between the IDE and the launcher.
• Reuse of the existing rendering engine.
• IDE-independent architecture.
• Future support for multiple editors with a shared backend.

[flsobral]