Feedback
Two ways to tell the user something. A toast slides a short message over the content and gets out of the way on its own, so use it when nothing needs to happen next. A dialog puts a modal surface in front of the window and waits for an answer, so use it when something does. This page also covers the two dialogs every app is expected to have: About and Preferences.
Each block below is a stack of windows. The first one RUNS the widget: the preview
is the live browser port, so it follows the light and dark toggle the way a real
window would, and the HTML tab beside it holds the very markup that paints it —
one import '@gjsify/adwaita-web' registers every element in it. Then comes
one window per kind of implementation — Native TypeScript, the @girs program
that runs unchanged on GJS, Node, Bun and Deno, with the matching Blueprint
declaration beside it, UI frameworks, the same widget written in Solid, Vue and
React through @gjsify/gtk-host — or, where the widget is built imperatively rather
than declared, the recorded reason it has no such snippet — and NativeScript,
the port that runs on a phone. That last window splits the way the first one does. An
XML template holds the tree, and the TypeScript beside it is the loader.
Libadwaita is the reference here, typed by
@girs/adw-1.
@gjsify/adwaita-web
and @gjsify/adwaita-nativescript
follow its naming, and where one of them differs, its own window says so.
A short line of text, optionally with one action button, that floats over the content for a few seconds and then dismisses itself. You do not add a toast to your layout: you wrap the page in a toast overlay and hand it toasts at runtime. The overlay layers them above the bottom edge without displacing anything beneath.
The overlay shows one toast at a time. Add a second while the first is visible and it waits its turn, appearing once the visible one goes away, whether by its timeout, its close button, its action button or an explicit dismissal. Every port behaves the same way here, so a queue you tested in the browser holds on the desktop.
Alert Dialog
Section titled “Alert Dialog”Ask a question the user has to answer: a bold heading, some body text and a row of responses to choose between. Each response is a button with a string ID, and that ID is what reaches your code. Give one response a destructive or suggested appearance to mark the consequence, and set the default and close responses so Enter and Escape do the right thing.
About Dialog
Section titled “About Dialog”Wire this to the About entry in your primary menu and you are done. Fill in the app metadata and the dialog builds the rest: a large icon, the application name, a developer line, a version pill, and Details, Credits and Legal sub-pages you never lay out yourself.
Preferences Dialog
Section titled “Preferences Dialog”The container behind your Preferences command. Organise it into pages, each holding groups of boxed-list rows: switches, drop-downs, spin buttons. Most apps need only one page, which is what the example shows. In a native window, extra pages sit behind a view switcher and you see one at a time; the web port renders them stacked instead.
Related
Section titled “Related”- Boxed Lists: the rows a preferences dialog is built from.
- Presentation: banners and status pages, for messages that do not interrupt.
- Layout: the header bars and toolbar views these overlays sit above.
- Adwaita Storybook: the same widgets in a live component browser you can poke at.