docs: remove unused Kotlin debugging, Unity and workspace notes

This commit is contained in:
l0ng-ai committed 2026-11-06 09:25:14 +08:00
1 parent a6474539b8
commit 6b0dc93938
3 files changed
-133

No files matched your search

-63
View File
@@ -1,63 +0,0 @@
# Kotlin debugging
Kotlin Application configurations use the official `fwcd/kotlin-debug-adapter`
release, installed through Settings > Language Servers or the missing-debugger
prompt. A module containing `.kt` files under `src` uses this adapter for both
Application launch and Maven/Gradle JDWP attach, including mixed Java/Kotlin
modules. Pure Java modules keep `java-debug`.
The adapter runs on the language-server JDK (11+). The application runs on its
resolved project JDK, with the classpath, VM arguments, program arguments and
environment from its run configuration.
## Source paths
The adapter infers JVM class names from source paths. OpenIDEA creates a temporary,
package-aligned source mirror outside the project and supplies it as the adapter's
`projectRoot`. For example, `src/main/kotlin/Main.kt` declaring `package org.example`
gets an external `src/main/kotlin/org/example/Main.kt` alias. Breakpoints go through
that alias; stack frames and event paths map back to the original editor file.
Source sets have separate mirror roots. Where file symlinks are unavailable,
OpenIDEA copies sources and refreshes the copies on editor saves.
Restart debugging after changing a package or source root. The upstream adapter's
path-based resolver does not support renamed Kotlin facades (`@file:JvmName`), or
packages containing a literal `java` or `kotlin` component. Selecting the correct
main class does not remove those breakpoint limitations.
The Kotlin Application launcher currently passes the classpath directly, without
Java's large-command-line shortening, and decodes application output as UTF-8.
Very large classpaths and non-UTF-8 application output remain limitations; Windows
runtime behavior has not been verified.
## Startup ordering
OpenIDEA starts Kotlin applications with JDWP `suspend=y` and attaches the adapter.
It waits for each `setBreakpoints` response before sending `configurationDone`.
Adapter 0.4.4 never completes the `configurationDone` response, so OpenIDEA sends
that request without awaiting its response.
The official adapter can resume the VMStart event before installing its breakpoint
hooks and DAP listeners. A session-owned loopback JDWP relay holds VM and thread
resume commands until the successful DAP attach response, which follows listener
installation. Other JDWP requests and replies continue during setup. Attach failure
or session shutdown closes the relay and kills any JVM launched by OpenIDEA. No
adapter patch or timed startup sleep is used. An already-running external JVM must
be started with `suspend=y` to preserve its earliest breakpoints.
## Verification
`cargo test -p ide-dap --lib` covers relay ordering, fragmented packets, cleanup,
source mapping, and the adapter's missing configuration response. The ignored
`kotlin_official_release_ten_no_delay_runs` test exercises the real DAP client ten
times with an official adapter and a compiled reporter fixture. Set
`KOTLIN_PROBE_CONFIG` to a LaunchConfig JSON file and `KOTLIN_PROBE_ADAPTER` to the
release executable, then run:
```sh
cargo test -p ide-dap kotlin_official_release_ten_no_delay_runs -- --ignored --nocapture
```
The fixture is `src/main/kotlin/Main.kt`, with `package org.example`, a `for (i in
0..3)` loop at line 5 and `println(i)` at line 6, without any startup delay. Each run
must hit line 6, expose `i = 0`, step to line 5, and stop its session.
-23
View File
@@ -1,23 +0,0 @@
# Unity projects
Open the folder containing `Assets` and `ProjectSettings/ProjectVersion.txt`.
OpenIDEA detects Unity without requiring a generated solution and shows the editor
version in the Unity project view.
The Unity view hides `.meta` files, generated C# project files and cache/build
folders. **Show Meta Files** and **Show Generated Files** reveal them independently;
the regular Project view is still available. Generated folders are excluded from
indexing and search, including folders Unity creates after the project is opened.
Operations on assets inside `Assets` include their `.meta` files. Rename and move
preserve GUIDs, deletion removes both files, and copy generates new GUIDs and updates
references within the copied group. References to assets outside the group stay
unchanged. File move undo and transactional workspace edits include metadata too.
Destination metadata conflicts are rejected before making changes.
Projects may be opened through a linked root or parent directory, including macOS
`/var` and `/tmp`. Links inside the project (including Windows junctions) are not
followed by asset operations. For moves/copies to or from ordinary directories,
the external path must have no linked ancestors. Cross-volume asset moves and
copies that require rewriting binary serialized assets are rejected; use Unity
for those operations.
-47
View File
@@ -1,47 +0,0 @@
# Workspaces and project window groups
A workspace opens several local project folders in one IDE session. A window group switches between independent IDE sessions; a member can itself contain a workspace.
## Workspace
Use **File → New Workspace…**. Choose a name and a separate directory for the workspace, then add project folders. **File → Open Workspace…** opens that directory again. **File → Manage Workspace…** changes its name or linked projects. Removing a link leaves the project's files and open editor buffers intact.
When opening another local project, choose **Attach** to add it to this window. A plain project becomes a workspace automatically under the IDE app data directory's `workspaces` folder, named after the current project (with a unique directory suffix when needed). The existing editor session carries over after the unsaved-changes guard. **Don't ask again** remembers Attach; change it in **Settings → System Settings → Project → Open project in**. Already linked projects are revealed in Project view. Right-click a non-first linked root and choose **Remove from Workspace** to unlink it without deleting files.
The workspace stores its manifest in `.openidea/workspace.json`:
```json
{
"version": 1,
"name": "Full stack",
"projects": ["/work/frontend", "/work/backend"]
}
```
Paths in an existing manifest may be relative to the workspace directory. New and updated manifests use canonical absolute paths. Missing previously linked folders are retained so they can be reconnected or removed. Nested workspace manifests are rejected.
Linked folders appear as roots in Project view and participate in indexing, Find in Files, Git repository discovery and language-server root selection. Detected and saved run configurations have project-qualified names and use their member's working directory and launch settings. Build Project combines the linked projects' build plans; Compile File targets its owning project. Workspace editor/settings state belongs to its own directory. Each member retains its repository and project configuration.
The specialized Maven/Gradle tool-window model still describes the workspace directory itself; it does not yet aggregate independent member models. Workspace creation and management currently target local folders. To link independent Gradle builds in one Gradle tree, open their parent folder as an ordinary project instead of creating a Workspace manifest, then use **Link Gradle Projects…** in the Gradle toolbar or Find Action.
## Linked Gradle builds in a project
In an ordinary project window, **Link Gradle Projects…** accepts one or more `settings.gradle`, `settings.gradle.kts`, `build.gradle`, or `build.gradle.kts` files. Each linked build has its own root in the Gradle tool window. Its tasks, dependencies, wrapper, working directory and sync cache stay separate, even when another build has the same `:app` project or task names. Included builds remain under the build that includes them.
Right-click a build root for **Reload Gradle Project** or **Unlink Gradle Project**. Unlinking only removes the IDE connection; it does not delete files or saved run configurations. The Link button remains available after the last build is unlinked. Linked builds may live outside the opened folder.
Links are saved in project settings as `languages.java.gradle.linkedProjects`. Until links are configured, existing automatic discovery is unchanged. An explicit empty list means that no Gradle builds are linked. Opening the project again restores its links. A folder first opened by an older version may need one fresh sync because independent builds now have separate caches.
## Window group
Open two project windows, then use **Window → Merge All Project Windows**. The project tabs occupy their own row below the main toolbar. Click a tab or use **Next/Previous Project Tab** to switch; drag tabs to reorder them. The default shortcuts are ⌥⌘PageDown/PageUp on macOS and Ctrl+Alt+PageDown/PageUp on Windows/Linux.
Use the tab's close button to close that project, or **Move Tab to New Window** to detach the current tab. Right-click a tab for **Close Other Tabs**, **Close Tabs to the Left** and **Close Tabs to the Right**, which close the projects one at a time and keep the clicked tab; cancelling one project's unsaved-changes prompt leaves it and the rest open. The same commands are in the Command Palette and can be assigned shortcuts. Closing uses the existing unsaved-changes guard. Quit visits project windows in sequence so a hidden project's prompt is visible. Groups restore when **Reopen last project** is enabled.
The grouping model lives in `ide-workspace`, independently of project ownership. The desktop adapter keeps each member's WebView and backend services alive, presents the selected window at the group's position/size, and hides its peers. Hidden members are kept at the selected window's frame and display (and follow it after a move or resize), so switching projects only changes which window is visible. This is an application-drawn tab strip, not the macOS native tab strip. Its persistence is application-local in `window-groups.json`. Language servers, terminals, editor buffers and settings remain independent between group members.
## Validation
Automated coverage includes workspace manifest validation and persistence, missing members, independent language-server initialization roots, cross-root search/repositories/run directories, document preservation after unlinking, window-group membership/order, dialog failures and tab keyboard controls.
Tauri MCP validation on macOS covered workspace creation and management, opening same-named files from both projects, cross-project search, running both projects, tab selection/reordering/detachment, unsaved close cancellation, full-screen switching and application restart restoration. Windows/Linux native-window behavior has not been visually tested.