David Richardson
dc6bebd7eb
CPScrollView previously lacked magnification support, preventing document zooming and leaving view scaling infrastructure without practical test coverage. Additionally, views resetting to a 1.0 scale retained stale CSS transform properties, and legacy cibs compiled via nib2cib omitted explicit magnification limits, breaking zoom functionality in older archives. * AppKit/CPScrollView.j: - Implement magnification methods and properties (`magnification`, `setMagnification:`, `setMagnification:centeredAtPoint:`, `allowsMagnification`, `minMagnification`, and `maxMagnification`) modelled on NSScrollView, with keyed archiving. - Scale clip view bounds and synchronize resizing document view widths. - Define standard Cocoa default limits (0.25 and 4.0) as named constants. - Implement robust decoding validation to assign default limits to unset or invalid archive values and reject non-positive magnification inputs, ensuring full compatibility with legacy cibs. * AppKit/CPView.j: - Remove stale CSS scale styling when a view's scale factor returns to 1.0. * Tests/AppKit/CPScrollViewTest.j: - Add comprehensive unit tests covering magnification scaling, archiving, and fallback decoding for unconfigured limits. * Tests/Manual/TextEditor/DocumentWindowController.j: - Implement zoom action handlers (`zoomToLevel:`, `zoomToActualSize:`, `zoomIn:`, and `zoomOut:`) driven by menu item tag values. * Tests/Manual/TextEditor/Resources/MainMenu.xib, MainMenu.cib: - Add View menu options for Actual Size, Zoom In, Zoom Out, and explicit Zoom Levels (25% to 200%). * Tests/Manual/TextEditor/WORKLIST.md: - Mark zoom functionality as tested; log discovered scaling edge cases as open items. CPScrollView and TextEditor now support robust document magnification from 25% to 200%, validating core view scaling mechanics.
Manual Integration Tests
This directory contains the manual integration test suite for Cappuccino. Each subdirectory represents a distinct test application.
Integration Test Definition
Unlike automated, isolated unit tests located in Tests/AppKit, Tests/Foundation, and Tests/Objective-J, the tests in this directory validate the framework as a complete, running application. A test consists of a minimal Cappuccino application (AppController.j, main.j, Info.plist, index.html) executing in a real browser, exercising the compiled runtime, rendering pipeline, and target classes together. These tests require manual verification. There are no automated assertions; a human reviewer must open the application, interact with it, and visually verify its behavior. This suite is designed for human review of specific features, not yet unattended CI.
Execution
Open /index.html (release) or /index-debug.html (debug, unminified) directly in a web browser.
No intermediate build step is required to load the framework and application sources, provided the /Frameworks directory exists.
To provision the Frameworks directory for every application in the suite, execute jake configure within Tests/Manual once initially, and after any framework modifications. The available tasks are:
configure:(Default): Depends on refresh-dist. Builds a shared, merged .Frameworks cache once, then provisions every test application with a single symlink pointing to it.refresh-dist: Rebuilds the dist packages at the repository root (../../dist).clean: Removes the Frameworks symlink from each application directory without affecting actual directories. Skips any unmanaged, non-symlink directories.clobber: Executes clean, then removes the shared .Frameworks cache.
Many applications contain legacy Jakefiles predating the current Node-hosted toolchain. These use incompatible idioms, will not execute correctly via per-application jake build or jake run commands, and are not required to open the tests directly in a browser. Migration of these Jakefiles is pending.
Framework Provisioning
The HTML entry points load Frameworks/Objective-J/Objective-J.js (or the debug equivalent) via a literal relative path. Without this directory present, the application will not load.
Shared Cache Architecture
Cappuccino's framework build is distributed across two packages (dist/cappuccino, dist/objective-j) and two target levels (release, debug). Every application requires the same merged subset of eight items. Utilizing a shared cache (.Frameworks) with per-application symlinks provides three structural advantages over copying or linking individual framework components directly into dist:
- Centralized Configuration: Modifying the required framework set requires only a single edit, which immediately updates all applications. Direct linking requires restating the set for every application.
- Atomic Cleanup: The clean operation targets a single symlink per application. Managing a per-application directory requires sweeping the directory and distinguishing managed components from unmanaged files.
- Scalability: The operational cost scales with the application count, rather than the product of application count and member count. Direct linking repeats eight operations per application on every configure execution, whereas the shared cache performs the operations once globally. This ensures configure remains fast enough to run reflexively during iterative development.
Portability
The Frameworks symlink is ephemeral, ignored by git, and valid exclusively within the Tests/Manual tree.
To relocate a test, regenerate the Frameworks directory at the destination using capp gen --frameworks appName (or --frameworks --symlink appName), utilizing the binary located at dist/cappuccino/bin/capp.