Merges 71 commits from main. Headline content: the Tests/Manual
integration test suite revived and reorganized after long disuse
(renames, new applications, updated cibs), restoring a large
integration validation surface. Functional fixes include replacing
unload-based termination with pagehide (back/forward cache
compatibility) and hardening CPTextField's input-element handling.
Conflict resolutions (local versions retained):
- AppKit/CPTextField.j: main's input-element logic carried, with this
branch's preprocessor-removal sweep re-applied on top. Main's
conditionals are re-expressed as runtime CPDOMAvailable guards; the
_inputElement method-definition gate is retained.
- AppKit/Platform/CPPlatform.j: the DOM platform implementation stays
inlined under the PLATFORM(DOM) gate. The split layout breaks the
legacy build: the include fragment is compiled standalone by the
source walk and cannot resolve its superclass. Main's pagehide
termination fix is ported into the inlined section; the restored
AppKit/Platform/DOM/CPPlatform.j fragment is deleted.
Verified: legacy build green through Foundation, AppKit and Tools;
Tests/Manual suite passing.
- CPView.j: remaining 17 PLATFORM blocks resolved; purely mechanical
translation to runtime CPDOMAvailable guards, except the choice of
guard form (wrapped, compound, or early-return) per site
- No PLATFORM(DOM) conditionals remain in CPView.j; one #if DEBUG
block remains and is out of scope for this change
- work-in-progress towards complete removal of CPP directives
- Add CPDOMAvailable to CPCompatibility.j: canonical documented DOM capability test, bare global assignment
- CPView.j: 13 of 30 PLATFORM blocks resolved. Method bodies now
guarded at runtime (wrapped, compound, or early-return forms); DOM vars and ivars declared without resort to CPP conditionals
- work-in-progress towards complete removal of CPP directives
Cappuccino previously supported three platform contexts behind the
PLATFORM() preprocessor macro: Browser, CommonJS/Node, and a NativeHost
target. NativeHost is no longer supported; this removes it and
consolidates on Browser (for the app) and CommonJS/Node (still needed
by the toolchain itself, for theme compilation and testing).
PLATFORM(DOM) conditionals throughout AppKit governed both distinctions
at once - Browser vs NativeHost, and separately, DOM-dependent code vs
the CommonJS/Node build. Each conditional was reviewed individually:
NativeHost-only branches were removed, while branches needed for
CommonJS/Node were kept intact rather than collapsed to Browser-only.
Also included, found in the course of this work:
- Fixed two pre-existing duplicate instance-variable declarations
(_ephemeralSubviews in CPView, _scrollingTimer in CPTextView)
- Added a missing @import for CPTextContainer.j in CPTextView.j so
it resolves when compiled outside the full framework bundle
- Merged two Platform/DOM/*.j files into their parents to resolve a
build-tool basename collision, preserving the CommonJS fallback path
Calculations of the visible rect can be a heavy operation as it depends of the superviews
visible rect. They have to be transformed and intersected together to create the result.
This calculation is a recursive operation that travels up the view hierarchy all the way
to the top.
Updating the tracking areas is also a recursive operation. But it travels down the view hierarchy
instead. It will calculate the new tracking area using the visible rect for the current view. For
each view it updates it will get the visible rect that has to travel all the way up the view
hierarchy to calculate it by transform and intersect them together. This results in that the visible
rect will be calculated for each view multible times. This makes it a very slow operation, specially
for deeper view hierarchies.
This fix will send along the visible rect for the superview when traveling down the
view hierarchy. This means that the visible rect does not need to travel up the view hierarchy
to be calculated. It will just need transform and intersect the provided rect for its superview
with the one from itself.
This makes updating views much faster when they need layout. This will make resizing browser window and changing split views sizes much smoother.
The effectiveAppearance is inherited from the superview. The superviews appearance is passed along as it is recomputed down the view hierarchy.
Also the current appearance is saved on each view to make it possible to only change the theme states when the appearance is changed.
This speed improvement is very notable when resizing a browser window of altering the size of split views.
The fix uses a variable on the window to control when to update the tracking areas.
If the view is not connected to a window the tracking areas will not be updated as they will
be when added to a window.