{
  "id": 6949594,
  "title": "A Dialog Can Now Be a Native Desktop Window",
  "url": "https://urgent.news/2026/09/12/a-dialog-can-now-be-a-native-desktop-window",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-12T16:17:44.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/codenameone/a-dialog-can-now-be-a-native-desktop-window-1jgk"
  },
  "original_language": "en",
  "account": "A new release of the Codename One framework allows dialogs to become native desktop windows. Previously, showing a dialog inside an inspector could cause it to appear on the wrong surface. The bug exposed a confusion between \"top level\" and \"form\". PR #5624 resolves this by making dialogs capable of becoming real desktop windows.\n\nTwo main types of dialogs remain: lightweight dialogs that paint inside their owner's layered pane and native desktop windows. To enable a dialog to be a native window, use Dialog.setDefaultNativeWindowMode(true);. This allows confirmation dialogs to function as native windows while preserving the existing static API.\n\nCode that creates dialogs without a source component can explicitly bind them to a specific window using the setTopLevelHost() method. This ensures the dialog correctly participates in desktop window ordering, focus, and task switching.\n\nThe change in native-window mode is useful when a dialog must interact with desktop window ordering, focus, or task switching. However, it's not suitable for small prompts that should inherit the exact visual treatment of their owner. In such cases, lightweight mode is preferred.\n\nDialogs, sheets, toast bars, combo boxes, floating action buttons, infinite progress indicators, tooltips, and HTML components all had paths that queried the Display for the current Form. Those paths have been corrected to bind to the component causing the action, ensuring proper handling of accessibility state and not turning popups into unexpected windows.\n\nA limitation of the native-window mode is that popups cannot become independent desktop windows, as this would break positioning and keyboard behavior. The new mode is limited to dialogs and interaction dialogs.\n\nThe transition between windows is not possible due to the lack of shared graphics context. Instead, changes to content within a window should be handled using setContent() with appropriate transitions.\n\nThe same contract applies across Windows and Mac platforms. The test suite verifies this consistency by opening controls in various window sizes and modal cases. This ensures that desktop work remains secure and visually consistent across ports.",
  "summary": "Last week's native-window release could open an editor, inspector, and tool palette as separate operating-system windows. Then an ordinary Dialog.show() inside the inspector looked for the current Form and appeared on the wrong surface. What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase.…",
  "key_points": [
    "Dialogs can now function as native desktop windows in Codename One framework.",
    "Dialog.setDefaultNativeWindowMode(true) enables dialog to be a native window.",
    "Transition handling and accessibility state preserved across Windows and Mac platforms."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}