Codename One now exposes a portable semantics tree to VoiceOver, TalkBack, UI Automation, AT-SPI, Java accessibility, and web ARIA.'
+series: ["release-2026-07-17"]
+---
+
+
+
+Accessibility has become personal for me. I am getting older, and large type is no longer an abstract preference somebody else needs. It is how I read a phone comfortably.
+
+I worked with accessibility experts at Sun Microsystems and learned how deep the problem goes. A label is the easy part. Real accessibility needs roles, values, ranges, actions, traversal order, live announcements, collections, focus, platform conventions, and a way to test all of it. That complexity is why full Codename One accessibility support sat dormant for a decade.
+
+We eventually added `setAccessibilityText()`. It was useful, but it was the poor man's version. [PR #5363](https://github.com/codenameone/CodenameOne/pull/5363) replaces that single-label model with a portable semantics tree we can be proud of.
+
+## Lightweight UI needs a second tree
+
+Codename One paints lightweight components into its own native surface. VoiceOver cannot inspect a `Button` as a UIKit button because there is no UIKit button there. TalkBack cannot walk an Android `View` hierarchy because most of the painted controls are not Android views.
+
+The new accessibility manager builds an immutable virtual tree beside the visual component tree. Standard controls infer their semantics. Custom controls can replace or extend them. Each port exposes that virtual tree through the platform accessibility API.
+
+{{< mermaid >}}
+flowchart TD
+ A["Codename One component tree"] --> B["Portable semantics tree"]
+ B --> C["VoiceOver
A running Codename One simulator or JavaSE tool can expose its semantic UI and application tools to coding agents over MCP.'
+series: ["release-2026-07-17"]
+---
+
+
+
+[Yesterday's accessibility work](/blog/accessibility-semantics/) created an immutable tree that describes what is on screen, what each item means, and which actions it supports. VoiceOver and TalkBack consume that tree for people.
+
+[PR #5377](https://github.com/codenameone/CodenameOne/pull/5377) lets an agent consume it too.
+
+The JavaSE port can expose a running simulator or Codename One desktop tool as a local [Model Context Protocol](https://modelcontextprotocol.io/) server. Codex, Claude Code, Claude Desktop, opencode, or another MCP host can inspect the current form, find a field by label, enter text, activate a button, and call tools published by the application.
+
+## The agent reads meaning, not coordinates
+
+Screenshot automation sees colored rectangles and guesses where to click. MCP exposes the same resolved semantics that accessibility technology receives:
+
+```json
+{
+ "id": "profile-save",
+ "role": "button",
+ "label": "Save",
+ "enabled": true,
+ "actions": ["activate"]
+}
+```
+
+The agent can ask for `ui_snapshot`, find `profile-save`, then invoke `activate`. It does not need to assume the button stayed at yesterday's x and y coordinates.
+
+{{< mermaid >}}
+sequenceDiagram
+ participant Agent as MCP host
+ participant Server as Codename One MCP server
+ participant Tree as Accessibility snapshot
+ participant EDT as Codename One EDT
+ Agent->>Server: ui_snapshot
+ Server->>Tree: build immutable semantics tree
+ Tree-->>Agent: roles, labels, values, actions
+ Agent->>Server: ui_set_text(profile-name, "Ada")
+ Server->>EDT: dispatch action
+ EDT-->>Server: success + fresh snapshot
+ Server-->>Agent: updated UI state
+{{< /mermaid >}}
+
+The built-in tools are small on purpose:
+
+| Tool | Purpose |
+|---|---|
+| `ui_snapshot` | Return the current semantic UI tree as JSON |
+| `ui_find` | Find nodes by identifier, label, or screen coordinate |
+| `ui_perform_action` | Run a semantic action with an optional argument |
+| `ui_activate` | Activate a node |
+| `ui_set_text` | Set editable text through the UI action model |
+
+Every action runs on the Codename One event dispatch thread. The agent never mutates the live component tree from the MCP transport thread. Each action returns a fresh snapshot so the next decision uses current state.
+
+## Starting a server is explicit
+
+There is no build hint that quietly exposes an application. Calling the API is the switch:
+
+```java
+MCP.startSocketServer(8765);
+```
+
+The socket mode is useful for a running simulator session a person can watch. A tool launched directly by an MCP host can use standard input and output instead:
+
+```java
+MCP.startStdioServer();
+```
+
+The JavaSE port owns the stdio transport because process standard input is not available on every Codename One target. While the transport is active, normal application logging is redirected away from standard output so it cannot corrupt the newline-delimited JSON-RPC stream.
+
+## Desktop tools get a menu without application code
+
+The JavaSE port adds an MCP menu to the simulator and Codename One desktop tools, including the new Settings editor. The menu can expose the running tool, detect installed MCP hosts, install or remove the local host registration, and control debug logging.
+
+Registration uses a small bridge. Most local MCP hosts launch servers over stdio. The visible Codename One tool is already running and listens on a loopback socket. `MCPStdioLauncher` relays between the host's stdio connection and that socket.
+
+```text
+Coding agent <-- stdio --> MCPStdioLauncher <-- loopback --> running tool
+```
+
+This is how an agent can drive the actual Certificate Wizard or Settings window in front of you instead of launching a hidden copy with different state.
+
+## Your app can publish domain tools
+
+UI actions are useful, but some operations should not be simulated as clicks. An application can expose a typed `Tool` with a JSON schema and handler:
+
+```java
+MCP.addTool(new Tool(
+ "current_user",
+ "Returns the signed in user",
+ "{\"type\":\"object\",\"properties\":{}}",
+ argumentsJson -> "{\"name\":\"" + signedInUser + "\"}"
+));
+```
+
+The server merges application tools with the built-in UI tools. Codename One already uses the same `com.codename1.ai.Tool` contract for model tool calls inside an app, so one definition can serve an in-app model and an external MCP host.
+
+Treat these tools as a privileged API. Do not publish a tool that returns signing passwords, API tokens, or unrestricted file contents because the handler happens to be local. The current server is local, but the agent still receives whatever the tool returns.
+
+## Screenshots remain available
+
+The semantic tree means a vision model does not need a screenshot for routine navigation. Some UI facts remain visual, such as a chart shape or a rendering defect. The server therefore exposes the current form as an optional PNG resource too.
+
+The two sources complement each other. The tree says “this is an enabled Save button with an activate action.” The PNG says “the button overlaps the footer.” A screenshot alone cannot reliably provide the first fact. A semantic tree cannot provide the second.
+
+## The scope is JavaSE today
+
+This release supports the JavaSE port, which covers the simulator and JavaSE-hosted desktop tools. It does not make every packaged Codename One application an MCP server. Packaged executable jars, cloud desktop builds, mobile targets, the JavaScript port, and the native macOS, Linux, and Windows ports do not yet have the launcher and transport plumbing.
+
+If you need MCP in one of those native targets, let us know which port and deployment model you need. The protocol engine and semantic tools are portable. The missing work is the transport, startup, registration, and security boundary for that target.
+
+The PR includes 13 protocol and UI-driving tests plus an end-to-end run against the reference MCP Inspector client. It also builds the core into an iOS application to verify that unused MCP code is pruned and that referenced core classes stay within the ParparVM API surface.
+
+Tomorrow's post covers another machine-readable view of Codename One. The new port status page turns the test suite into a dated support matrix instead of asking you to trust a manually maintained table.
+
+---
+
+## Discussion
+
+_Join the conversation via GitHub Discussions._
+
+{{< giscus >}}
diff --git a/docs/website/content/blog/pixel-perfect-is-a-test.md b/docs/website/content/blog/pixel-perfect-is-a-test.md
new file mode 100644
index 00000000000..0410b4d3b5a
--- /dev/null
+++ b/docs/website/content/blog/pixel-perfect-is-a-test.md
@@ -0,0 +1,208 @@
+---
+title: "Pixel Perfect Is a Test, Not a Claim"
+slug: pixel-perfect-is-a-test
+url: /blog/pixel-perfect-is-a-test/
+date: '2026-07-17'
+author: Shai Almog
+description: "Codename One now compares its iOS 26 Liquid Glass and Android Material 3 themes against native reference apps in CI. The suite measures pixels, geometry, and fixed animation frames, then prevents the UI from drifting below the recorded baseline."
+feed_html: '
Codename One now compares its iOS 26 Liquid Glass and Android Material 3 themes against native reference apps in CI, including geometry and animation checks.'
+series: ["release-2026-07-17"]
+---
+
+
+
+Codename One does not wrap UIKit or Material widgets. It compiles to a native app, then paints its own UI. That gives you control over every pixel, but it also creates an obligation: if we say a theme follows iOS 26 or Material 3, we need more than a good screenshot and an adjective.
+
+So we built native iOS and Android apps to grade us.
+
+[Last week's release](/blog/beating-hotspot-performance/) rebuilt large parts of ParparVM. I expected that to remain the most involved work of the summer. The theme fidelity work took longer. [PR #5274](https://github.com/codenameone/CodenameOne/pull/5274) alone reports 53,000 additions across 1,147 changed files. Generated access registries, resources, screenshots, and native goldens account for much of that number, but the scale is still real. Five follow-up PRs then fixed what the first pass exposed.
+
+The result is not a claim of 100% visual identity. It is a repeatable process for getting closer and for stopping accidental drift.
+
+## The themes were modern, but they were not finished
+
+We introduced the [iOS Modern and Android Material 3 themes](/blog/liquid-glass-material-3-modern-native-themes/) in May. They gave new projects a current starting point, but the first iOS implementation used translucent colors where iOS 26 uses a live glass material. Several controls still carried general Codename One geometry. The Material floating action button was a good example: it inherited the old circular shape and icon-derived size instead of Material 3's fixed 56dp rounded rectangle.
+
+This is the Android floating action button before and after the fidelity pass. The older render is on the left. The current Material 3 render is on the right.
+
+
+
+The iOS theme changed just as visibly. Buttons became full capsules, state glyphs moved to SF Symbols, and the sizes and spacing moved toward the iOS 26 references. The May render is on the left and the current render is on the right.
+
+
+
+Why is the floating action button still circular on iOS? iOS has no native floating action button equivalent. Importing Material's rounded rectangle into the iOS theme would make it less native, not more. Android follows Material 3. iOS keeps the established circular accent action until there is an iOS component we can honestly target.
+
+## A native app produces the answer sheet
+
+The fidelity suite contains two standalone reference applications. One is written with UIKit and Swift. The other uses Android's Material components. We run those apps locally on pinned native toolchains and capture real controls in light and dark appearances, including normal, pressed, selected, and disabled states.
+
+The native captures are committed as versioned golden sets:
+
+```text
+scripts/fidelity-app/goldens/
+ ios-26-metal/
+ ios-26-metal-anim/
+ ios-26-metal-frames/
+ android-m3/
+ android-m3-anim/
+```
+
+CI never invents the native side. It renders the Codename One component under the matching theme, compares it with the committed native image, and reports both visual and geometric differences. A one-way gate fails if a score drops below its recorded baseline.
+
+{{< mermaid >}}
+flowchart LR
+ A["UIKit reference appiOS 26 simulator"] --> B["Versioned native goldens"] + C["Material reference app
API 36 emulator"] --> B + D["Codename One fidelity app
rendered in CI"] --> E["Pixel comparison"] + B --> E + E --> F["Visual score"] + E --> G["Geometry metrics"] + E --> H["Fixed animation frames"] + F --> I["One-way baseline gate"] + G --> I + H --> I +{{< /mermaid >}} + +The iOS golden set is pinned to iOS 26. The Android set is pinned to Material 3 on API 36 at 160dpi. When iOS 27 arrives, we will capture a new `ios-27` set, add a theme variant and a CI matrix row, then test both generations until we deliberately retire the older one. We will not silently replace the iOS 26 answer sheet and call the movement an improvement. + +## What the percentage means, and what it does not + +The current Android baseline contains 54 pairs. Its median tolerant visual score is 95.5%. The worst pair is the dark pressed outlined button at 91.25%. The iOS baseline contains 68 pairs with a 94.4% median. Its worst pair is the dark tab bar at 83.45%. + +Those percentages are useful for a regression gate. They are not a substitute for eyes. + +Thomas made this point in the [PR discussion](https://github.com/codenameone/CodenameOne/pull/5274). A radio button can look identical to a person and still lose points to antialiasing. A large tab bar can hide a wrong icon inside thousands of matching backdrop pixels. A high overlay score can also conceal a wrong width or corner radius. + +We changed the suite in response. It now reports bounding-box offsets, width and height ratios, center offsets, and an estimated corner radius separately from the visual score. The comparison mode also comes from an explicit `material: normal|glass|lens` declaration instead of an image heuristic. Human review remains part of the process, especially for motion and complete application screens. + +Here are four iOS pairs from the automated report. Native is on the left. Codename One is on the right. The dark picker makes the limitation obvious: the selected row is closer, but the off-row contrast still needs work. + + + +The Android report uses the same layout. The floating action button now has Material 3 geometry, while the tab typography and outlined button still show smaller differences that the baseline tracks. + + + +These fixture pairs answer a narrower question than a full app screenshot: does one component match its native reference in a controlled state? They do not prove that every real screen has native spacing, hierarchy, and composition. Thomas asked for known application screens too. That is a fair request, and it is a separate layer we still need to add. The component suite gives us attribution and a CI gate. Full-screen examples give humans context. We need both. + +## The tab bar became a rendering project + +The iOS 26 tab selection is not a tinted pill sliding under icons. During a touch-driven transition, the selection becomes a magnifying lens. It travels across the bar, refracts the background and glyphs under it, stretches during flight, and settles with a small spring overshoot. + +This animation compares the native references with Codename One. The top row is light appearance and the bottom row is dark. Native is on the left. Codename One is on the right. + + + +The static comparison below freezes the useful stages so you can inspect the geometry. + + + +The shared motion lives in `TabSelectionMorph`. Given progress, source and target cells, and a small set of theme tokens, its internal model returns the capsule rectangle, lens rectangle, magnification, aberration, tint, and settle position. `Tabs` paints that result. The switch uses the same approach through `SwitchThumbDroplet`, which stretches and squashes the glass thumb while it moves. + +```text +progress + source cell + target cell + preset tokens + -> pill bounds + lens bounds + optics + settle position +``` + +The public theme surface is intentionally smaller than the internal model. A theme selects `tabsMorphPreset: ios26` or `subtle`, then adjusts duration, lens intensity, and spring percentage. Thirteen low-level motion constants from the first implementation were removed because they made it too easy to tune one screenshot while breaking the path between screenshots. + +The test freezes the animation at 0%, 10%, 25%, 50%, 75%, 90%, and 100%. It checks that the frames are distinct, travel is monotonic, and overshoot stays bounded. The committed intermediate frames are Codename One goldens, not native intermediate-frame comparisons. Native motion is still reviewed from the captured video. That distinction matters. + +## Glass is a typed material, not a pile of constants + +The first glass pass exposed saturation, blur, scale, offset, refraction, and specular values as unrelated theme constants. Review feedback was right: that would become impossible to keep coherent across a toolbar, panel, button, and moving lens. + +`GlassRecipe` now defines four bounded material intents: + +```java +GlassRecipe.plainBlur(); +GlassRecipe.liquidChrome(dark); // edge bars and toolbars +GlassRecipe.liquidPill(dark); // floating tab bar +GlassRecipe.liquidPanel(dark); // general glass surface +``` + +The theme assigns a recipe to a UIID. `Component` resolves it and passes the parameters through `Graphics.glassRegion(...)`. Ports receive a material recipe instead of reading iOS-specific constants during paint. + +On iOS, the moving lens is a Metal fragment shader on the frame's existing command buffer. There is no GPU readback. The larger glass patch does need backdrop pixels, so it uses a cache keyed by bounds, recipe parameters, and a hash of the actual backdrop bytes. In a profiled suite run, full composition averaged about 90ms when the backdrop changed and a stable cache hit averaged 5.3ms, with 475 hits and 253 misses. That is development instrumentation, not a general app benchmark, but it gave us a concrete cache policy. + +JavaSE originally had no `glassRegion` implementation. It silently reduced the bar to a plain blur, leaving the lens to magnify a gray slab. JavaScript discarded the material parameters and used a flat tint plus uniform zoom. [PR #5388](https://github.com/codenameone/CodenameOne/pull/5388) implements the material on both ports and pins 14 constants across JavaScript, JavaSE, the iOS CPU reference, and the Metal shader. The JavaScript lens now produces the same pixel CRC as JavaSE at all seven probe points. + +There is still a platform tradeoff. The iOS path uses the native Metal shader. JavaSE and JavaScript reproduce the pixels in software. They do not get the same GPU path, so a complex moving backdrop can look less smooth there. The component and its state model remain portable. The implementation cost is not identical. + +## CSS had to grow with the themes + +Several differences could not be fixed by editing a color. The framework and CSS compiler gained new vocabulary: + +```css +#Constants { + tabsMorphPreset: "ios26"; + buttonReleaseFadeDurationInt: 180; + tabsEqualWidthBool: true; +} + +RaisedButton { + cn1-background-type: cn1-pill-border; + border: 0.1mm solid rgba(136,254,255,0.58); + cn1-stroke-gradient: #ffffff; + cn1-stroke-gradient-angle: 135deg; +} +``` + +`RoundBorder` now supports a gradient stroke. Button gained an opt-in release overlay so iOS Modern can fade the held state over 180ms instead of snapping it away. `Dialog` and `InteractionDialog` gained opt-in centered-title layouts while keeping command rows flush with the card edges. Tabs gained equal-width cells and a correctly scaled Material indicator. `Style` gained letter spacing. Resource format revisions carry gradients, filters, and gradient strokes into the shipped `.res` files. + +The icon problem also needed a platform answer. Material icons looked wrong inside iOS controls even when their meaning was correct. `FontImage.createSFOrMaterial(...)` selects an Apple SF Symbol on iOS and the Material fallback elsewhere. Toolbar commands can now hide their text visually while retaining the command title for accessibility. + +The follow-ups matter as much as the headline PR: + +- [PR #5373](https://github.com/codenameone/CodenameOne/pull/5373) restored application accent bindings that the first fidelity pass accidentally replaced with fixed colors. The regression also exposed a test that could accept default colors after a retry, so the test was fixed too. +- [PR #5379](https://github.com/codenameone/CodenameOne/pull/5379) added the iOS 26 button capsules, the 180ms release fade, and gradient strokes. +- [PR #5376](https://github.com/codenameone/CodenameOne/pull/5376) added opt-in centered dialog-title layouts and fixed edge-to-edge command grids in both dialog classes. +- [PR #5387](https://github.com/codenameone/CodenameOne/pull/5387) tightened toolbar icons, spinner contrast and insets, slider thumbs, progress tracks, disabled switches, and glass-panel corners. +- [PR #5388](https://github.com/codenameone/CodenameOne/pull/5388) brought JavaSE and JavaScript glass rendering back in line with the shared model. + +The suite also found a 14-year-old iOS gradient bug. The on-screen `fillLinearGradientGlobal` path had horizontal and vertical axes reversed since 2012. The mutable-image path was correct. A controlled gradient backdrop finally made the difference attributable. + +## Most of the week was invisible backend work + +While the theme diff was easy to photograph, most of our time went into replacing the Codename One account login system. + +The new [Account Security page](https://cloud.codenameone.com/account/security) puts the controls in one place. You can now sign in with Google or GitHub, enable a time-based two-factor authentication app, register passkeys, inspect active sessions, revoke one session, or sign out every other device. A passkey can use the fingerprint, face, PIN, or other device-unlock method supported by your platform. + +This work changes no pixel in your app, but it changes how we protect build credentials, signing assets, and account data. It also removes several account responsibilities from the desktop Settings tool. Saturday's post explains that smaller tool. + +## Three smaller changes with large failure modes + +Three other PRs deserve a note because each fixes a problem that can waste hours. + +**Aligned text no longer jumps when editing starts.** [PR #5374](https://github.com/codenameone/CodenameOne/pull/5374) makes the Android inline editor and JavaSE Swing editor honor `getAbsoluteAlignment()`. A right-aligned number now stays on the right when the lightweight field hands control to the native editor. Multi-line Swing text areas remain unchanged because Swing has no per-line horizontal alignment there. + +**Local tooling failures can offer Get Help.** [PR #5383](https://github.com/codenameone/CodenameOne/pull/5383) adds `mvn cn1:get-help` after install, project creation, configuration, local run, or build submission failures. Nothing is telemetry and nothing is sent until you press Send. The report includes the failed step, command, Java and proxy environment, and a capped error trace. If you supplied an email, support can reply asynchronously. The UI does not promise round-the-clock live staffing. + +**A stale class now fails before upload.** [PR #5390](https://github.com/codenameone/CodenameOne/pull/5390) scans the staged application jar with ASM and verifies that your own package references close over classes that actually exist. The old failure appeared roughly 11,000 build-log lines later as a missing generated Objective-C header. The new failure runs on the client and tells you to run `mvn clean`. + +```text +The compiled application classes are inconsistent. + - com.example.Gone (referenced from com.example.Caller) +Run 'mvn clean' and rebuild. +``` + +## The rest of this release series + +The fidelity work could fill the week, but five other changes need their own explanations: + +- **Saturday:** {{< post-link path="/blog/standalone-codename-one-settings" text="Codename One Settings is now a standalone project tool" >}}. +- **Sunday:** {{< post-link path="/blog/widgets-live-activities-dynamic-island" text="Widgets, Live Activities, and Dynamic Island from one Java API" >}}. +- **Monday:** {{< post-link path="/blog/accessibility-semantics" text="Accessibility semantics and the parallel UI tree" >}}. +- **Tuesday:** {{< post-link path="/blog/codename-one-mcp-server" text="How that accessibility tree lets an agent drive a Codename One app over MCP" >}}. +- **Wednesday:** {{< post-link path="/blog/tested-port-support" text="A support matrix generated from current CI evidence" >}}. + +If you use the modern themes, the most useful thing you can send us is still a screenshot with a precise component, state, appearance, and device. The ratchet stops known pixels from getting worse. It does not tell us which missing screen matters most to you. + +--- + +## Discussion + +_Join the conversation via GitHub Discussions._ + +{{< giscus >}} diff --git a/docs/website/content/blog/standalone-codename-one-settings.md b/docs/website/content/blog/standalone-codename-one-settings.md new file mode 100644 index 00000000000..d1b60e3dfd1 --- /dev/null +++ b/docs/website/content/blog/standalone-codename-one-settings.md @@ -0,0 +1,101 @@ +--- +title: "Codename One Settings Is Now a Standalone Tool" +slug: standalone-codename-one-settings +url: /blog/standalone-codename-one-settings/ +date: '2026-07-18' +author: Shai Almog +description: "Codename One Settings now launches as a standalone Maven-distributed desktop tool for project identity, build hints, themes, and extensions. Accounts, signing, and build monitoring moved to the tools that own those jobs." +feed_html: '
Codename One Settings is now a focused Maven-distributed desktop tool for project identity, build hints, themes, and extensions.'
+series: ["release-2026-07-17"]
+---
+
+
+
+Codename One Settings used to be a screen inside the old GUI Builder jar. It edited project properties, managed accounts, opened signing workflows, monitored builds, installed extensions, and accumulated every job that did not have a better home.
+
+[PR #5359](https://github.com/codenameone/CodenameOne/pull/5359) replaces it with a standalone Codename One desktop application. It does fewer things, which is the point.
+
+## One command, one project
+
+Run the new tool from a Codename One Maven project:
+
+```bash
+mvn cn1:settings
+```
+
+The Maven plugin resolves the `com.codenameone:codenameone-settings` artifact, launches it against the current project, and writes changes back to that project's `codenameone_settings.properties` and Maven configuration. The tool has its own release lifecycle instead of borrowing the GUI Builder's jar and version.
+
+{{< mermaid >}}
+flowchart LR
+ A["Your Maven project"] -->|"mvn cn1:settings"| B["Codename One Maven plugin"]
+ B --> C["codenameone-settings artifact"]
+ C --> D["Basic project settings"]
+ C --> E["Build hints"]
+ C --> F["Extensions and themes"]
+ D --> G["Project files"]
+ E --> G
+ F --> G
+{{< /mermaid >}}
+
+This is the new Basic screen. It keeps the properties that belong to the source project: display name, package name, version, main class, icon, and related build choices.
+
+
+
+## Build hints are searchable project data
+
+Build hints used to feel like an untyped text file with a dialog in front of it. The new editor preserves direct key-value control, but adds descriptions, known value types, filtering, and a focused editing flow.
+
+
+
+Nothing prevents you from editing the property file by hand. The Settings tool is useful when you do not remember whether the current spelling is `ios.themeMode`, `and.themeMode`, or a platform-specific signing key. It also keeps project values visible without mixing them with account state from the cloud.
+
+For example, selecting the modern native themes still produces ordinary project settings:
+
+```properties
+nativeTheme=modern
+ios.themeMode=modern
+and.themeMode=modern
+```
+
+The file remains the source of truth. The UI is an editor, not a second configuration system.
+
+## Extensions keep compatibility warnings
+
+The Extensions screen browses the live catalog and installs or removes both Maven dependencies and legacy cn1lib packages. It also retains bundled compatibility metadata when the live catalog omits it. That matters for older entries such as Admob Fullscreen Ads, where installing an obsolete library without a warning is worse than showing stale-looking metadata.
+
+
+
+The implementation includes install and uninstall tests for both dependency models. It also handles light and dark appearance, keyboard focus, text caret behavior, native menus, the application icon, and a real desktop About dialog. The tool itself is built with Codename One, which gives us a useful test of the JavaSE desktop path every time we edit it.
+
+## What moved out
+
+The smaller scope is easier to understand:
+
+| Job | Where it lives now |
+|---|---|
+| Project name, version, package, icon | Codename One Settings |
+| Build hints and themes | Codename One Settings |
+| Extensions | Codename One Settings |
+| Apple and Android signing assets | [Certificate Wizard](/blog/standalone-certificate-wizard/) |
+| Account login and security | [Account Security](https://cloud.codenameone.com/account/security) |
+| Cloud build monitoring | Codename One website |
+
+Accounts do not belong inside a project-property editor. Certificates have enough platform rules to justify their own tool. Build monitoring belongs next to the builds. Removing those sections leaves Settings with one durable responsibility: edit the project you launched it from.
+
+## The migration cost
+
+The new editor is distributed as a separate Maven artifact and its application is built on Java 17. The release workflow now has to publish that reactor after the core release and keep its versions aligned with the Maven plugin. That is more release plumbing than embedding one more screen in `guibuilder.jar`.
+
+The payoff is separation. We can change Settings without shipping a GUI Builder update, and the GUI Builder no longer carries account, certificate, catalog, and project-editor code that it does not own.
+
+The old settings UI is gone from `cn1:settings`. If your documentation or script tells users to open the Control Center for project properties, change it to the command above. Signing instructions should point to `mvn cn1:certificatewizard` instead.
+
+Tomorrow's post covers the opposite kind of extraction. Widgets and Live Activities live outside your app's window, but one declarative Java model now updates them across iOS, Android, Windows, Linux, and the simulator.
+
+---
+
+## Discussion
+
+_Join the conversation via GitHub Discussions._
+
+{{< giscus >}}
diff --git a/docs/website/content/blog/tested-port-support.md b/docs/website/content/blog/tested-port-support.md
new file mode 100644
index 00000000000..052aefde15c
--- /dev/null
+++ b/docs/website/content/blog/tested-port-support.md
@@ -0,0 +1,99 @@
+---
+title: "Port Support You Can Trace Back to a Green Test"
+slug: tested-port-support
+url: /blog/tested-port-support/
+date: '2026-07-22'
+author: Shai Almog
+description: "The Codename One port status page maps 49 feature groups across 10 targets to current conformance reports, environment details, skip explanations, and dated CI evidence instead of a manually maintained support table."
+feed_html: '
The Codename One port status page maps 49 feature groups across 10 targets to dated CI evidence and explicit skip explanations.'
+series: ["release-2026-07-17"]
+---
+
+
+
+“Supported on iOS, Android, desktop, and web” sounds useful until you need one method on one target. Does WebSocket work on watchOS? Which Linux architectures do we build? Was the JavaScript media test green this week, or did somebody update a table six months ago and forget it?
+
+[PR #5389](https://github.com/codenameone/CodenameOne/pull/5389) turns those questions into the [Codename One Port Status page](/port-status/). It maps 49 user-facing feature groups across 10 portability targets to current conformance results, environment data, skip reasons, and the date of the run.
+
+## The table is an output, not an opinion
+
+The HelloCodenameOne suite already exercises APIs and screenshot goldens on Android, iOS, tvOS, watchOS, JavaScript, native Linux, native Windows, and Mac Catalyst. The missing part was a contract that translated thousands of test cases into a stable public vocabulary.
+
+The new conformance mapping connects registered tests and screenshots to rows such as networking, media, databases, maps, notifications, input, accessibility, and 3D. CI normalizes each port's result into the same report format. A publishing workflow writes the latest reports to a data-only branch. The website consumes those reports and renders the matrix.
+
+{{< mermaid >}}
+flowchart LR
+ A["Port CI jobs"] --> B["HelloCodenameOne tests"]
+ B --> C["Normalized conformance report"]
+ D["Feature-to-test contract"] --> E["49 public feature rows"]
+ C --> F["Data-only status branch"]
+ E --> F
+ F --> G["/port-status/"]
+ G --> H["490 target-feature cells"]
+ G --> I["Environment and run date"]
+ G --> J["Skip and scope explanations"]
+{{< /mermaid >}}
+
+The page currently renders 490 feature cells. Ten targets appear because architectures and renderer variants matter. iOS Metal and legacy OpenGL are separate evidence paths. Windows x64 and ARM64 are separate. Linux x64 and ARM64 are separate.
+
+JavaSE is deliberately excluded from the public portability matrix. It is the simulator and development runtime, not one of the deployed native targets the table is meant to prove.
+
+## A green cell has a chain of evidence
+
+Each status report records the commit, environment, registered tests, outcome, duration, and skipped cases. The website data also records the runtime used for browser and platform evidence. For example, the current browser environment file names the Chromium, Firefox, and WebKit engine versions rather than saying “modern browsers.”
+
+The contract itself is validated in CI:
+
+```bash
+python3 scripts/hellocodenameone/conformance/port_status.py validate
+python3 -m unittest -v \
+ scripts/hellocodenameone/conformance/test_port_status.py
+node scripts/website/validate_port_status.mjs
+```
+
+Validation fails if a registered conformance test or screenshot golden is orphaned from the public mapping, if the mapping points to a test that no longer exists, or if the published reports do not satisfy the schema. That makes the page part of the test system instead of a second table someone has to remember to edit.
+
+## Skipped does not always mean unsupported
+
+Some tests cannot run meaningfully on a target even when the API works. A device-only test may need hardware. A store API may require credentials. A screenshot can be irrelevant on watchOS because the phone-sized fixture is cropped before it tests the intended behavior.
+
+The status page keeps skips visible and attaches a reason. It does not silently convert every skip to “unsupported,” and it does not turn every skip into a green claim either. This distinction is important when a feature is supported but its current CI proof covers only part of the behavior.
+
+The deployment section applies the same honesty to minimum versions. It separates the declared floor from the environment CI actually ran. An iOS build may compile with an iOS 14 deployment target while hosted CI runs the current Xcode 26 simulator. The page says both. A compiled floor is evidence, but it is not the same as running on an iOS 14 device.
+
+## Benchmarks use the same application
+
+The page also carries ten common workloads through each generated application: integer and long arithmetic, transcendental math, sequential and random arrays, allocation, map churn, string building, recursion, and quicksort.
+
+```text
+3 warm-up runs
+5 measured runs
+report the minimum measured time
+verify the workload checksum
+```
+
+These are absolute per-target timings, not a claim that an ARM watch should beat a desktop CPU. Their value is trend detection and a common workload inside the actual generated port application.
+
+Binary size and memory are intentionally absent. The current artifacts mix compressed Android and web packages with unpacked Apple bundles and native executables. The ports also report different memory concepts. Publishing those numbers in one comparison row would look precise while measuring different things. They will return when a dedicated release-mode fixture packages and samples every target consistently.
+
+## What a green test cannot prove
+
+A green status means the mapped tests passed in the named environment at the recorded commit. It does not prove that no application can hit a bug. It does not extend the test to OS versions, devices, drivers, or permissions that the run did not exercise.
+
+That boundary is why the page exposes details instead of collapsing everything to a marketing checkmark. You can inspect the target environment, last run, mapped coverage, and reason for an exception. If the proof is narrower than your requirement, the page should make that visible before you commit to a platform.
+
+This also changes how we review a new API. Adding the Java class is no longer enough. A feature needs a conformance test, a mapping to a public capability, and green results on the ports we claim. If a port intentionally does not implement it, that scope must be explicit.
+
+## One place to start a platform decision
+
+Use the [Port Status page](/port-status/) when you need the current deployment floors, architecture coverage, API evidence, browser engines, or common-workload results. Then follow the linked test detail for the part your application depends on.
+
+This closes the week's series: [measured native-theme fidelity](/blog/pixel-perfect-is-a-test/), a [standalone Settings tool](/blog/standalone-codename-one-settings/), [external surfaces](/blog/widgets-live-activities-dynamic-island/), [portable accessibility semantics](/blog/accessibility-semantics/), and an [MCP server built on that semantic tree](/blog/codename-one-mcp-server/). The common thread is not the number of features. It is turning claims into artifacts you can inspect.
+
+---
+
+## Discussion
+
+_Join the conversation via GitHub Discussions._
+
+{{< giscus >}}
diff --git a/docs/website/content/blog/widgets-live-activities-dynamic-island.md b/docs/website/content/blog/widgets-live-activities-dynamic-island.md
new file mode 100644
index 00000000000..1031c2e8f48
--- /dev/null
+++ b/docs/website/content/blog/widgets-live-activities-dynamic-island.md
@@ -0,0 +1,172 @@
+---
+title: "Widgets, Live Activities, and Dynamic Island From One Java API"
+slug: widgets-live-activities-dynamic-island
+url: /blog/widgets-live-activities-dynamic-island/
+date: '2026-07-19'
+author: Shai Almog
+description: "The new com.codename1.surfaces API describes home-screen widgets, Live Activities, Dynamic Island regions, Android ongoing notifications, and desktop widgets as data that can render while the main app is not active."
+feed_html: '
One declarative Java API now targets home-screen widgets, Live Activities, Dynamic Island, Android ongoing notifications, and desktop widgets.'
+series: ["release-2026-07-17"]
+---
+
+
+
+Widget support was one of the earliest Codename One requests. We dismissed it for years because a widget must render while the application UI is not running. A normal Codename One `Component` needs the application renderer, event dispatch thread, and live object graph. A home-screen widget gets none of those.
+
+The missing piece had been under our nose for a decade. Steve added background processes so an app could refresh data without showing its UI. That solves the update side. The rendering side becomes possible once the widget is data rather than a live component.
+
+[PR #5365](https://github.com/codenameone/CodenameOne/pull/5365) turns that observation into `com.codename1.surfaces`, one API for home-screen widgets, Live Activities, Dynamic Island, Android ongoing notifications, and desktop floating widgets.
+
+## The dead-process rule
+
+An external surface is a piece of application state that the operating system can render outside the app. The app publishes a serializable layout and a timeline of state maps. The platform persists that data, then renders it with its own surface technology.
+
+You cannot attach a Java listener to a widget. There may be no Java process to invoke. You assign a string action ID instead. A tap launches the app and delivers that action after startup.
+
+{{< mermaid >}}
+flowchart LR
+ A["Codename One app or background fetch"] --> B["Surface layout + timeline state"]
+ B --> C["Canonical JSON + content-addressed PNGs"]
+ C --> D["iOS WidgetKit / ActivityKit"]
+ C --> E["Android RemoteViews / notification"]
+ C --> F["Desktop floating widget"]
+ D --> G["Tap action ID"]
+ E --> G
+ F --> G
+ G -->|"cold start if needed"| A
+{{< /mermaid >}}
+
+The simulator implements the same model. Open **Widgets > Widgets Preview** to inspect every registered kind, move through its timeline, change size and appearance, and click actions without creating a device build.
+
+
+
+## Widget kinds exist at build time
+
+iOS and Android compile widget galleries into the native application. The kinds must therefore be known during the build. Add a `surfaces.json` resource:
+
+```json
+{
+ "liveActivities": true,
+ "kinds": [
+ {
+ "id": "delivery_status",
+ "name": "Delivery",
+ "description": "Track your order",
+ "iosFamilies": ["systemSmall", "systemMedium"]
+ }
+ ]
+}
+```
+
+Mirror that declaration in `init()` so the simulator and runtime know the same kind:
+
+```java
+Surfaces.registerWidgetKind(new WidgetKind("delivery_status")
+ .setDisplayName("Delivery")
+ .setDescription("Track your order")
+ .addSupportedSize(WidgetSize.SMALL)
+ .addSupportedSize(WidgetSize.MEDIUM));
+```
+
+Referencing the surfaces package is the build gate. Apps that never use it get no WidgetKit extension, Android receiver, app group, or surface resources.
+
+## A timeline carries future state
+
+A widget publishes one layout and dated entries. Placeholders such as `${status}` resolve from each entry's state map. The operating system advances to the next entry without waking the app.
+
+```java
+long now = System.currentTimeMillis();
+long eta = now + 4 * 60000L;
+
+WidgetTimeline timeline = new WidgetTimeline()
+ .setContent(buildDeliveryLayout())
+ .addEntry(new Date(now), state("Preparing", eta, 0.1f))
+ .addEntry(new Date(now + 60000L), state("Out for delivery", eta, 0.4f))
+ .addEntry(new Date(eta), state("Delivered", eta, 1f))
+ .setReloadPolicy(WidgetTimeline.RELOAD_AT_END);
+
+Surfaces.publish("delivery_status", timeline);
+```
+
+`SurfaceDynamicText` is the useful trick here. Give it an ETA and `STYLE_TIMER_DOWN`. WidgetKit renders a timed `Text`. Android uses a `Chronometer`. The countdown changes every second with no Java wake-up.
+
+```java
+return new SurfaceColumn().setPadding(12).setSpacing(6)
+ .add(new SurfaceText("${status}")
+ .setFontSize(15)
+ .setFontWeight(SurfaceFontWeight.SEMIBOLD))
+ .add(new SurfaceDynamicText(
+ SurfaceDynamicText.STYLE_TIMER_DOWN, "eta")
+ .setFontSize(24)
+ .setColor(SurfaceColor.ACCENT))
+ .add(new SurfaceProgress(SurfaceProgress.STYLE_LINEAR)
+ .setValueState("progress"))
+ .setAction("open_order", params);
+```
+
+For longer-lived data, background fetch loads fresh state and republishes the timeline. On Android, an exhausted widget can request that fetch, throttled to once per 15 minutes per kind. iOS does not let a WidgetKit extension wake the host app whenever it wants, so iOS timelines should span the expected gap between background fetch opportunities.
+
+## Dynamic Island is another layout region
+
+A Live Activity uses the same nodes and state maps. Its descriptor adds the regions ActivityKit needs: compact leading and trailing content, minimal content, and the expanded leading, trailing, center, and bottom areas.
+
+```java
+LiveActivityDescriptor descriptor = new LiveActivityDescriptor("delivery")
+ .setContent(buildDeliveryLayout())
+ .setCompactLeading(new SurfaceImage(courierAvatar)
+ .setSize(24, 24).setCornerRadius(12))
+ .setCompactTrailing(new SurfaceDynamicText(
+ SurfaceDynamicText.STYLE_TIMER_DOWN, "eta"))
+ .setExpandedCenter(new SurfaceText("${status}"))
+ .setExpandedBottom(new SurfaceProgress(
+ SurfaceProgress.STYLE_LINEAR).setValueState("progress"));
+
+LiveActivity activity = LiveActivity.start(descriptor, initialState);
+activity.update(arrivingState);
+activity.end(deliveredState);
+```
+
+On iOS, that becomes a lock-screen Live Activity and Dynamic Island presentation. On Android, it becomes an ongoing notification. On desktop, it becomes a floating pill window.
+
+
+
+## Widgets on Linux are not a typo
+
+The same publish call reaches desktop targets. A JavaSE or native desktop build can expose kinds from a tray menu and pin them as frameless, always-on-top windows. Windows can also generate a Windows 11 Widgets Board provider when `windows.msix=true`.
+
+Linux uses GTK floating windows. Compositors with the layer-shell protocol can place them like desktop applets. GNOME Wayland does not expose that positioning contract, so it falls back to a normal floating window. Desktop widgets are process-bound in this release. They exist while the application process runs, unlike iOS and Android system widgets.
+
+The analog clock below uses `SurfaceVector`, a retained set of fill, stroke, line, arc, text, and rotation operations. Sixty timeline entries update the hand angles once per minute.
+
+
+
+## The common model has a floor
+
+The surface node catalog is deliberately smaller than the Codename One component set. Android `RemoteViews` is the constrained renderer, so it defines several compromises:
+
+| Feature | iOS | Android |
+|---|---|---|
+| Layout rows and columns | SwiftUI stacks | LinearLayout |
+| Countdown | Native timed Text | Chronometer |
+| Circular progress | Gauge | Linear fallback |
+| Relative date | Native update | Static until refresh |
+| Vector drawing | SwiftUI Canvas | Rasterized bitmap |
+| Small widget actions | Root action only | Per-node actions |
+
+Descriptors stop at eight nesting levels. JSON and image payloads should stay comfortably below 200KB. Android eventually has to send a rendered widget through a 1MB binder transaction, while the iOS extension runs with a small memory budget.
+
+The PR verified serialization, timeline ordering, image deduplication, live-activity lifecycle, cold-start action queues, and generated Swift compilation. The simulator sample ran end to end. The PR did not claim on-device verification for every platform path, and the Windows MSIX plus native Linux window paths could not be executed on the author's Mac. Those are real gaps to keep in mind for the first release.
+
+
+
+Push-driven widget updates are not in this version. The app publishes timelines, background fetch republishes them, and live activities accept app-driven updates. Server-pushed state and ActivityKit push tokens are planned on top of the same wire format.
+
+Tomorrow's post covers the parallel tree that makes lightweight Codename One components visible to VoiceOver, TalkBack, UI Automation, AT-SPI, ARIA, and, unexpectedly, AI agents.
+
+---
+
+## Discussion
+
+_Join the conversation via GitHub Discussions._
+
+{{< giscus >}}
diff --git a/docs/website/social/linkedin/2026-07-27-0300-shai-pixel-perfect-is-a-test.md b/docs/website/social/linkedin/2026-07-27-0300-shai-pixel-perfect-is-a-test.md
new file mode 100644
index 00000000000..91dcebd7d4b
--- /dev/null
+++ b/docs/website/social/linkedin/2026-07-27-0300-shai-pixel-perfect-is-a-test.md
@@ -0,0 +1,22 @@
+---
+title: "Shai: pixel perfect needs a test"
+slug: 2026-07-27-0300-shai-pixel-perfect-is-a-test
+platform: linkedin
+account: shai
+source_slug: pixel-perfect-is-a-test
+publish_at: '2026-07-27T03:00:00'
+timezone: Asia/Jerusalem
+review_by: '2026-07-24'
+status: draft
+image: /blog/pixel-perfect-is-a-test.jpg
+---
+
+We do not use UIKit or Material widgets for the Codename One UI. We paint the UI ourselves.
+
+That gives us control over every pixel. It also means “pixel perfect” cannot be a slogan.
+
+This week we built native iOS and Android reference apps, captured real controls, and made CI compare our themes against them. Pixels, geometry, and fixed animation frames all get separate checks. A one-way gate stops a known result from quietly getting worse.
+
+The current iOS tab bar still has the lowest score. Full-app visual review is still missing from the automated layer. I would rather publish those limits than hide them behind a 95% median.
+
+Full write-up: {{canonical}}
diff --git a/docs/website/social/linkedin/2026-07-27-1200-codenameone-standalone-codename-one-settings.md b/docs/website/social/linkedin/2026-07-27-1200-codenameone-standalone-codename-one-settings.md
new file mode 100644
index 00000000000..479b1cb693e
--- /dev/null
+++ b/docs/website/social/linkedin/2026-07-27-1200-codenameone-standalone-codename-one-settings.md
@@ -0,0 +1,20 @@
+---
+title: "Codename One: standalone Settings tool"
+slug: 2026-07-27-1200-codenameone-standalone-codename-one-settings
+platform: linkedin
+account: codenameone
+source_slug: standalone-codename-one-settings
+publish_at: '2026-07-27T12:00:00'
+timezone: Asia/Jerusalem
+review_by: '2026-07-24'
+status: draft
+image: /blog/standalone-codename-one-settings.jpg
+---
+
+`mvn cn1:settings` now launches a standalone Codename One desktop tool.
+
+It edits the current project's identity, build hints, themes, and extensions. Account security moved to the website. Signing moved to the Certificate Wizard. Build monitoring stays with the cloud build console.
+
+The property files remain the source of truth. The application is a focused editor for them, distributed as its own Maven artifact instead of a screen embedded in the old GUI Builder jar.
+
+Full write-up: {{canonical}}
diff --git a/docs/website/social/linkedin/2026-07-28-0300-codenameone-pixel-perfect-is-a-test.md b/docs/website/social/linkedin/2026-07-28-0300-codenameone-pixel-perfect-is-a-test.md
new file mode 100644
index 00000000000..d813ca14c55
--- /dev/null
+++ b/docs/website/social/linkedin/2026-07-28-0300-codenameone-pixel-perfect-is-a-test.md
@@ -0,0 +1,20 @@
+---
+title: "Codename One: native fidelity ratchet"
+slug: 2026-07-28-0300-codenameone-pixel-perfect-is-a-test
+platform: linkedin
+account: codenameone
+source_slug: pixel-perfect-is-a-test
+publish_at: '2026-07-28T03:00:00'
+timezone: Asia/Jerusalem
+review_by: '2026-07-24'
+status: draft
+image: /blog/pixel-perfect-is-a-test.jpg
+---
+
+Codename One now tests its iOS 26 Liquid Glass and Android Material 3 themes against native reference applications.
+
+The current baselines contain 68 iOS pairs and 54 Android pairs across light, dark, normal, pressed, selected, and disabled states. CI reports visual similarity and geometry separately. Tab and switch animations are frozen at fixed progress points so motion regressions cannot hide between the first and last frame.
+
+The gate only moves one way. A theme change can improve a recorded result or fail the build. It cannot silently lower the baseline.
+
+Full write-up: {{canonical}}
diff --git a/docs/website/social/linkedin/2026-07-28-1200-shai-standalone-codename-one-settings.md b/docs/website/social/linkedin/2026-07-28-1200-shai-standalone-codename-one-settings.md
new file mode 100644
index 00000000000..d61cc703650
--- /dev/null
+++ b/docs/website/social/linkedin/2026-07-28-1200-shai-standalone-codename-one-settings.md
@@ -0,0 +1,20 @@
+---
+title: "Shai: why Settings got smaller"
+slug: 2026-07-28-1200-shai-standalone-codename-one-settings
+platform: linkedin
+account: shai
+source_slug: standalone-codename-one-settings
+publish_at: '2026-07-28T12:00:00'
+timezone: Asia/Jerusalem
+review_by: '2026-07-24'
+status: draft
+image: /blog/standalone-codename-one-settings.jpg
+---
+
+Codename One Settings had become the place where unrelated jobs accumulated.
+
+Project properties, account login, certificates, build monitoring, and extensions all lived in one old GUI Builder jar. The rewrite is smaller on purpose.
+
+The standalone tool owns project configuration. The Certificate Wizard owns signing. The website owns accounts and cloud builds. That costs us another Maven artifact and another release step, but each tool now has a boundary we can explain in one sentence.
+
+Full write-up: {{canonical}}
diff --git a/docs/website/social/linkedin/2026-07-29-0300-shai-widgets-live-activities-dynamic-island.md b/docs/website/social/linkedin/2026-07-29-0300-shai-widgets-live-activities-dynamic-island.md
new file mode 100644
index 00000000000..8392f28369e
--- /dev/null
+++ b/docs/website/social/linkedin/2026-07-29-0300-shai-widgets-live-activities-dynamic-island.md
@@ -0,0 +1,22 @@
+---
+title: "Shai: the widget request we called impossible"
+slug: 2026-07-29-0300-shai-widgets-live-activities-dynamic-island
+platform: linkedin
+account: shai
+source_slug: widgets-live-activities-dynamic-island
+publish_at: '2026-07-29T03:00:00'
+timezone: Asia/Jerusalem
+review_by: '2026-07-24'
+status: draft
+image: /blog/widgets-live-activities-dynamic-island.jpg
+---
+
+We dismissed widget support as impossible for years.
+
+A home-screen widget has to render when the Codename One UI is not running. The answer was to stop treating it as UI. The app publishes a serializable layout plus dated state. WidgetKit, RemoteViews, or the desktop renderer owns the pixels after that.
+
+Steve's decade-old background-process work supplies fresh data. Timelines carry future updates without waking the app. The same model turned out to fit Live Activities and Dynamic Island too.
+
+The first version has real limits, especially around Android RemoteViews and desktop process lifetime. The model finally fits the operating systems instead of fighting them.
+
+Full write-up: {{canonical}}
diff --git a/docs/website/social/linkedin/2026-07-29-1200-codenameone-accessibility-semantics.md b/docs/website/social/linkedin/2026-07-29-1200-codenameone-accessibility-semantics.md
new file mode 100644
index 00000000000..f1a83eb71cf
--- /dev/null
+++ b/docs/website/social/linkedin/2026-07-29-1200-codenameone-accessibility-semantics.md
@@ -0,0 +1,20 @@
+---
+title: "Codename One: portable accessibility semantics"
+slug: 2026-07-29-1200-codenameone-accessibility-semantics
+platform: linkedin
+account: codenameone
+source_slug: accessibility-semantics
+publish_at: '2026-07-29T12:00:00'
+timezone: Asia/Jerusalem
+review_by: '2026-07-24'
+status: draft
+image: /blog/accessibility-semantics.jpg
+---
+
+Codename One lightweight components now expose a portable accessibility semantics tree.
+
+Standard controls infer roles, states, values, ranges, and actions. Custom renderers can publish virtual children. The same immutable tree maps to VoiceOver, TalkBack, Windows UI Automation, Linux AT-SPI, Java accessibility, and an off-screen ARIA DOM on the web.
+
+The simulator inspector audits unlabeled actions, invalid ranges, duplicate identifiers, and traversal cycles. Tests can snapshot the tree as JSON and assert the behavior users depend on.
+
+Full write-up: {{canonical}}
diff --git a/docs/website/social/linkedin/2026-07-30-0300-codenameone-widgets-live-activities-dynamic-island.md b/docs/website/social/linkedin/2026-07-30-0300-codenameone-widgets-live-activities-dynamic-island.md
new file mode 100644
index 00000000000..0301afcc32e
--- /dev/null
+++ b/docs/website/social/linkedin/2026-07-30-0300-codenameone-widgets-live-activities-dynamic-island.md
@@ -0,0 +1,20 @@
+---
+title: "Codename One: one API for external surfaces"
+slug: 2026-07-30-0300-codenameone-widgets-live-activities-dynamic-island
+platform: linkedin
+account: codenameone
+source_slug: widgets-live-activities-dynamic-island
+publish_at: '2026-07-30T03:00:00'
+timezone: Asia/Jerusalem
+review_by: '2026-07-24'
+status: draft
+image: /blog/widgets-live-activities-dynamic-island.jpg
+---
+
+`com.codename1.surfaces` is one declarative Java API for home-screen widgets, Live Activities, Dynamic Island, Android ongoing notifications, and desktop floating widgets.
+
+Layouts serialize to JSON. Images use content-addressed PNG blobs. Dated timeline entries update placeholders without changing the layout. A native countdown ticks through WidgetKit or Android Chronometer without waking the application every second.
+
+The simulator includes a widget and Dynamic Island preview, so layout, timeline, dark mode, size, and action routing can be tested on the desktop.
+
+Full write-up: {{canonical}}
diff --git a/docs/website/social/linkedin/2026-07-30-1200-shai-accessibility-semantics.md b/docs/website/social/linkedin/2026-07-30-1200-shai-accessibility-semantics.md
new file mode 100644
index 00000000000..d10eea02cf0
--- /dev/null
+++ b/docs/website/social/linkedin/2026-07-30-1200-shai-accessibility-semantics.md
@@ -0,0 +1,20 @@
+---
+title: "Shai: accessibility became personal"
+slug: 2026-07-30-1200-shai-accessibility-semantics
+platform: linkedin
+account: shai
+source_slug: accessibility-semantics
+publish_at: '2026-07-30T12:00:00'
+timezone: Asia/Jerusalem
+review_by: '2026-07-24'
+status: draft
+image: /blog/accessibility-semantics.jpg
+---
+
+Accessibility has become personal for me. I am getting older, and large type is how I read a phone comfortably now.
+
+I also remember working with accessibility experts at Sun and seeing the real complexity. A label is easy. Roles, actions, virtual children, collection position, focus recovery, live announcements, and platform behavior are not.
+
+Our old `setAccessibilityText()` API was the poor man's version. The new semantics tree is a parallel, testable hierarchy with mappings for every current Codename One UI port. Automated audits help, but the final pass still belongs to a person using the actual screen reader.
+
+Full write-up: {{canonical}}
diff --git a/docs/website/social/linkedin/2026-07-31-0300-shai-codename-one-mcp-server.md b/docs/website/social/linkedin/2026-07-31-0300-shai-codename-one-mcp-server.md
new file mode 100644
index 00000000000..fbafe8b5e1b
--- /dev/null
+++ b/docs/website/social/linkedin/2026-07-31-0300-shai-codename-one-mcp-server.md
@@ -0,0 +1,22 @@
+---
+title: "Shai: accessibility led to MCP"
+slug: 2026-07-31-0300-shai-codename-one-mcp-server
+platform: linkedin
+account: shai
+source_slug: codename-one-mcp-server
+publish_at: '2026-07-31T03:00:00'
+timezone: Asia/Jerusalem
+review_by: '2026-07-24'
+status: draft
+image: /blog/codename-one-mcp-server.jpg
+---
+
+Accessibility led to something I did not expect.
+
+Once a Codename One screen had an immutable tree of roles, labels, values, and actions, an agent could read that tree too. The JavaSE port can now expose the running simulator or a desktop tool as an MCP server.
+
+The agent finds `profile-save` and invokes its activate action. It does not guess yesterday's screen coordinates. Application tools can expose domain operations directly, and a PNG resource remains available when the issue is genuinely visual.
+
+This is JavaSE-only today. Native desktop packages and mobile targets still need transport and launcher work.
+
+Full write-up: {{canonical}}
diff --git a/docs/website/social/linkedin/2026-07-31-1200-codenameone-tested-port-support.md b/docs/website/social/linkedin/2026-07-31-1200-codenameone-tested-port-support.md
new file mode 100644
index 00000000000..195c5f7767a
--- /dev/null
+++ b/docs/website/social/linkedin/2026-07-31-1200-codenameone-tested-port-support.md
@@ -0,0 +1,20 @@
+---
+title: "Codename One: port status from CI evidence"
+slug: 2026-07-31-1200-codenameone-tested-port-support
+platform: linkedin
+account: codenameone
+source_slug: tested-port-support
+publish_at: '2026-07-31T12:00:00'
+timezone: Asia/Jerusalem
+review_by: '2026-07-24'
+status: draft
+image: /blog/tested-port-support.jpg
+---
+
+The new Codename One Port Status page maps 49 feature groups across 10 targets to current CI reports.
+
+Each result carries a commit, environment, run date, mapped tests, and skip explanations. Architecture and renderer variants remain separate, including iOS Metal versus OpenGL and Windows or Linux x64 versus ARM64.
+
+A green cell means the named tests passed in the named environment. It does not claim every OS version and device was exercised. The page keeps that boundary visible.
+
+Full write-up: {{canonical}}
diff --git a/docs/website/social/linkedin/2026-08-01-0300-codenameone-codename-one-mcp-server.md b/docs/website/social/linkedin/2026-08-01-0300-codenameone-codename-one-mcp-server.md
new file mode 100644
index 00000000000..6c7192f0d5f
--- /dev/null
+++ b/docs/website/social/linkedin/2026-08-01-0300-codenameone-codename-one-mcp-server.md
@@ -0,0 +1,20 @@
+---
+title: "Codename One: semantic UI tools over MCP"
+slug: 2026-08-01-0300-codenameone-codename-one-mcp-server
+platform: linkedin
+account: codenameone
+source_slug: codename-one-mcp-server
+publish_at: '2026-08-01T03:00:00'
+timezone: Asia/Jerusalem
+review_by: '2026-07-24'
+status: draft
+image: /blog/codename-one-mcp-server.jpg
+---
+
+A running Codename One simulator can now expose its UI to MCP hosts such as Codex, Claude Code, Claude Desktop, and opencode.
+
+Built-in tools return the semantic UI snapshot, find nodes, set text, and perform actions on the Codename One EDT. Applications can add typed domain tools through the existing `com.codename1.ai.Tool` contract.
+
+Socket mode attaches to a visible running tool. A small stdio bridge lets local MCP hosts connect to that same process. Nothing is exposed until the API or MCP menu starts the server.
+
+Full write-up: {{canonical}}
diff --git a/docs/website/social/linkedin/2026-08-01-1200-shai-tested-port-support.md b/docs/website/social/linkedin/2026-08-01-1200-shai-tested-port-support.md
new file mode 100644
index 00000000000..90a78c22b92
--- /dev/null
+++ b/docs/website/social/linkedin/2026-08-01-1200-shai-tested-port-support.md
@@ -0,0 +1,20 @@
+---
+title: "Shai: why the support table has missing metrics"
+slug: 2026-08-01-1200-shai-tested-port-support
+platform: linkedin
+account: shai
+source_slug: tested-port-support
+publish_at: '2026-08-01T12:00:00'
+timezone: Asia/Jerusalem
+review_by: '2026-07-24'
+status: draft
+image: /blog/tested-port-support.jpg
+---
+
+Our new port status page deliberately omits binary size and memory.
+
+Android and web report compressed packages. Apple reports an unpacked app bundle. Linux and Windows report executables. The ports also expose different memory concepts. Putting those values in one table would look scientific while comparing different things.
+
+So the first version publishes what CI can prove honestly: 49 feature groups, 10 targets, exact test results, run environments, dates, and skip reasons. The missing metrics will return after we build a dedicated release fixture that packages and samples every target the same way.
+
+Full write-up: {{canonical}}
diff --git a/docs/website/static/blog/accessibility-semantics.jpg b/docs/website/static/blog/accessibility-semantics.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..ffefd8df9722c98b51c14cc4eb525b6770b6ceb2
GIT binary patch
literal 50713
zcmeFY2Ut_vx-L8c6$KRwph$@dQbm;BqqqP8DN?0IMfw7y_XI)d80pfbiGUF49i)Tw
z-U+>z&_W;~`KRu^*7Bac_I>WTe>?y4p8