jgamboaandClaude
eafe426c8e
The reunion is complete: one build contains both UIs and picks between them at bootstrap. - src/shared/types.ts regains `skin: "modern" | "win7"` on AppSettings. - SettingsService regains the skin signal, setSkin() and applySkin(), which toggles the `.win7` class on <html>. - buildPreload emits __APP_SKIN and adds `.win7` conditionally again, instead of unconditionally as it had sincefe028a9. - chromeOptions() regains its parameter: win7 gets frameless + transparent, modern gets the macOS hiddenInset fusion or the plain native frame. - core/platform.ts regains APP_SKIN / IS_WIN7_CHROME (added in stage 4). - main.ts now selects on both axes — skin picks the tree, APP_MODE picks the root within it. - Both tab-bars get a skin row, with the reopen caveat as its tooltip. DEFAULT_SETTINGS.skin is "modern", matching the original design and `main`. Worth flagging: this branch has booted win7 unconditionally sincefe028a9, so after this commit it starts in the modern UI unless the setting says otherwise. One word in types.ts flips that if the win7 look should be the default. i18n: en.ts is the source of truth and everything else falls back to it, so only en was strictly required — but es/eu/fr/de/zh/ja got real translations too, each matching the terminology that locale already uses for the Theme row. Verified both skins on live single-instance captures. Modern boots and renders fully styled, which also proves Tailwind scans skins/shadlike/** — a purge would have produced an unstyled page rather than this one. Win7, selected by setting skin in the persisted settings, is still pixel-identical to the pre-refactor baseline across all five stages. The persisted settings file was backed up and restored, so it still carries no skin key and resolves to the default through the backend's merge. Not verified: clicking the new skin row itself, which needs an interaction pass — no window automation is available here. Its bindings compile and the built bundle contains options.skin, setSkin and the translated labels. Co-Authored-By: Claude <noreply@anthropic.com>
Ui
This project was generated using Angular CLI version 22.0.6.
Development server
To start a local development server, run:
ng serve
Once the server is running, open your browser and navigate to http://localhost:4200/. The application will automatically reload whenever you modify any of the source files.
Code scaffolding
Angular CLI includes powerful code scaffolding tools. To generate a new component, run:
ng generate component component-name
For a complete list of available schematics (such as components, directives, or pipes), run:
ng generate --help
Building
To build the project run:
ng build
This will compile your project and store the build artifacts in the dist/ directory. By default, the production build optimizes your application for performance and speed.
Running unit tests
To execute unit tests with the Vitest test runner, use the following command:
ng test
Running end-to-end tests
For end-to-end (e2e) testing, run:
ng e2e
Angular CLI does not come with an end-to-end testing framework by default. You can choose one that suits your needs.
Additional Resources
For more information on using the Angular CLI, including detailed command references, visit the Angular CLI Overview and Command Reference page.