Drop the Monaco webview. Edit in a GtkSourceView on GTK and in a
native text view on Apple, both speaking to Frida.Compiler's
in-process language server for completions, signature help,
hovers and diagnostics.
Color, complete and indent code natively, matching the GitHub
theme in light and dark.
Bridge EditorCustomTheme/EditorTokenRule/EditorBaseTheme to their
Monaco counterparts and pass the theme name through.
CodeEditorView picks .gitHubLight or .gitHubDark from the
environment colorScheme and frames the editor with 1pt hairline
borders on top, leading, and bottom in editorGroupHeader.tabsBorder.
- Store source files as named CustomInstrumentFile rows per def
- Render sidebar with disclosure groups
- Drive editor via Monaco project models with activePath
- Validate Add/Rename/Delete dialogs and submit on Enter
- Fork installed hook packs into editable custom instruments
- Reload instances on def change; clear stale compat reasons live
- Focus editor on selection (native + Monaco)
EngineRegistry caches one Engine per working-project URL.
MainWindowView.init does a pure lookup, so SwiftUI's
view-tree re-evaluations cannot open extra ProjectStores
that race the live one's BEGIN IMMEDIATE and crash via
try!.
UI-state persistence (collapse flag, sidebar selection,
session detail section, etc.) lives on Engine for GTK to
adopt. SQLite has a 5s busy timeout. Engine open failures
surface as an error view.
TargetPicker is host @State injected via environment.
Global instrument-UI defaults register at app startup;
per-engine instrument and local-notifier hookups live in
Engine extensions.
Both frontends were configuring Monaco editors with parallel,
incompatible types: a hand-rolled MonacoEditorProfile in LumaGtk,
SwiftyMonaco's MonacoEditorProfile in the SwiftUI host. Each had
its own MonacoExtraLib, TypeScriptCompilerOptions, frida compiler
options constant, and tracer-handler ambient declarations. The
LumaCore.MonacoFSSnapshot type also collided with SwiftyMonaco's
same-named type, forcing a typealias workaround in the host.
LumaCore now owns the canonical editor model:
* EditorProfile, EditorCompilerOptions, EditorExtraLib, plus
EditorScriptTarget / EditorModuleKind / EditorModuleResolutionKind
enums whose raw values match Monaco's TypeScript enums.
* EditorProfile.fridaCompilerOptions and .fridaGumLib for the
Frida-recommended TS config and the bundled gum typings.
* EditorProfile.fridaTracerHook(packages:) and .fridaCodeShare()
factory methods that build the right profile in one call.
* TracerTypings.handlerLib for the defineHandler ambient
declarations (previously duplicated verbatim in both frontends).
MonacoFSSnapshot is renamed to EditorFSSnapshot, eliminating the
name collision with SwiftyMonaco entirely.
LumaGtk's MonacoEditor.swift drops its duplicate types and uses
LumaCore.EditorProfile directly. The JS literal generation moves
to fileprivate extensions on the canonical types.
The SwiftUI host gains one new file — Editor/SwiftyMonacoBridge.swift
— containing init(from:) extensions on SwiftyMonaco's MonacoExtraLib,
TypeScriptCompilerOptions, MonacoFSSnapshot, and MonacoEditorProfile.
This is the only place that knows about both type families. All
the per-frontend editor-profile files (TracerEditorProfile,
CodeShareEditorProfile, TypeScriptEnvironment), Workspace+Packages,
and the MonacoFSSnapshotAlias hack are deleted.
LumaCore now owns MonacoFSSnapshot, the package alias typings
helper, and the Engine.rebuildMonacoFSSnapshotIfNeeded routine
that walks node_modules for .d.ts and package.json. The SwiftUI
host's Workspace+Packages becomes a thin pass-through, and the
LumaGtk MonacoEditor gains setFSSnapshot plus initial-bootstrap
wiring so the tracer hook editor injects both gum typings and
project package alias typings, then ships the FS snapshot once
the engine has it ready.
Engine now has installPackage, upgradePackage,
removePackage, loadAllPackages, loadPackage —
delegating to CompilerWorkspace and propagating
to attached process nodes.
Workspace+Packages is reduced to the SwiftyMonaco
filesystem snapshot building, which stays in the
app layer.
Delete all 10 @Model classes (replaced by LumaCore structs).
Remove SwiftData imports from 27 files. Drop DocumentGroup,
schema versions, and migration plan from LumaApp.
ProcessNodeViewModel now persists REPL cells, ITrace
captures, and session updates through ProjectStore instead
of ModelContext. InstrumentRuntime uses the LumaCore
InstrumentInstance struct directly.
WIP: Workspace needs ProjectStore injection and views need
wiring to load data from the store. The Xcode build has
errors until the remaining view plumbing is done.
- Provide a trimmed node_modules filesystem snapshot to Monaco
- Inject global alias typings for installed packages
- Run tracer scripts through Frida.Compiler
Ole André Vadla Ravnås