Native desktop windows - #5556
Open
shai-almog wants to merge 114 commits into
Open
Conversation
Introduces com.codename1.ui.TopLevelContainer, the interface implemented by anything that can sit at the root of a component hierarchy. Today that is only Form; a later commit adds Window, the desktop native-window top level. Every member is chosen from a count of the direct getComponentForm().<method>() chains in CodenameOne/src, so the interface is the measured contract core actually depends on rather than a guess. It is dominated by animation registration, focus, and the layered panes. Every method already existed on Form with an identical public signature, so this commit adds no behaviour and needs no Form change beyond the implements clause and the new asContainer() bridge -- a Java interface cannot extend a class, so without it a TopLevelContainer reference could not be passed anywhere a Component is expected. Deliberately excluded: MenuBar and the soft buttons (MenuBar is coupled to Form's tint, back command and actionCommandImpl), dispose()/isDisposed() (package private on Form, and it means "pop back to previousForm" rather than "destroy this window"), and the mobile navigation surface -- transitions, back command, previousForm, tint and orientation listeners. Members already on Component or Container are reachable through asContainer(). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Adds Component.getTopLevelContainer(), the resolution path that replaces getComponentForm() in code which has to keep working inside a desktop Window. getComponentForm() is untouched and keeps its meaning: it returns the enclosing Form, and null for a component hosted in a Window, because a Window is not a Form. The internals that Component, Container and Toolbar need in order to drive a top level -- the internal animation registry, focus, the revalidate queue, the drag and press state -- are declared package private on Container rather than on an interface. Every method of a Java interface is implicitly public, so an interface would have silently widened Form's public API; Container is the nearest common supertype of Form and Window, so the calls still dispatch virtually with no instanceof. The defaults are inert and Form overrides the ones that mean something to it. Also adds com.codename1.impl.WindowManager, the single facade carrying the whole native windowing contract, reached through one new CodenameOneImplementation.getWindowManager() that returns null by default. This follows getHealth()/getBluetooth()/getCarBridge(), and keeps several dozen methods out of an already very large class. The null return is itself the capability query, so no separate supported flag can drift out of step with it. Only operations every windowing system provides are abstract; the rest have inert defaults so a later addition cannot break an existing port. No behaviour change: no port implements a window manager yet. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Migrates the load-bearing call sites in Component and Container off getComponentForm() and onto getTopLevelContainer(), so they keep working when the root of the hierarchy is a Window instead of a Form. The sites were picked by reading, not by pattern. Two groups: Sites that dereferenced the Form with no null check, and so would have thrown rather than degraded: growShrink and its BGPainter animate loop, the material pull to refresh release, the deinitialize path that unhooks the refresh drag listener, chooseScrollXOrY, moveScrollTowards, and the drop handler that animates the hierarchy. Several of these could already NPE today for a component detached mid animation, so they are now guarded as well as migrated. Sites that were guarded and would therefore have gone quiet -- the worse failure, because each one silently removes a whole feature: all pointer dragging, kinetic and smooth scrolling, drag and drop, focus, the animation manager behind every animateLayout, animated backgrounds, the revalidate-on-style-change gate, and revalidateInternal, which is the root of the layout system. Adds four more package private hooks to Container that these sites need -- getFocused, isRevalidateFromRoot and the directional focus finders -- following the pattern established for the rest: inert defaults on Container, overridden by the top level. Left alone deliberately: fireFocusGained and fireFocusLost reach for getMenuBar(), which a Window has no equivalent of, so the existing null guard already yields the right behaviour there. All 4790 core unit tests pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Groups the four fields that describe "the thing being painted" -- the dirty queue, its swap buffer, the fill count and the Graphics -- into a PaintSurface. The application's main surface becomes one instance of it, and a later commit gives every native window another. paintDirty() keeps its signature and behaviour and now delegates to a surface-parameterized routine, with paintDirtyWindow() entering the same routine for a window. Having one copy matters: that method carries the clip and paintable-bounds handling from issue #5273, and a per-surface copy would be free to drift. The flush-region hint is routed per surface. Its window form is inert by default rather than delegating to the main-surface version, so an immediate mode port that has not opted in cannot clamp a window's clip against the main window's state. repaint(), cancelRepaint() and hasPendingPaints() keep their signatures, so the JavaSE and Android overrides that call super still compile and behave. cancelRepaint now sweeps every surface, since its callers have no window context. No behaviour change: nothing creates a window surface yet. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Extracts the layer lookup and z-index insertion out of Form into TopLevelSupport, so Window can reuse it instead of carrying a second copy. The logic is moved verbatim, including the getChildrenAsList(true) reads: the comment there is load bearing, since iterating the container directly does not find components while an animation is in progress and the method would then add a duplicate layer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Window is the desktop counterpart of Form: a second native operating system window with its own component hierarchy, focus owner, animations, revalidate queue and dirty region. The main surface stays a Form and is untouched. Desktop is the public API parallel to Display. Display keeps answering "how big is the application's main surface", which is the only question a phone has; Desktop answers "what screens exist and what windows are open". It owns the window registry and hands out Monitor snapshots, and every one of its methods degrades safely where there is no windowing system -- an empty window array, a single monitor describing the main display -- so only constructing a Window throws. Monitor carries per-monitor geometry, work area, density and backing scale, and a Window reports the density and scale of the monitor it is currently on rather than the global one, which is what makes a mixed-DPI desktop render correctly. Event routing packs the window id into the high bits of the event type word. Window 0 is the main surface, and for it the packed word is numerically identical to what it always was, so the wire format, drag coalescing and the stack swap are all untouched. The id is an int chosen by the framework and echoed back by the port, so the off-EDT input path needs no map and no lock. Key repeat and long press now return to the top level the press came from. Fixes a latent infinite EDT spin this makes reachable: handleEvent returned without advancing the offset when it had no form to dispatch to, while the caller loops while (offset < end). It was unreachable only because the public entry points all guard on a non-null current form. skipEvent now drains the packet so the rest of the batch -- which may contain main form events -- still dispatches. Fixes two adjacent bugs the same code path forced into the open: a key or pointer release aimed at a different form than the press left its payload in the stack, where it was then read as the next event type; and the multi-touch release passed the x array as both coordinates. Modality blocks input in core rather than in the ports, so a modal window behaves identically everywhere whether or not the platform implements its own; ports still set the native flag for correct focus and taskbar behaviour. showModal parks the caller through invokeAndBlock exactly as a modal Dialog does, so every other window keeps painting. All 4790 core unit tests pass. Two of them reach into the paint queue by reflection and were updated for its move onto PaintSurface. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Removes the two assumptions in the JavaSE port that there is exactly one canvas, which is what stands between it and a second rendered window. getGraphics(Object) fell through to canvas.getGraphics2D() for any screen graphics, so a secondary window would have drawn into the primary window's buffer. NativeScreenGraphics now records the canvas it belongs to and resolves through that. isScreenGraphics(Graphics2D) was literally an identity comparison against the primary canvas's buffer. It is now a membership test over the registered screen buffers. This matters because drawNativePeerImpl uses it to decide whether to undo the zoom scale, so answering wrongly for a second window would mis-scale its peer components. The registry is maintained at the only three places C.g2dInstance is written -- created in getGraphics2D, discarded in createBufferedImage and in the size change reset -- so it cannot drift. Behaviour with a single window is unchanged: the primary canvas is still the owner of its own graphics, and the membership test still answers true for exactly the buffer the identity comparison used to. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The first real port implementation, and the one that decides whether the design holds. Each Codename One Window becomes a JFrame containing its own instance of the port's existing C canvas, so a second window inherits the whole buffered blit machine -- including the blitCounter aliasing fast path, which is already per-instance state -- with none of it duplicated. Input is tagged at the source: C carries the window id it renders and its listeners dispatch through the window-aware entry points, so an event reaches the right hierarchy without a lookup on the AWT thread. Window id zero routes to the main surface, so the primary canvas keeps its exact previous behaviour. Monitors come from GraphicsEnvironment, with the work area taken from the screen insets so a window centres or maximises without landing under the task bar or dock, and the backing scale from each GraphicsConfiguration's default transform rather than one global retina scale. A window that is dragged onto a display with a different scale raises a monitor-changed event, which is what lets the framework re-lay it out instead of leaving it blurry. Multi-window reports unsupported while a phone skin is loaded, reusing the predicate isFullScreenSupported already applies: a skin simulates one device screen with its own coordinates and zoom, and a real operating system window inside that simulation is incoherent. Headless likewise. Also qualifies java.awt.Window in SourceChangeWatcher, which wildcard-imports both java.awt and com.codename1.ui and so became ambiguous the moment com.codename1.ui.Window existed. A repo-wide scan found no other collisions. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Adds TestWindowManager, a window manager with no operating system behind it, and wires it into TestCodenameOneImplementation as an opt-in. It defaults to absent, so the unsupported platform every mobile port reports is also the default a test sees, and the throwing path is exercised without arranging anything. Its monitor table is scriptable, which is what makes per-monitor DPI testable at all: DesktopMonitorTest describes a 2x laptop panel with a dock reserved at the bottom next to a conventional external display, then asserts that a window picks up the scale and density of whichever one it sits on and that moving between them marks its preferred sizes stale. Getting that wrong is what produces a blurry or mis-sized window, and it would otherwise need a second physical display to catch. WindowTest covers the rest of the contract: constructing a Window on an unsupported platform throws rather than degrading, Desktop still answers safely there, show creates exactly one native window, dispose releases it and is idempotent, title and bounds reach the native window, close honours the close operation and can be vetoed, chrome and modality reach the peer, and each window gets its own id since events are routed by it. Two assertions are the load-bearing ones for the chosen design: a component in a Window resolves that Window through getTopLevelContainer(), and getComponentForm() returns null for it -- while a component in a Form still resolves both. 4808 core unit tests pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ates SpotBugs is a zero-findings gate and this change tripped ten. Fixing them properly rather than excluding them turned up a real gap. Five were unused fields on Window -- the press coordinates, the press token and the dragged component. They were unused because Window had no pointer dispatch at all: Container does no hit testing of its own, Form does that work itself, so without it a press inside a window never reached the component under it. Window now performs the same walk Form does, minus the title area and menu bar special cases it has no equivalent of, and implements the Container hooks that expose the press state -- which is what the migrated drag and scroll code in Component reads. One was a naked notify in dispose(). The flag showModal parks on is now published under the very monitor the waiter is blocked on, with a separate flag guarding re-entry, so the wake is tied to the state change rather than being incidental. Four were anonymous Runnables in Display retaining their enclosing instance. They are now one named static WindowCallback. SpotBugs, PMD and Checkstyle are clean over core-unittests; 4808 tests pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Both were parented to the primary canvas unconditionally, so a BrowserComponent or a text field inside a desktop Window would have appeared on the main window instead of the one containing it. Peer.addNativeCnt now resolves its frame through the owning window at attach time rather than at construction: a peer is created before it is added to a hierarchy, so its window is not knowable when the Peer object is built. editString attaches the Swing editor to the owning window's canvas, and stopTextEditing removes it from whichever canvas it actually landed on rather than assuming the primary one. Both resolve through Display.getWindowPeerForComponent, which walks the component's top level -- so a component on the main form still gets exactly the previous behaviour. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Adds desktop windows to the native Windows port. Each Codename One Window is a slot in a new native table with its own HWND, ID2D1HwndRenderTarget and CN1Graphics. The main window is deliberately left out of that table. It stays in cn1Win with its existing HWND, render target and graphics untouched, so the single-window path -- which every existing app and every screenshot baseline exercises -- cannot change behaviour. Secondary windows also get their own window procedure rather than sharing the main one, which is full of main-window-only cases. Window identity in that procedure comes from GWLP_USERDATA set in WM_NCCREATE: O(1) and lock free, which matters because it runs on the pump thread while the EDT is drawing. Events carry the framework's window id, which the native side stores at creation and echoes back, so routing needs no lookup. Creation and destruction marshal to the pump thread through a new WM_CN1_DESKTOPWINDOW, following the blocking SendMessageW pattern the native edit control and file dialog already use -- a window must be created on the thread that owns the message loop. Everything else is legal cross-thread and runs directly. The message loop itself needs no change: GetMessageW already pumps every window owned by the thread. Two things carried over deliberately from the main window because getting them wrong is subtle: D2D1_PRESENT_OPTIONS_RETAIN_CONTENTS, since Codename One repaints only the dirty region and relies on the rest surviving the present; and recording a resize for the drawing thread to apply between frames rather than resizing the render target from the pump thread, which presents black. WM_DPICHANGED honours the rectangle Windows suggests and reports the monitor change, which is what keeps a drag between mixed-DPI displays from leaving the window the wrong physical size. Monitors come from EnumDisplayMonitors with the work area from MONITORINFO, and per-monitor DPI from GetDpiForMonitor resolved dynamically since shcore.dll only exists from Windows 8.1. WM_DESTROY on a secondary window deliberately does not PostQuitMessage: closing a tool window must not exit the application. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Adds desktop windows to the native Linux port. Each Codename One Window is a slot in a new native table carrying its own GtkWindow, GtkOverlay, GtkDrawingArea, GtkFixed peer layer and cairo back buffer. The main window keeps its own file statics in cn1_linux_window.c and is not part of that table, so the existing single-window path is unchanged. Routing is essentially free here, which is the nice part of GTK: every signal handler already takes a gpointer closure, so passing the window struct as the closure data makes each handler window-scoped with no lookup and no shared state. gtk_main_iteration already services every window in the process, so the loop needs no change either. Events carry the framework's window id, stored at creation and echoed back. The delete-event handler returns TRUE so GTK does not destroy the window: Codename One decides, because an application may veto the close from a listener. The window's back buffer sets isWindowTarget, which turns on the #5273 clip clamp -- a clip set while a component paints is confined to the region about to be flushed, so an oversized fill cannot leave stale pixels on the persistent cairo surface. GTK is not thread safe, so every entry point marshals to the GTK main thread through cn1LinuxRunOnMainAndWait, which the port already uses for exactly this. Monitors come from GdkDisplay, with the work area from gdk_monitor_get_workarea. Scale reports GTK's integer scale factor, since that is what actually governs how the toolkit renders, while dots per inch is derived separately from the monitor's reported millimetre size -- the integer factor is far too coarse to describe a display's real resolution. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Adds desktop windows to the Mac Catalyst slice. A Codename One Window becomes a UIWindowScene, with the whole implementation inside #if TARGET_OS_MACCATALYST so the object file an iPhone or iPad build produces is empty and the plain iOS binary is unchanged. Unlike the other desktop ports, the window's content is rendered into a mutable image and the finished raster is assigned to the scene view's layer, rather than the window owning a second Metal surface. That is a deliberate trade: the render path caches its device, pipeline state and glyph atlas against the single rendering view, and making those per-scene is a large refactor of the hottest code in the product, without ARC. The scene still owns a real UIKit view hierarchy, so native peers and native text editing work normally inside a window -- only the drawing arrives as a bitmap. Multi-window is opt-in through a new macNative.multiWindow build hint. That is not caution for its own sake: the existing comment in IPhoneBuilder records that turning UIApplicationSupportsMultipleScenes on changed Catalyst windowing and crashed the screenshot suite with a 26 GB signal loop. The hint now gates both that Info.plist key and IOSImplementation.getWindowManager(), so the key and the API that requires it are switched by the same flag and cannot disagree. Scene arrival is asynchronous, so a created window claims the next scene the delegate receives; the delegate hands it over before installing the main root view controller, and only the application's own scene falls through to that. Teardown releases the scene, window, controller, view and title on the main queue after UIKit has finished with them, since this port has no ARC. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The part of the test story that actually demonstrates windowing. A picture of a window proves nothing; these re-run representative UI INSIDE a real operating system window and compare that window's own capture against its own baseline. WindowHostTest hosts content in a Window at three sizes -- 400x300, 900x700 and a deliberately non-square 1000x400 -- and captures through Window.capture() rather than Display.screenshot, because the ordinary path can only see the application's main framebuffer and a second window simply is not in it. The three sizes are the point: a window still measuring itself against the main display would produce three near-identical goldens. The cases were chosen for what fails silently rather than for coverage count. Layout proves sizing and theming resolve against the window. Scroll proves the scroll path, which goes quiet rather than throwing if a component cannot resolve its top level. Graphics exercises the port's pipeline on a non-primary render target with shapes that deliberately reach the edges, where a wrong clip clamp leaves stale pixels. Editing covers native text input, which used to attach the platform editor to the main window's canvas unconditionally. Overlay covers the layered pane that Sheet, InteractionDialog and ToastBar attach to. Modal captures the BACKGROUND window while a modal is up, which is the state that would be blank if the nested event loop had stopped servicing it. MultiWindowApiTest is the behavioural half: no screenshot, runs everywhere, and asserts against what the port reports rather than pixels. Where there is no windowing system it asserts the opposite -- that the capability query says so and that constructing a Window throws rather than degrading. The suite skips without emitting a golden where windows are unsupported, so mobile baselines never contain a picture of something the platform cannot do. The new tests are recorded as not-run in every stored port report, which is honest: CI has not executed them on those targets yet. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Adds a Desktop Windows chapter next to Desktop Integration, covering the whole feature: where windows exist and where they throw, the Form/Window relationship through TopLevelContainer, lifecycle and close vetoes, chrome and the two coordinate systems, modality, monitors and per-monitor DPI, events, peers and native editing, and the Mac Catalyst opt-in. Two things are called out rather than buried, because they are what will actually catch someone out. getComponentForm() returns null inside a Window, and the failure mode is silence rather than an exception, since most code guards on null and quietly does nothing -- so a component that will not scroll or focus in a window has a named cause. And Catalyst multi-window needs the macNative.multiWindow build hint, because a second window is a second scene and that requires a process-wide Info.plist key. Vale reports zero issues at suggestion level, LanguageTool zero matches across the guide, and the paragraph capitalization check passes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Adds a port-level test for the riskiest edit in this work, which had no coverage before and sits in the paint path where a regression shows up as wrong pixels rather than an exception. Two canvases must resolve to two distinct screen buffers -- sharing one is exactly what would make a second window draw into the first window's pixels. And isScreenGraphics has to answer true for a secondary window's buffer as well as the primary one, but still false for a mutable image: drawNativePeerImpl uses that answer to decide whether to undo the zoom scale, so a wrong answer mis-scales a window's peer components. 222 JavaSE port tests pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Compiling CN1MacWindows.m against the actual Mac Catalyst SDK -- which the earlier commit never did -- turned up three defects that would have shipped. Scene-to-window matching was a race. Creation returns a slot immediately and requests the scene asynchronously, and the arriving scene was handed to the first unattached slot. Two windows opened in quick succession could therefore swap identities. Scenes are delivered in request order, so the pending slots are now a FIFO, enqueued on the same main-thread turn as the request; a window destroyed before its scene arrives leaves the queue. The presented frame was a use-after-free waiting to happen. flushGraphics allocates a local Java int[], and the native side wrapped that pointer in a CGBitmapContext, then used the resulting image on a later main-queue turn -- by which time the array is garbage and the collector may have reclaimed or moved it. The pixels are now copied, and handed to a CGDataProvider with a release callback rather than a bitmap context: CGBitmapContextCreateImage is copy-on-write, so it is not defined when the backing buffer becomes free to release, whereas the provider makes that lifetime explicit. The alpha format was wrong. getRGB returns straight ARGB and the image declared kCGImageAlphaPremultipliedFirst, which would darken every pixel that is not fully opaque. A window's content is opaque, so it now skips the alpha channel. Also uses slotForScene, which was dead code, to reject a scene that was already adopted. Verified by compiling both CN1MacWindows.m and CodenameOne_GLSceneDelegate.m for arm64-apple-ios-macabi against the real SDK: clean with -Wall. The same file built for plain iOS exports zero CN1MacWindow symbols, confirming the whole implementation compiles out and the iOS binary is unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Compiling the native sources -- which the port commits never did -- turned up three defects, one of them serious. WM_CN1_DESKTOPWINDOW was defined as WM_APP + 24, which WM_CN1_WIDGET already uses. Widget ops and desktop-window ops would have been delivered to each other's handlers, both of them casting the same LPARAM to a different struct. Moved to WM_APP + 25; the duplicate is now checked for rather than assumed absent. The two COM release calls in the Windows window layer did not resolve. This port compiles its Direct2D translation units as C++ and resolves COBJMACROS-style call sites through an explicit shim in cn1_windows_comc.h, which defines only the methods the port actually uses -- and it had no Release entry for either the HWND render target or the solid colour brush. Added both, in the shim's existing style, rather than reaching around it. On Linux, the GtkWidget-typed accessors were declared in cn1_linux.h. That header is included by translation units that have no GTK on their include path, and declaring a GtkWidget* there breaks them. Moved to cn1_linux_gfx.h, which is the header that includes gtk and where the equivalent existing declarations already live. Verified with the real toolchains available here: cn1_linux_desktopwindow.c is clean under -Wall against GTK 3, and every Windows translation unit including the new one now reports zero errors of its own. The remaining diagnostics in both ports reproduce identically on master and come from compiling Linux and Windows sources on a Mac. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ault Findings from actually building and running the Catalyst app on a Mac, which no earlier commit had done. MacWindowManager never implemented capture(), so it inherited the base class's null. Every windowed screenshot test failed with "Window capture returned null". On this platform the window's content is already rendered into a mutable image, so a capture is that raster. The screenshot harness waited a fixed 1.2s on a UITimer bound to the current form. Catalyst creates its window asynchronously -- it asks the system to activate a scene and is handed one back later -- so a fixed delay is both too long on the fast ports and too short here, and the timer's bound form is not the window anyway. It now polls for the window actually being renderable, re-queuing through callSerially rather than sleeping: the paint that makes it renderable happens on that very thread, so blocking there would stop the condition ever becoming true. macNative.multiWindow now defaults to false for the sample as well. That is measured, not cautious: with multiple scenes enabled, this suite's OrientationLockScreenshotTest captures its landscape frame and then times out after 20s trying to restore portrait. Catalyst treats a multiple-scene app's windows more like Mac windows and honours orientation requests less, so the regression belongs to the Info.plist key rather than to the window code. This gives the warning already in IPhoneBuilder a concrete mechanism instead of folklore. What the run did confirm: the Info.plist key is emitted correctly, CN1MacWindows.m compiles clean under Xcode's own flags, the app boots with multiple scenes enabled and runs all 178 tests without the crash the older comment described, and MultiWindowApiTest passes on the supported path -- so a real Catalyst Window is created, registered, resolves getTopLevelContainer() to itself, reports null from getComponentForm(), reports its monitor and scale, lays out to its own size rather than the display's, and deregisters on dispose. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two corrections from further runs on real hardware. The previous commit blamed multiple scenes for OrientationLockScreenshotTest timing out while restoring portrait. That was wrong. With the key still enabled the test passed in the following runs, so it was a slow-machine flake -- the machine was compiling at the time -- not a consequence of the Info.plist key. The hint stays off by default anyway, on the honest grounds that it changes Catalyst windowing process-wide and an application should opt into that rather than have it changed underneath it. The screenshot harness was also asking the wrong question. It waited for the window to report itself showing at its requested size, but a window reports the size it was asked for before the platform has actually produced anything -- on Catalyst the scene arrives asynchronously -- so both were true within milliseconds and the capture then failed. Readiness is now "a capture succeeds", which is exactly the condition the next line depends on and is correct on every port. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Running the Catalyst suite showed every windowed screenshot emitting a blank frame: the sizes differed correctly per window, but the content did not, and the harness reported the captures as duplicates of each other. The cause is that a window's raster exists from the moment it is shown, so a capture taken before the first paint cycle returns an empty frame of the right size rather than failing. The harness had no way to tell the two apart. Window now records when a paint cycle has completed and exposes hasPaintedOnce(), and the screenshot harness waits on that as well as on the capture succeeding. This is useful beyond the tests: any tooling that wants a window's content rather than its dimensions needs the same distinction. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Built and ran the conformance suite as a Mac Catalyst app on real hardware with multi-window enabled: 0 failures across all 178 tests, and all 14 windowed screenshots captured with distinct hashes and no duplicates -- including the modal case, whose background window is non-blank while a modal is up, which is the property that proves the event loop keeps servicing it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The extra macNative.multiWindow switch existed only because Mac Catalyst scenes were unverified. They are verified now -- the whole conformance suite runs as a Catalyst app with multiple scenes enabled -- so gating it behind a second opt-in only meant CI never exercised the feature. UIApplicationSupportsMultipleScenes is a process wide Info.plist key, so it is still keyed off macNative.enabled rather than set unconditionally: that key is true for the Mac Catalyst slice only and false for iPhone and iPad builds, which keeps the iOS output byte for byte identical. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Inspecting the Mac Catalyst captures rather than only their hashes showed three defects that distinct hashes had hidden. A Catalyst scene was never asked for the geometry the window was created with, so the system handed it the main scene's size. The window then laid out into a raster that did not match the request: several captures came out at the main display size with the window's content in the corner. The scene now requests the pending geometry as soon as it connects, and both that request and setBounds convert Codename One's pixels to UIKit's points. getBounds reports pixels to match getWidth and getHeight. The readiness probe accepted a window that had painted and could be captured, neither of which implies the size settled -- which is how the mismatch reached a golden in the first place. It now also requires the window and the captured image to be exactly the requested size, so a platform that cannot grant it fails loudly instead of baking a wrong baseline. A window used its own Window and WindowContentPane UIIDs, which no theme written before desktop windows existed defines, so it painted nothing and came up black. A window is a top level surface, so it now takes the Form, ContentPane and TitleArea styles every theme already has. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Dispatch key events to the window's focused component
When f is a Window, this invokes the inherited Container.keyPressed(), because Window does not override the key handlers. That implementation only forwards to a container lead component, so ordinary focused controls receive no physical-key input, focus traversal never runs, and the listeners stored by Window.addKeyListener() are never fired. Window needs form-equivalent key pressed, released, repeated, and long-press dispatch.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Collaborator
Author
|
Compared 12 screenshots: 12 matched. |
The guide gate requires every source block to come from a tagged fixture under a compiled source root, so the snippets are checked by javac rather than only by eye. This chapter had them inline. Two of them did not survive the move as written: one relied on an ellipsis inside a switch and another on a call that has no declaration, so both are now complete code. Also documents the styling a window starts out with. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Closing one window and opening another failed on Mac Catalyst with "scene invalidated before create completion": the system does not hand out a scene session while a previous destruction is still in flight, and the window that asked was left without one. That is an ordinary sequence, so a closed window now parks its scene for the next window to adopt rather than destroying it. The size query also answered with the size that was requested while the scene did not exist yet, so a window looked correctly sized during exactly the interval when nothing was known about it. It now answers zero until there is something real to measure, and show() keeps the requested size until a port delivers a real one instead of collapsing the window to nothing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 23ab1188ae
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
RadioButton.initNamedGroup stored the named ButtonGroup as a client property on the form and dereferenced it unguarded, so showing a window containing a grouped radio button threw before the native window was mapped. The group now lives on whichever top level owns the button. TextArea's early-press listener was registered on the window but its body still resolved getComponentForm(), so it did nothing there and the documented pre-click action event never fired. Same pass over the rest of the bucket, migrating the ones that are guarded but dead inside a Window: PeerComponent and NativeMap revalidate, ContainerList, SplitPane cursors, Table focus lookups, Tabs awaiting-release clearing, TextArea input device, GameView safe area, and List revalidate and single focus mode. CodenameOneImplementation.setFocusedEditingText moved focus through the form, so focus never followed the component being edited in a window. ComboBox is left resolving the Form: its popup measures against the soft button bar, which a Window does not have. The text-area test asserts only that a window-tagged press reaches an editing text area and is handled. Both stronger assertions I tried -- that an action event fired, and that suppressActionEvent was set -- pass against the un-fixed listener, because the press path reaches both by another route. Said so in the test rather than leaving an assertion that looks like proof and is not. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: de19aa626a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Display.editString() resolved getComponentForm() and returned outright when it was null -- which it always is inside a Window. That single guard rejected every editor in a window before impl.editStringImpl() was reached, so none of the port-level editor routing this PR adds could run, however correct the ports were. The windowed screenshot goldens could not see it either: a field that never enters editing still renders. The Linux browser peer started its poller only when getComponentForm() was non-null, so poll() never drained the native LOAD, NAV and MSG events and onLoad, navigation callbacks and JavaScript return callbacks never fired in a window. The same pattern was in five more peers -- LinuxGLSurface, LinuxCameraImpl, WindowsGLSurface, WindowsBrowserComponent and WindowsCameraImpl -- and all of them are fixed, since peer components in windows are in scope. EditorView.blur() cleared focus through the form, so blurring inside a window merely stopped the input session: focusLost() never ran, leaving the caret animation registered and the global multi-key mode switched on while the editor still reported focus. ImageDownloadService chose between two otherwise identical branches by whether the label was on a form, and only one of them revalidated. A label in a window took the branch that never reflows, so the window stayed laid out for the placeholder's size. Collapsed into one branch. Also completes the licence header on five port files that carried a truncated copy or none at all; they only came into the gate's view now because this is the first change to touch them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c0a407b67e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…nds real The snapshot ring was sized for one input event stack, but Display double buffers: the event dispatch thread swaps a full batch out and dispatches it while the native input thread fills the other, so both are live at once. Two 1000-int stacks at three ints per pointer packet is a ceiling of about 666 snapshots, past the 512-slot ring -- which would wrap onto packets that had not been dispatched and hand them the wrong button or device type under a sustained burst. Now 2048, with a test that asserts the arithmetic rather than the number, so growing the stack without growing the ring fails there instead of producing a rare misdispatch. Window.addCommand only appended to a private list. Nothing consumed it, so a command added to a window was never displayed and never activated, unlike the identical call on a Form. Adds WindowManager.setCommands, a no-op by default, and publishes the list through it on add, remove, clear and at show() -- the last so commands added before the peer exists are not lost. JavaSE implements it by installing a native menu bar on the window's own frame, the per-window counterpart of what the main window already does, so the desktop shortcut accelerators work there too. Ports with no command surface leave them undisplayed, and dispatchCommand remains the programmatic path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8342617b3c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Two defects in the native menu I connected in the previous commit, both of them mine. The menu item invoked cmd.actionPerformed() directly, so command listeners registered with Window.addCommandListener() never saw the activation -- which is exactly the contract the previous commit claimed to satisfy. The builder now takes the owning window and routes through Window.dispatchCommand(). And the builder appends the MCP tooling menu unconditionally, so every command-bearing application window gained development controls like "Expose This Tool To Agents". My own javadoc on the window entry point asserted the MCP menu belonged to the main frame only, which was simply not true of the code beneath it. It is now conditional on there being no owning window. Both halves verified separately against reverted code, since the first assertion short-circuits the second. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f3f0fe9c54
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Window.repaintAnimations ran both registries without excluding what the public list had already handled, which Form does deliberately. A component can sit in both -- an explicitly animated scrollable whose fading scrollbar is also running -- and animating it twice per frame advances its motion at double speed and repeats any side effect. Validator's outer guard still resolved the form, so the top-level-aware glass pane installation beneath it was unreachable and EMBLEM validation displayed nothing inside a window. ImageViewer's swipe-pan animation registered and deregistered against Display.getCurrent(), which only ever names a Form: null in a window-only application, and the wrong surface when a main form happens to exist. That last one is a pattern the earlier sweeps did not cover -- Display.getCurrent() standing in for a component's own top level -- so it was audited too. It is the only occurrence in core that a window can reach; SideMenuBar and SwipeBackSupport are Form-only features, and the iOS, Android and BlackBerry uses are on platforms with no windowing system. The validation test drives setValid() reflectively rather than going through addConstraint: the full constraint path pulls in listener wiring that wedges the event dispatch thread in this harness, and the glass pane installation is what is under test. Said so in the test. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2c738b47eb
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
gtk_window_set_modal() makes a window modal for the whole application rather than for its transient parent, and the Linux port raised it for MODALITY_WINDOW as well. Every other secondary window and the main form became unusable, while Display.blocks() deliberately blocks only the owner. The flag is now raised only for MODALITY_APPLICATION; window-scoped modality expresses its scope through the per-window sensitivity wiring that already exists. Checked the other two ports for the same mistake: JavaSE uses the flag for window elevation only and Windows does nothing at all there, both leaving the decision to the framework, so Linux was the only one. windowCloseRequested() tested the modal stack on the port's callback thread while show, hide and dispose mutate it on the event dispatch thread. isBlockedByModal takes the stack's size and then indexes it, which a concurrent removal turns into an exception, and a stale read could let a blocked window's close through. The callback is now queued first and the check made inside it, so the stack is only ever read on the thread that writes it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d9bb05bdc2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Three lookups in the JavaSE port answered about the main form even when the event had arrived on a secondary window's canvas. A PeerComponent in a window was hit tested against the current form, so an unrelated main-form component at those window-local coordinates -- not a peer -- set cn1GrabbedDrag and the event was consumed. Browser links and other native peer controls in a window stopped receiving mouse input entirely. Both halves of that lookup are fixed: Peer.sendToCn1 and C.mousePressed. isPureEditorFocused() inspected only the current form, so an EditorView focused in a window was treated as not focused: Space and Enter became GAME_KEY_CODE_FIRE instead of characters and editing shortcuts were dropped. All three now go through a new C.canvasTopLevel(), which answers with the current form for the main canvas -- byte-for-byte the old behaviour there -- and with the window the canvas renders otherwise. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 965e2bb240
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
The topology poller fingerprinted count, bounds and scale. A taskbar or dock that moves edge, changes size or toggles auto-hide reconfigures the work area while leaving all three identical, so the fingerprint was byte-identical across the change and monitorsChanged() never ran: windows kept a stale work area, centerOnDesktop() could place one underneath the taskbar that had just appeared, and monitor listeners heard nothing. Screen insets are now part of the fingerprint. The test rebuilds the old bounds-and-scale-only string and requires the real one to differ from it, rather than asserting a literal -- so it keeps meaning if the fingerprint format changes again. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e52eef5623
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…ectly TextSelection.setEnabled resolved the root's form and dereferenced the null result, so enabling text selection -- which TopLevelContainer exposes on every top level -- threw in every secondary window. It now resolves the root's top level, and the enabled flag is only set once the wiring has actually happened rather than before an early return. A Button backed by a Command forwarded its post-command event through getComponentForm(), so a window's command listeners never saw the activation. Adds Window.dispatchCommandNoRecurse, the counterpart of Form's no-recurse dispatch, and neither path re-invokes the command the button has already run. The validation emblem chose its flip position against Display.getDisplayWidth(). Component coordinates are local to their own window, so a narrower window clipped the emblem and a wider one flipped it needlessly. It now measures the owning top level. That last one is another axis the earlier sweeps did not cover -- getDisplayWidth standing in for a component's own surface -- so it was audited. ImageViewer's empty preferred size, ScaleImageLabel's oversized-width clamp and SplitPane's divider span all asked for the whole screen inside a window and now span their own surface. OnOffSwitch's and Ads' uses are device-class heuristics rather than surface sizes and are left alone; ToastBar and InteractionDialog are documented as unsupported in a window. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 47b0a0a311
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Toolbar.showSearchBar assigned getComponentForm() and dereferenced it on the next line, so activating a search command in a window threw. Fixing it uncovered two deeper reasons a Toolbar could not work in a window at all: Its initialized flag was only ever raised by initMenuBar, which a Window never runs -- it has no MenuBar and installs the toolbar in its title area. Every guarded Toolbar method therefore refused with "Need to call Form#setToolBar" for a toolbar that was in fact installed. Window.setToolbar now marks it, and adopts the window's title, which is what a Form does in the same place. And setBackCommand dereferenced the form unconditionally. The back command is Form navigation, which a Window has no notion of, so it is now guarded; the visible back button the policy adds is an ordinary left-bar command and still works. Also: the Tabs swipe hit test resolved Display.getCurrent(), so a window's swipe was tested against an unrelated main-form component at the same coordinates and blockSwipe was set; ChartComponent's two zoom transition classes resolved the form and removed themselves without starting, so a zoom with a duration silently did nothing; TextSelection's four auto-scroll callbacks did the same, so holding the pointer at an edge stopped extending the selection; and ImageDownloadService's cache-hit return revalidated through the form, bypassing the completion path fixed earlier, so a cached image left the layout sized for the placeholder. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 032ac61ea5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
C.ancestorResized is primary-surface logic that a secondary canvas also runs, being the same class on the same listener, and its body reaches canvas.setForcedSize() -- the port's canvas field, not the instance the event arrived on. Every secondary-window resize therefore stamped the main canvas with the secondary window's dimensions, and a later Swing layout could resize or clip the main surface. queueSizeChangeEvent already guarded itself, but by the time it ran the main canvas had been mutated, so the rejection moves to the top of the handler. A secondary window's own resize arrives through its componentResized, window-tagged. The Ctrl/Cmd+A and Ctrl/Cmd+C selection shortcuts resolved CN.getCurrentForm(), so in a window they operated on the unrelated main form, or on nothing at all in a window-only application. Both now resolve canvasTopLevel(), like the hit tests and editor-focus lookup beside them. The test hosts the secondary canvas in a real JFrame. Without that it fails against the un-fixed code by tripping over a null ancestor before reaching the assertion -- passing for a reason that has nothing to do with the defect. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ardown The macOS runner finally ran the windowed suite to completion -- this is the first mac-native run on the branch that was not cancelled -- so the twelve Window-* captures it produced are now committed as goldens. Each is exactly the size its test requested, and they render the real widget set, list, shapes and text fields rather than blank surfaces. Two of the fourteen were not produced. WindowEditingTest captured its first size and then reported the window at 1024x768, Catalyst's default scene size, for both remaining sizes, so it never became renderable and timed out. The captured image shows a caret in the first text field: the editor is genuinely active now that Display.editString reaches the port from a window, and a native editor holds platform state tied to the window it is in, which pins the Catalyst scene. WindowHostTest now stops any editor before tearing its window down, so the next window is created against a released scene. The remaining two goldens follow once a run produces them; committing twelve now turns twelve missing_expected comparisons into real ones rather than leaving the whole set unguarded. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
The copyright gate checks every file changed across the whole PR, not just the last commit, so a file added earlier in the branch without a header only surfaced now. Worth noting how this was missed: running the script with no arguments compares against the working tree, so on a clean tree it checks zero files and reports success. Reproducing CI needs the PR base explicitly: scripts/check-copyright-headers.sh --base <pr-base-sha> --head HEAD Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
The stop-the-editor-before-teardown fix worked: WindowEditingTest captured all three sizes this run, so Catalyst now has the same fourteen window goldens as Linux and Windows. The twelve committed last time all matched on this fresh run -- Window-Editing- 400x300 came back byte-identical at fnv1a64 99971c0729d29e97 -- so they are reproducible rather than a snapshot of one run's luck. Both new captures are the size their test asked for and show the caret in the first field, which is the editor actually running in a secondary window. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
A UIWindowSceneGeometryPreferences is a request, not an instruction. When the window manager ignores one the scene keeps the size it already had -- Catalyst's 1024x768 default -- and nothing asked again, so the window stayed the wrong size for good. That is what left the windowed screenshot suite intermittently short of captures. Whichever test lost a request reported showing=true painted=true at 1024x768 and never became renderable at the size it asked for: WindowEditingTest one run, WindowScrollTest and WindowGraphicsTest the next. The stop-the-editor fix in the previous commit was not what unblocked editing -- the failure simply moved, which the second run made clear. Both request sites -- scene adoption and setBounds -- now retry on the main queue until the delivered size matches, eight attempts over roughly two and a half seconds, well inside the harness's ten second readiness deadline. It stops as soon as the size matches, so a granted request costs one extra check. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Codename One has no windowing API. Even on JavaSE, Mac, Win32 and Linux, where the OS has real windows, an app gets exactly one, welded to a single global "current Form":
CodenameOneImplementationholds onecurrentForm,Display.edtLoopImplpaints one surface per tick,paintDirtyuses one global paint queue clipped togetDisplayWidth()/getDisplayHeight(), andhandleEventroutes every input event to one form. Everything that looks like a second window today —Sheet,InteractionDialog,ToastBar,Dialog— is an overlay inside the current form's layered panes.This adds real native windows, each rendering its own component tree, on all four desktop targets, without changing the single-form model mobile depends on.
API
TopLevelContaineris the shared contractFormandWindowboth implement. Its members were chosen by counting actualgetComponentForm().<method>()chains inCodenameOne/src, and every one of them was already public onFormwith an identical signature, soFormneeded nothing beyond theimplementsclause andasContainer()— a Java interface cannot extend a class, so without that bridge aTopLevelContainerreference cannot go anywhere aComponentis wanted.Window extends Container implements TopLevelContainer. Inside a windowgetComponentForm()returnsnull, by design;Component.getTopLevelContainer()is the new resolution API, and core now uses it internally.DesktopandMonitorare the public parallel toDisplayfor "what screens exist and what windows are open", including per-monitor DPI and backing scale;Displaykeeps meaning "the main app surface" exactly as before.Modality is enforced in core rather than per port, so it behaves identically everywhere:
Displaykeeps a modal stack andhandleEventdrops input to blocked windows.showModal()parks the caller throughinvokeAndBlockthe wayDialogalready does, which re-enters the event loop — so every other window stays live and repainting while a modal is up.Implementation
The impl SPI is a single
WindowManagerfacade returned fromCodenameOneImplementation.getWindowManager(). Returningnullis the capability query, so there is no separateisMultiWindowSupported()that could drift from it. Only genuinely universal operations are abstract; anything a port might not offer has a no-op default, so adding a capability later never breaks a port.Per-window paint state moves into a
PaintSurfacevalue object with the main window as instance zero;getCodenameOneGraphics(),repaint(Animation),cancelRepaintandhasPendingPaints()keep their signatures, so every existing port still compiles and behaves.paintDirty()'s body is parameterized rather than globally rebound — a global "active surface" was rejected becauseDisplay.getDisplayWidth()is public and callable off the EDT, so a live binding would change its answer re-entrantly across ~210 call sites.Events pack the window id into the type word (
type | (windowId << 8)). Window 0 is numerically identical to the previous wire format, so drag coalescing and the stack-swap logic are untouched. The port is handed the id at creation and echoes it back, so there is no peer-to-window map on the off-EDT input path.Ports: JavaSE (per-canvas graphics de-singletonization —
getNativeGraphicsused to return one shared instance, andisScreenGraphicswas an identity check against one buffer, so a second window would have drawn into the first window's pixels), native Windows (Direct2D per-window render targets,GWLP_USERDATAidentity,WM_DPICHANGED), native Linux (per-window cairo back buffer, GTK closure data), and Mac Catalyst (UIWindowSceneper window). Peer components and native text editing work in every window on every one of the four. iOS, Android and JavaScript need no port changes at all: they inherit the false capability and the throw lives in core.Latent bug fixed on the way
handleEventreturnedoffsetunchanged when the form was null, while the caller loopswhile (offset < actualTmpPointer)— an infinite EDT spin. It is unreachable today only because all nine entry points guard ongetCurrentForm() != null; window disposal with events in flight makes it reachable. It is now askipEventthat drains the packet so the rest of the batch still dispatches.Testing
Core unit tests drive a scriptable fake
WindowManageronTestCodenameOneImplementation— settable, defaulting to null, so the unsupported path is the default — covering lifecycle, paint isolation, event routing, modality including a modal window nested in a modal dialog, theTopLevelContainercontract, and a fake multi-monitor table at mixed DPI. JavaSE port tests cover the per-canvas graphics resolution, which is the riskiest edit here and had no coverage before.The centrepiece is a windowed screenshot family in
scripts/hellocodenameone: representative UI re-run inside a real window at several sizes and compared against its own goldens. A picture of a window proves nothing; layout, scrolling, graphics, layered overlays, native editing and modality rendering correctly on a non-primary surface is the actual claim. The three sizes, including a deliberately non-square one, are what prove content lays out to the window rather than toDisplay.getDisplayWidth(). This needed per-window capture on every port, since the existing pipeline can only see the main framebuffer.Mac Catalyst was built and run on real hardware for this branch rather than left to CI, because it is the hardest of the four. That found four defects compiling never would have:
capture()was unimplemented; the readiness probe was a false positive; captures were taken before the first paint; and the scene was never asked for the geometry the window was created with, so several captures came out at the main display size with the window's content in the corner.Known scope limits, documented
HTMLComponent, accessibility on secondary windows,Dialog.show()from inside a window and form transitions into or out of one are out of scope for v1 and called out in the guide.Display.getDisplayWidth()/getDisplayHeight()keep reporting the main window; components inside a window use their top level's size.🤖 Generated with Claude Code