@linkshell/mac 0.1.13 → 0.1.15

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -1,25 +1,50 @@
1
1
  # @linkshell/mac
2
2
 
3
- LinkShell.app is the native macOS status app and screen helper. Its dark dashboard and menu-bar
4
- popover use the same logo and neutral/mint palette as the website. Open it with `linkshell app`
3
+ LinkShell.app combines a desktop workspace, native Mac service management and the screen helper.
4
+ Two adjacent **工作台 / 本机管理** buttons sit below the larger, unframed brand row at the top of the sidebar;
5
+ ⌘1 / ⌘2 also switch between the workspace and native Mac management. The title bar follows the
6
+ window's appearance without a separate color strip. Open it with `linkshell app`
5
7
  or double-click the app. The host still opens separate `--connect` workers for screen capture;
6
8
  `--setup` retains the existing permission flow. Closing the dashboard leaves the host running.
7
9
 
8
10
  ## Desktop status app
9
11
 
10
- The dashboard provides overview, session summaries/details, paired devices, a bounded host-log
12
+ Native Mac management provides overview, paired devices, a bounded host-log
11
13
  viewer, account sign-in/sign-out, permissions, service start/stop/restart, and version checks.
12
14
  Standalone builds update the whole app through Sparkle; CLI-managed builds use the package manager. Stops, restarts and updates explain interruption before proceeding.
13
- Session approvals remain in the phone or original agent terminal in this first desktop version.
15
+ The workspace supports conversations, approvals, projects, terminals, files and remote desktops.
16
+ It reuses the current client protocol with desktop-specific typography, navigation and surfaces.
17
+ Conversations live in the workspace; native management has no separate session page. The workspace
18
+ sidebar keeps the computer selector's card hierarchy, names and status without a decorative
19
+ computer icon. Both areas use the native management palette, including its original near-black
20
+ dark background.
21
+
22
+ Desktop port previews support multiple tabs. Switching tabs keeps their existing previews;
23
+ refresh and close apply to individual tabs. “铺满窗口” expands a preview inside the current App
24
+ window and offers an explicit exit control. It also hides the native navigation overlay while
25
+ preserving the preview's isolated origin.
14
26
 
15
27
  `linkshell app` locates/unpacks the bundled app at the existing stable path and passes the exact
16
28
  CLI and Node executable plus `LINKSHELL_HOME`. Standalone Finder launches use the bundled Node
17
29
  and CLI; only CLI-managed helper builds fall back to the login shell's `linkshell`. A matching CLI is required: the UI reads `linkshell desktop` JSON snapshots every
18
- five seconds, with no TCP listener and no alternate database. Stopped, unreachable and unknown
19
- states are distinct; failed snapshots discard old session/device data. The list includes the latest
20
- 200 sessions and indicates truncation. Activity is observed during this UI session, not a persisted
30
+ five seconds. Stopped, unreachable and unknown
31
+ states are distinct; failed snapshots discard old live-status data. Activity is observed during this UI session, not a persisted
21
32
  audit log. Each data directory has one dashboard instance; screen and setup workers remain separate.
22
33
 
34
+ The bundled workspace is served by an App-owned `desktop-workspace` CLI process on a random
35
+ loopback port. Its API validates a launch capability, Host and Origin; the local Host proxy rejects
36
+ native-agent `desktop.*` methods. Remote computers retain the existing encrypted gateway tunnel.
37
+ Initial local Host discovery uses a short, bounded backoff while the Host opens its socket.
38
+ `desktop-client.json` under `LINKSHELL_HOME` stores the separate client identity and preferences
39
+ with mode `0600`, so origin changes do not lose pairings or drafts. Login uses the existing CLI
40
+ account through the system browser; refresh tokens stay outside the page. Closing or hiding the
41
+ workspace releases screen viewing. Before ordinary quit or workspace reconnect, the native app
42
+ asks the page to flush queued storage writes and waits for its acknowledgement. Failed writes
43
+ are retried; if saving fails or times out, the user can return to the workspace or explicitly
44
+ continue. Exiting cancels pending account and login requests and stops the workspace child, not
45
+ the Host.
46
+ See [the implementation plan](../../docs/design/mac-desktop/workspace.md) for boundaries.
47
+
23
48
  Two distributions share the same UI, bundle ID and Developer ID. The standalone DMG includes Node,
24
49
  CLI and Host, supports stable/beta update channels, and uses Sparkle to replace the bundle and
25
50
  recover its owned Host. The npm/Homebrew helper retains the external package-manager update route.
@@ -49,8 +74,22 @@ The adapter now admits at most two raw frames to VideoToolbox at once. If both a
49
74
  it skips new raw input and retains any key-frame request for the next accepted frame. It never
50
75
  discards already-compressed reference frames to enforce this bound.
51
76
 
52
- The media peer is an iOS native receiver or a web player, independently of the Node host's
53
- werift bulk-data connection. iOS normally decodes H.264 through VideoToolbox into a latest-frame
77
+ The media peer is a Mac native receiver, an iOS native receiver or a web player, independently
78
+ of the Node host's werift bulk-data connection. The desktop workspace uses native WebRTC with a
79
+ VideoToolbox decoder that requires hardware acceleration and verifies the session's actual
80
+ `UsingHardwareAcceleratedVideoDecoder` property. IOSurface-backed pixel buffers are mapped through
81
+ `CVMetalTextureCache` and rendered with Metal. AppKit handles mouse, keyboard and IME input through
82
+ the screen DataChannels. Web content owns navigation, toolbars and the existing encrypted
83
+ signaling path; decoded frames never enter WebKit or JavaScript. H.264 is the desktop default.
84
+ The decoder also supports HEVC, but this does not establish HEVC negotiation in the desktop UI.
85
+ There is no software decoder, browser-media or byte-stream fallback for the Mac receiver:
86
+ unsupported hardware or a failed connection produces an explicit error and retry action.
87
+ Leaving the screen, switching to native management or hiding the window destroys the screen
88
+ connection and releases input; returning reconnects. This first desktop implementation does not
89
+ use the ordinary Web/iOS 120-second pause-and-reuse lifecycle. Native hardware and loopback
90
+ validation are still in progress.
91
+
92
+ iOS normally decodes H.264 through VideoToolbox into a latest-frame
54
93
  mailbox, then maps the pixel buffer to Metal. Its transparent WebView still owns gestures,
55
94
  controls and the cursor. It requests a ceiling of 120 fps, bounded by both displays, power,
56
95
  thermal state and adaptation; standard receivers retain the 60/30 defaults. No video frames
@@ -62,10 +101,11 @@ HEVC is offered to capable native receivers only after the Mac's low-latency har
62
101
  passes an availability probe; other viewers keep H.264. Codec/extension support still depends
63
102
  on the actual negotiation.
64
103
 
65
- Failed media falls back to the host's H.264 byte stream. iOS first tries the standard WebView
66
- receiver and then bypasses the bulk direct channel for that screen, using RPC. Android/Web
67
- retain their existing stream path. Both Mac capture paths use ScreenCaptureKit/VideoToolbox;
68
- only the byte stream includes the cursor in the picture. There is no TURN service.
104
+ For iOS, Android and ordinary Web viewers, failed media can fall back to the host's H.264 byte
105
+ stream. iOS first tries the standard WebView receiver and then bypasses the bulk direct channel
106
+ for that screen, using RPC. Android/Web retain their existing stream path. Both Mac capture
107
+ paths use ScreenCaptureKit/VideoToolbox; only the byte stream includes the cursor in the
108
+ picture. There is no TURN service.
69
109
 
70
110
  See the [current architecture and diagrams](../../docs/v2/screen-realtime.md),
71
111
  [iOS receiver](../client/modules/link-screen/README.md) and
Binary file
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@linkshell/mac",
3
- "version": "0.1.13",
3
+ "version": "0.1.15",
4
4
  "description": "LinkShell.app: the Mac side of the screen — capture, encoding, WebRTC and input, under the app's own permissions.",
5
5
  "license": "MIT",
6
6
  "repository": {