v0.1.7 — window-controls LTR fix, hardened safe-close, broader RTL docs - #1
v0.1.7 — window-controls LTR fix, hardened safe-close, broader RTL docs#17odaifa-ab wants to merge 6 commits into
Conversation
Add the Chromium switch --force-ui-direction=ltr to the Windows launch paths (direct launch and packaged-app activation). On an Arabic/RTL Windows locale Chromium otherwise mirrors the native window chrome (WS_EX_LAYOUTRTL), flipping the minimize/maximize/close controls onto the app's own buttons and misplacing the menu bar. The switch corrects this at process start without modifying the app; RTL text direction is still handled in the renderer. Also replace the fixed 1s wait after Stop-Process with a ~10s poll loop, so a slow/busy exit (or antivirus scanning the process) no longer fails the launcher spuriously, and the fresh debug/UI-direction instance is not swallowed by a lingering single-instance lock. Matches the poll the macOS launcher already does.
Pass --force-ui-direction=ltr when launching the app on macOS, matching the Windows launchers, so the native window chrome stays LTR on RTL OS locales.
Clarify that the toolkit detects any right-to-left script, not just Arabic: direction is decided per Unicode code point, so Arabic and Arabic-script languages (Persian, Urdu, Kurdish, Pashto, Sindhi, Uyghur) and other RTL scripts are all supported. The detection core already covers these ranges; only the docs lagged. Also document the native window-chrome LTR fix (--force-ui-direction=ltr) and the hardened wait-for-exit in the launcher list.
Bundles the native window-controls LTR fix (--force-ui-direction=ltr on the Windows and macOS launchers), the hardened wait-for-exit safe-close, and the documentation updates clarifying broad RTL script support (Arabic, Persian, Urdu, and other right-to-left scripts).
|
@pawnsmaster waiting for review.. |
|
Thanks for the contribution. I don’t currently have access to a Mac, so I can’t test the macOS launcher myself.
This keeps the installation reproducible and avoids running dependency lifecycle scripts. |
- Replace `npm install --omit=dev` with `npm ci --omit=dev --ignore-scripts` in the macOS launcher, so the install is reproducible from the lockfile and no dependency lifecycle scripts run (matches the Windows launcher). - Harden the macOS pre-launch close so background/windowless and Electron helper processes are handled: detect the app by its main process OR any helper running from the bundle, ask it to quit gracefully, then, if anything ignores the request, force the whole bundle down (pkill on the .app path) and re-poll before giving up.
|
Thanks! Done both:
On the Mac verification — I want to be upfront: I don't currently have access to a Mac either, so I haven't run it on real hardware. The launcher uses only standard macOS mechanisms ( If you're OK with it, I'd suggest merging the Windows-verified changes and treating the macOS launcher as best-effort until one of us can test on a Mac — or I can split the macOS launcher into a separate PR so this one stays fully verified. Your call. |
|
Tested on real Apple Silicon hardware running macOS 26.2 with Node v20.19.4 and Everything passed:
I also tested the launcher end to end. It detected the running ChatGPT app, closed it cleanly, relaunched it using I verified the result through CDP as well: Finally, I checked the DevTools port with |
|
@pawnsmaster I brought a reviewer :) |
3 participants
v0.1.7
--force-ui-direction=ltr(Windows direct + packaged activation, and macOS), so on an RTL OS locale the native minimize/maximize/close controls and menu bar stay in place instead of being mirrored over the app's own buttons. No app modification — it's a startup flag, confirmed working on Arabic Windows.Verified:
npm run checkis green (unit tests + PowerShell/launcher/extension-sync checks).