Adwaita vs Breeze
アドワイタ / ブリーズ
Both sit in Platform Screen Languages, so the question is not what they belong to but how they behave. They are reached for with some of the same intent, which is where they get confused.
Adwaita
Adwaita is the name GNOME gives its default visual style, defined in the project's Human Interface Guidelines. One set of components has to carry a light style, a dark style and a high contrast style, so colour arrives as named variables that switch rather than as fixed values. A header bar crosses the top of every window holding buttons drawn with no background and no border, and interface icons are monochrome symbolics built on a 16 by 16 pixel grid.
Breeze
The default visual style KDE introduced with Plasma 5, described in its own announcement as a high contrast, flat theme for the workspace. Graphics assets are simpler and more monochromatic, and layouts lean on typography rather than ornament so elements stay recognisable. Light and dark variants shipped as a matched pair from the beginning.
| Adwaita | Breeze | |
|---|---|---|
| Era | 2011– | 2014– |
| Family | Platform Screen Languages | Platform Screen Languages |
| Kind | Style | Style |
| Cues | A single header bar across the top of the window, laid out on three alignment points with the window heading in the centre / Header bar buttons carry no background and no border, leaving only the symbol and the label on the surface / Monochrome symbolic icons drawn at 16 by 16 pixels with 2 pixel strokes and no perspective / A published palette of five steps per hue, including Blue 3 at #3584e4 | Flat surfaces with no modelled shading, where edges are carried by contrast alone / Icons and graphic assets reduced toward monochrome, with a tight colour count / Type contrast doing the work ornament would otherwise do, so layout reads through text / The same assets existing as a matched light and dark pair |
| Best used for | Building a Linux desktop app that has to hold the same structure in both the light and the dark setting · Adding a custom widget by riding on the existing style classes and colour variables instead of hard coding values | Making a Linux desktop application sit naturally inside the default workspace appearance · Setting the look of an admin interface that has to ship light and dark as a matched pair from day one |
| Type | Identify a control with either an icon or a label, not both. The exceptions are sidebar rows and view switchers. | Let type carry the hierarchy. Open a wide gap in size and weight between heading and body, and never separate them with ornament. |
| Composition | Put a header bar at the top, main actions at the start, the heading in the middle, menus at the end. Always leave blank area so the bar can be dragged. Group buttons with spacing rather than by linking them. | Divide regions with space and thin rules rather than stacked frames or shadows. Keep the arrangement plain so visual clutter drops. |
| Material | Take colour from the published palette and hold it as variables that swap for light, dark and high contrast. Draw icons as monochrome SVG and recolour them programmatically. | Build on flat fields with no shading or gloss and hold the palette near monochrome. Push contrast hard, then derive light and dark from the same assets. |
| Caution | Hard coded colour values only break once someone switches to the dark or high contrast style, which is exactly the state the author never looks at. | Softening the contrast breaks the premise, because a flat surface has nothing but contrast left to separate one element from the next. |