{"diffoscope-json-version": 1, "source1": "/srv/reproducible-results/rbuild-debian/r-b-build.SZIbzgJs/b1/blueprint-compiler_0.16.0-1_amd64.changes", "source2": "/srv/reproducible-results/rbuild-debian/r-b-build.SZIbzgJs/b2/blueprint-compiler_0.16.0-1_amd64.changes", "unified_diff": null, "details": [{"source1": "Files", "source2": "Files", "unified_diff": "@@ -1,2 +1,2 @@\n \n- fa01d70905de73ad1174e4ab75e7f01e 69724 gnome optional blueprint-compiler_0.16.0-1_all.deb\n+ 844dc90f7c5245c6c79e8080a61ee33f 69716 gnome optional blueprint-compiler_0.16.0-1_all.deb\n"}, {"source1": "blueprint-compiler_0.16.0-1_all.deb", "source2": "blueprint-compiler_0.16.0-1_all.deb", "unified_diff": null, "details": [{"source1": "file list", "source2": "file list", "unified_diff": "@@ -1,3 +1,3 @@\n -rw-r--r-- 0 0 0 4 2025-01-22 20:21:28.000000 debian-binary\n -rw-r--r-- 0 0 0 2752 2025-01-22 20:21:28.000000 control.tar.xz\n--rw-r--r-- 0 0 0 66780 2025-01-22 20:21:28.000000 data.tar.xz\n+-rw-r--r-- 0 0 0 66772 2025-01-22 20:21:28.000000 data.tar.xz\n"}, {"source1": "control.tar.xz", "source2": "control.tar.xz", "unified_diff": null, "details": [{"source1": "control.tar", "source2": "control.tar", "unified_diff": null, "details": [{"source1": "./md5sums", "source2": "./md5sums", "unified_diff": null, "details": [{"source1": "./md5sums", "source2": "./md5sums", "comments": ["Files differ"], "unified_diff": null}]}]}]}, {"source1": "data.tar.xz", "source2": "data.tar.xz", "unified_diff": null, "details": [{"source1": "data.tar", "source2": "data.tar", "unified_diff": null, "details": [{"source1": "./usr/lib/python3/dist-packages/blueprintcompiler/reference_docs.json", "source2": "./usr/lib/python3/dist-packages/blueprintcompiler/reference_docs.json", "unified_diff": null, "details": [{"source1": "Pretty-printed", "source2": "Pretty-printed", "comments": ["Ordering differences only"], "unified_diff": "@@ -1,71 +1,27 @@\n {\n- \"Syntax Menu\": {\n- \"content\": \"\\n## Menus\\n\\n```text\\nMenu = 'menu' ? '{' MenuChild* '}'\\nMenuChild = ( MenuSection | MenuSubmenu | MenuItemShorthand | MenuItem )\\nMenuSection = 'section' ? '{' ( MenuChild | MenuAttribute )* '}'\\nMenuSubmenu = 'submenu' ? '{' ( MenuChild | MenuAttribute )* '}'\\nMenuItem = 'item' '{' MenuAttribute* '}'\\nMenuAttribute = ':' StringValue ';'\\n```\\n\\nMenus, such as the application menu, are defined using the `menu` keyword. Menus have the type [Gio.MenuModel](https://docs.gtk.org/gio/class.MenuModel.html) and can be referenced by ID. They cannot be defined inline.\\n\\n### Example\\n\\n```blueprint\\nmenu my_menu {\\n submenu {\\n label: _(\\\"File\\\");\\n item {\\n label: _(\\\"New\\\");\\n action: \\\"app.new\\\";\\n icon: \\\"document-new-symbolic\\\";\\n }\\n }\\n}\\n\\nMenuButton {\\n menu-model: my_menu;\\n}\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/menus.html#syntax-menu\"\n- },\n- \"Syntax MenuItemShorthand\": {\n- \"content\": \"\\n## Item Shorthand\\n\\n```text\\nMenuItemShorthand = 'item' '(' StringValue ( ',' ( StringValue ( ',' StringValue? )? )? )? ')'\\n```\\n\\nThe most common menu attributes are `label`, `action`, and `icon`. Because they're so common, Blueprint provides a shorter syntax for menu items with just these properties.\\n\\n### Example\\n\\n```blueprint\\nmenu {\\n item (\\\"label\\\")\\n item (\\\"label\\\", \\\"action\\\")\\n item (\\\"label\\\", \\\"action\\\", \\\"icon\\\")\\n}\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/menus.html#syntax-menuitemshorthand\"\n- },\n- \"Syntax Root\": {\n- \"content\": \"\\n## Document Root\\n\\n```text\\nRoot = GtkDecl (Using)* (TranslationDomain)? ( Template | Menu | Object )* EOF\\n```\\n\\nA blueprint document consists of a [GTK declaration](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/document_root.html#syntax-gtkdecl), one or more [imports](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/document_root.html#syntax-using), and a list of [objects](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/objects.html#syntax-object) and/or a [template](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/templates.html#syntax-template).\\n\\n### Example\\n\\n```blueprint\\n// Gtk Declaration\\nusing Gtk 4.0;\\n\\n// Import Statement\\nusing Adw 1;\\n\\n// Object\\nWindow my_window {}\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/document_root.html#syntax-root\"\n- },\n- \"Syntax GtkDecl\": {\n- \"content\": \"\\n## GTK Declaration\\n\\n```text\\nGtkDecl = 'using' 'Gtk' '4.0' ';'\\n```\\n\\nEvery blueprint file begins with the line `using Gtk 4.0;`, which declares the target GTK version for the file. Tools that read blueprint files should verify that they support the declared version.\\n\\n### Example\\n\\n```blueprint\\nusing Gtk 4.0;\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/document_root.html#syntax-gtkdecl\"\n- },\n- \"Syntax Using\": {\n- \"content\": \"\\n## GObject Introspection Imports\\n\\n```text\\nUsing = 'using' ';'\\n```\\n\\nTo use classes and types from namespaces other than GTK itself, those namespaces must be imported at the top of the file. This tells the compiler what version of the namespace to import.\\n\\nYou'll need the GIR name and version, not the package name and not the exact version number. These are listed at the top of each library's documentation homepage:\\n\\n![gir-namespace.png](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/_images/gir-namespace.png)\\n\\nThe compiler requires typelib files for these libraries to be installed. They are usually installed with the library, but on some distros, you may need to install the package that provides `{namespace}-{version}.typelib` (e.g. `Adw-1.typelib`).\\n\\n### Example\\n\\n```blueprint\\n// Import libadwaita\\nusing Adw 1;\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/document_root.html#syntax-using\"\n- },\n- \"Syntax TranslationDomain\": {\n- \"content\": \"\\n## Translation Domain\\n\\n```text\\nTranslationDomain = 'translation-domain' ';'\\n```\\n\\nThe translation domain is used to look up translations for translatable strings in the blueprint file. If no translation domain is specified, strings will be looked up in the program's global domain.\\n\\nSee [Gtk.Builder:translation-domain](https://docs.gtk.org/gtk4/property.Builder.translation-domain.html) for more information.\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/document_root.html#syntax-translationdomain\"\n- },\n- \"Syntax Value\": {\n- \"content\": \"\\n## Values\\n\\n```text\\nValue = Translated | Flags | Literal\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/values.html#syntax-value\"\n- },\n- \"Syntax Literal\": {\n- \"content\": \"\\n## Literals\\n\\n```text\\nLiteral = TypeLiteral | QuotedLiteral | NumberLiteral | IdentLiteral\\nQuotedLiteral = \\nNumberLiteral = ( '-' | '+' )? \\nIdentLiteral = \\n```\\n\\nLiterals are used to specify values for properties. They can be strings, numbers, references to objects, `null`, types, boolean values, or enum members.\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/values.html#syntax-literal\"\n- },\n- \"Syntax TypeLiteral\": {\n- \"content\": \"\\n## Type Literals\\n\\n```text\\nTypeLiteral = 'typeof' '<' TypeName '>'\\n```\\n\\nSometimes, you need to specify a type as a value. For example, when creating a list store, you may need to specify the type of the items in the list store. This is done using a `typeof<>` literal.\\n\\nThe type of a `typeof<>` literal is [GType](https://docs.gtk.org/gobject/alias.Type.html), GObject's \\\"meta-type\\\" for type information.\\n\\n\\n### Example\\n\\n```blueprint\\nGio.ListStore {\\n item-type: typeof;\\n}\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/values.html#syntax-typeliteral\"\n- },\n- \"Syntax Flags\": {\n- \"content\": \"\\n## Flags\\n\\n```text\\nFlags = '|' ( )|+\\n```\\n\\nFlags are used to specify a set of options. One or more of the available flag values may be specified, and they are combined using `|`.\\n\\n### Example\\n\\n```blueprint\\nAdw.TabView {\\n shortcuts: control_tab | control_shift_tab;\\n}\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/values.html#syntax-flags\"\n- },\n- \"Syntax Translated\": {\n- \"content\": \"\\n## Translated Strings\\n\\n```text\\nTranslated = ( '_' '(' ')' ) | ( '\\\\C_' '(' ',' ')' )\\n```\\n\\nUse `_(\\\"...\\\")` to mark strings as translatable. You can put a comment for translators on the line above if needed.\\n\\n```blueprint\\nGtk.Label label {\\n /* Translators: This is the main text of the welcome screen */\\n label: _(\\\"Hello, world!\\\");\\n}\\n```\\n\\nUse `C_(\\\"context\\\", \\\"...\\\")` to add a *message context* to a string to disambiguate it, in case the same string appears in different places. Remember, two strings might be the same in one language but different in another depending on context.\\n\\n```blueprint\\nGtk.Label label {\\n /* Translators: This is a section in the preferences window */\\n label: C_(\\\"preferences window\\\", \\\"Hello, world!\\\");\\n}\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/values.html#syntax-translated\"\n- },\n- \"Syntax Binding\": {\n- \"content\": \"\\n## Bindings\\n\\n```text\\nBinding = 'bind' Expression (BindingFlag)*\\nBindingFlag = 'inverted' | 'bidirectional' | 'no-sync-create'\\n```\\n\\nBindings keep a property updated as other properties change. They can be used to keep the UI in sync with application data, or to connect two parts of the UI.\\n\\nThe simplest bindings connect to a property of another object in the blueprint. When that other property changes, the bound property updates as well. More advanced bindings can do multi-step property lookups and can even call application code to compute values. See [the expressions page](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/expressions.html#syntax-expression).\\n\\n### Simple Bindings\\n\\nA binding that consists of a source object and a single lookup is called a \\\"simple binding\\\". These are implemented using [GObject property bindings](https://docs.gtk.org/gobject/method.Object.bind_property.html) and support a few flags:\\n\\n- `inverted`: For boolean properties, the target is set to the inverse of the source property.\\n- `bidirectional`: The binding is two-way, so changes to the target property will also update the source property.\\n- `no-sync-create`: Normally, when a binding is created, the target property is immediately updated with the current value of the source property. This flag disables that behavior, and the bound property will be updated the next time the source property changes.\\n\\n### Complex Bindings\\n\\nBindings with more complex expressions are implemented with [Gtk.Expression](https://docs.gtk.org/gtk4/class.Expression.html). These bindings do not support flags.\\n\\n### Example\\n\\n```blueprint\\n/* Use bindings to show a label when a switch\\n * is active, without any application code */\\n\\nSwitch show_label {}\\n\\nLabel {\\n visible: bind show_label.active;\\n label: _(\\\"I'm a label that's only visible when the switch is enabled!\\\");\\n}\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/values.html#syntax-binding\"\n+ \"Syntax Object\": {\n+ \"content\": \"\\n## Objects\\n\\n```text\\nObject = TypeName ? ObjectContent\\nObjectContent = '{' (Signal | Property | Extension | Child)* '}'\\n```\\n\\nObjects are the basic building blocks of a GTK user interface. Your widgets are all objects, as are some other features such as list models.\\n\\nOptionally, objects may have an ID to provide a handle for other parts of the blueprint and your code to access objects.\\n\\n#### Note\\n\\nObject IDs must be unique within their scope. The document root is a scope, but [sub-templates](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extlistitemfactory) have their own, isolated scope.\\n\\n### Example\\n\\n```blueprint\\nLabel label1 {\\n label: \\\"Hello, world!\\\";\\n}\\nLabel label2 {\\n label: bind-property file.name;\\n}\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/objects.html#syntax-object\"\n },\n- \"Syntax ObjectValue\": {\n- \"content\": \"\\n## Object Values\\n\\n```text\\nObjectValue = Object\\n```\\n\\nThe value of a property can be an object, specified inline. This is particularly useful for widgets that use a `child` property rather than a list of child widgets. Objects constructed in this way can even have IDs and be referenced in other places in the blueprint.\\n\\nSuch objects cannot have child annotations because they aren't, as far as blueprint is concerned, children of another object.\\n\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/values.html#syntax-objectvalue\"\n+ \"Syntax TypeName\": {\n+ \"content\": \"\\n## Type Names\\n\\n```text\\nTypeName = TypeNameFull | TypeNameExternal | TypeNameShort\\nTypeNameFull = '.' \\nTypeNameExternal = '$' \\nTypeNameShort = \\n```\\n\\nThere are three forms of type names: full, short, and external. Full type names take the form `{namespace}.{name}`, e.g. `Gtk.ApplicationWindow` or `Adw.Leaflet`. Because GTK types are so common, the Gtk namespace may be omitted, shortening `Gtk.ApplicationWindow` to just `ApplicationWindow`.\\n\\nExternal type names refer to types defined in your application. They are prefixed with `$` and do not have a dot between the namespace and class name. In fact, anywhere a `$` is used in a blueprint, it refers to something that must be defined in your application code.\\n\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/objects.html#syntax-typename\"\n },\n- \"Syntax StringValue\": {\n- \"content\": \"\\n## String Values\\n\\n```text\\nStringValue = Translated | QuotedLiteral\\n```\\n\\nMenus, as well as some [extensions](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extension), have properties that can only be string literals or translated strings.\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/values.html#syntax-stringvalue\"\n+ \"Syntax Property\": {\n+ \"content\": \"\\n## Properties\\n\\n```text\\nProperty = ':' ( Binding | ExprValue | ObjectValue | Value ) ';'\\n```\\n\\nProperties specify the details of each object, like a label's text, an image's icon name, or the margins on a container.\\n\\nMost properties are static and directly specified in the blueprint, but properties can also be bound to a data model using the `bind` or `bind-property` keywords.\\n\\nA property's value can be another object, either inline or referenced by ID.\\n\\n### Example\\n\\n```blueprint\\nLabel {\\n label: \\\"text\\\";\\n}\\n\\nButton {\\n /* Inline object value. Notice the semicolon after the object. */\\n child: Image {\\n /* ... */\\n };\\n}\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/objects.html#syntax-property\"\n },\n- \"Syntax ArrayValue\": {\n- \"content\": \"\\n## Array Values\\n\\n```text\\nArrayValue = '[' (StringValue),* ']'\\n```\\n\\nFor now, it only supports [Strings](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/values.html#syntax-stringvalue). This is because Gtk.Builder only supports string arrays.\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/values.html#syntax-arrayvalue\"\n+ \"Syntax Signal\": {\n+ \"content\": \"\\n## Signal Handlers\\n\\n```text\\nSignal = ('::' )? '=>' '$' '(' ? ')' (SignalFlag)* ';'\\nSignalFlag = 'after' | 'swapped' | 'not-swapped'\\n```\\n\\nSignals are one way to respond to user input (another is [actions](https://docs.gtk.org/gtk4/actions.html), which use the [action-name property](https://docs.gtk.org/gtk4/property.Actionable.action-name.html)).\\n\\nSignals provide a handle for your code to listen to events in the UI. The handler name is prefixed with `$` to indicate that it's an external symbol which needs to be provided by your code; if it isn't, things might not work correctly, or at all.\\n\\nOptionally, you can provide an object ID to use when connecting the signal.\\n\\nThe `swapped` flag is used to swap the order of the object and userdata arguments in C applications. If an object argument is specified, then this is the default behavior, so the `not-swapped` flag can be used to prevent the swap.\\n\\n### Example\\n\\n```blueprint\\nButton {\\n clicked => $on_button_clicked();\\n}\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/objects.html#syntax-signal\"\n },\n- \"Syntax Template\": {\n- \"content\": \"\\n## Composite Templates\\n\\n```text\\nTemplate = 'template' TypeName ( ':' TypeName )? ObjectContent\\n```\\n\\nWidget subclassing is one of the primary techniques for structuring an application. For example, a maps app might have a [Gtk.ApplicationWindow](https://docs.gtk.org/gtk4/class.ApplicationWindow.html) subclass, `MapsApplicationWindow`, that implements the functionality of its main window. But a maps app has a lot of functionality, so the headerbar might be split into its own [Gtk.HeaderBar](https://docs.gtk.org/gtk4/class.HeaderBar.html) subclass, `MapsHeaderBar`, for the sake of organization.\\n\\nYou could implement this with the following blueprint:\\n\\n```blueprint\\nusing Gtk 4.0;\\n\\n$MapsApplicationWindow window {\\n $MapsHeaderBar {\\n /* probably a lot of buttons ... */\\n }\\n\\n $MapsMainView {\\n /* a lot more UI definitions ... */\\n }\\n}\\n```\\n\\nThere are two problems with this approach:\\n\\n1. The widget code may be organized neatly into different files, but the UI is not. This blueprint contains the entire UI definition for the app.\\n\\n2. Widgets aren't in control of their own contents. It shouldn't be up to the caller to construct a widget using the correct blueprint--that's an implementation detail of the widget.\\n\\nWe can solve these problems by giving each widget its own blueprint file, which we reference in the widget's constructor. Then, whenever the widget is instantiated (by another blueprint, or by the application), it will get all the children and properties defined in its blueprint.\\n\\nFor this to work, we need to specify in the blueprint which object is the one being instantiated. We do this with a template block:\\n\\n```blueprint\\nusing Gtk 4.0;\\n\\ntemplate $MapsHeaderBar : Gtk.HeaderBar {\\n /* probably a lot of buttons ... */\\n}\\n\\nGio.ListStore bookmarked_places_store {\\n /* This isn't the object being instantiated, just an auxillary object. GTK knows this because it isn't the\\n one marked with 'template'. */\\n}\\n```\\n\\nThis blueprint can only be used by the `MapsHeaderBar` constructor. Instantiating it with `Gtk.Builder` won't work since it needs an existing, under-construction `MapsHeaderBar` to use for the template object. The `template` block must be at the top level of the file (not nested within another object) and only one is allowed per file.\\n\\nThis `MapsHeaderBar` class, along with its blueprint template, can then be referenced in another blueprint:\\n\\n```blueprint\\nusing Gtk 4.0;\\n\\nApplicationWindow {\\n $MapsHeaderBar {\\n /* Nothing needed here, the widgets are in the MapsHeaderBar template. */\\n }\\n}\\n```\\n\\n### Type & Parent Parameters\\n\\nThe type name that directly follows the `template` keyword is the type of the template class. In most cases, this will be an extern type starting with `$` and matching the class name in the application code. Templates for use in a [Gtk.BuilderListItemFactory](https://docs.gtk.org/gtk4/class.BuilderListItemFactory.html) use `ListItem` as the type name instead.\\n\\nThe parent type is optional, and may only be present if the template type is extern. It enables limited type checking for the properties and signals of the template object.\\n\\n\\n## Referencing a Template\\n\\nTo reference the template object in a binding or expression, use the `template` keyword:\\n\\n```blueprint\\ntemplate $MyTemplate {\\n prop1: \\\"Hello, world!\\\";\\n prop2: bind template.prop1;\\n}\\n```\\n\\n## Language Implementations\\n\\n- **C** `gtk_widget_class_set_template ()`: https://docs.gtk.org/gtk4/class.Widget.html#building-composite-widgets-from-template-xml\\n- **gtk-rs** `#[template]`: https://gtk-rs.org/gtk4-rs/stable/latest/book/composite_templates.html\\n- **GJS** `GObject.registerClass()`: https://gjs.guide/guides/gtk/3/14-templates.html\\n- **PyGObject** `@Gtk.Template`: https://pygobject.gnome.org/guide/gtk_template.html\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/templates.html#syntax-template\"\n+ \"Syntax Child\": {\n+ \"content\": \"\\n## Children\\n\\n```text\\nChild = ChildAnnotation? Object\\nChildAnnotation = '[' ( ChildInternal | ChildExtension | ChildType ) ']'\\nChildInternal = 'internal-child' \\nChildType = \\n```\\n\\nSome objects can have children. This defines the hierarchical structure of a user interface: containers contain widgets, which can be other containers, and so on.\\n\\nChild annotations are defined by the parent widget. Some widgets, such as [HeaderBar](https://docs.gtk.org/gtk4/class.HeaderBar.html), have \\\"child types\\\" which allow different child objects to be treated in different ways. Some, such as [Dialog](https://docs.gtk.org/gtk4/class.Dialog.html) and [InfoBar](https://docs.gtk.org/gtk4/class.InfoBar.html), define child [extensions](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-childextension), which provide more detailed information about the child.\\n\\nInternal children are a special case. Rather than creating a new object, children marked with `[internal-child ]` modify an existing object provided by the parent. This is used, for example, for the `content_area` of a [Dialog](https://docs.gtk.org/gtk4/class.Dialog.html).\\n\\n#### Note\\n\\nThe objects at the root of a blueprint cannot have child annotations, since there is no root widget for them to be a child of.\\n\\n#### Note\\n\\nSome widgets, like [Button](https://docs.gtk.org/gtk4/class.Button.html), use a property to set their child instead. Widgets added in this way don't have child annotations.\\n\\n### Examples\\n\\n#### Add children to a container\\n\\n```blueprint\\nButton {\\n Image {}\\n}\\n```\\n\\n#### Child types\\n\\n```blueprint\\nHeaderBar {\\n [start]\\n Label {\\n }\\n\\n [end]\\n Button {\\n }\\n}\\n```\\n\\n#### Child extensions\\n\\n```blueprint\\nDialog {\\n // Here, a child extension annotation defines the button's response.\\n [action response=cancel]\\n Button {}\\n}\\n```\\n\\n#### Internal children\\n\\n```blueprint\\nDialog {\\n [internal-child content_area]\\n Box {\\n // Unlike most objects in a blueprint, this internal-child widget\\n // represents the properties, signal handlers, children, and extensions\\n // of an existing Box created by the Dialog, not a new Box created by\\n // the blueprint.\\n }\\n}\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/objects.html#syntax-child\"\n },\n \"Syntax Expression\": {\n \"content\": \"\\n## Expressions\\n\\n```text\\nExpression = ( ClosureExpression | Literal | ( '(' Expression ')' ) ) ( LookupExpression | CastExpression )*\\n```\\n\\n#### Note\\n\\nThe grammar above is designed to eliminate [left recursion](https://en.wikipedia.org/wiki/Left_recursion), which can make parsing more complex. In this format, an expression consists of a prefix (such as a literal value or closure invocation) followed by zero or more infix or suffix operators.\\n\\nExpressions are composed of property lookups and/or closures. Property lookups are the inputs to the expression, and closures provided in application code can perform additional calculations on those inputs.\\n\\n\\n\",\n \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/expressions.html#syntax-expression\"\n },\n \"Syntax LookupExpression\": {\n \"content\": \"\\n## Lookups\\n\\n```text\\nLookupExpression = '.' \\n```\\n\\nLookup expressions perform a GObject property lookup on the preceding expression. They are recalculated whenever the property changes, using the [notify signal](https://docs.gtk.org/gobject/signal.Object.notify.html).\\n\\nThe type of a property expression is the type of the property it refers to.\\n\\n\\n\",\n@@ -79,14 +35,90 @@\n \"content\": \"\\n## Casts\\n\\n```text\\nCastExpression = 'as' '<' TypeName '>'\\n```\\n\\nCast expressions allow Blueprint to know the type of an expression when it can't otherwise determine it. This is necessary for closures and for properties of application-defined types.\\n\\n### Example\\n\\n```blueprint\\n// Cast the result of the closure so blueprint knows it's a string\\nlabel: bind $format_bytes(template.file-size) as \\n```\\n\\n\",\n \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/expressions.html#syntax-castexpression\"\n },\n \"Syntax ExprValue\": {\n \"content\": \"\\n## Expression Values\\n\\n```text\\nExprValue = 'expr' Expression\\n```\\n\\nSome APIs take *an expression itself*--not its result--as a property value. For example, [Gtk.BoolFilter](https://docs.gtk.org/gtk4/class.BoolFilter.html) has an `expression` property of type [Gtk.Expression](https://docs.gtk.org/gtk4/class.Expression.html). This expression is evaluated for every item in a list model to determine whether the item should be filtered.\\n\\nTo define an expression for such a property, use `expr` instead of `bind`. Inside the expression, you can use the `item` keyword to refer to the item being evaluated. You must cast the item to the correct type using the `as` keyword, and you can only use `item` in a property lookup--you may not pass it to a closure.\\n\\n### Example\\n\\n```blueprint\\nBoolFilter {\\n expression: expr item as <$UserAccount>.active;\\n}\\n```\\n\\n\",\n \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/expressions.html#syntax-exprvalue\"\n },\n+ \"Syntax Extension\": {\n+ \"content\": \"\\nProperties are the main way to set values on objects, but they are limited by the GObject type system in what values they can accept. Some classes, therefore, have specialized syntax for certain features.\\n\\n#### Note\\n\\nExtensions are a feature of `Gtk.Buildable`--see [Gtk.Buildable.custom_tag_start()](https://docs.gtk.org/gtk4/vfunc.Buildable.custom_tag_start.html) for internal details.\\n\\nBecause they aren't part of the type system, they aren't present in typelib files like properties and signals are. Therefore, if a library adds a new extension, syntax for it must be added to Blueprint manually. If there's a commonly used extension that isn't supported by Blueprint, please [file an issue](https://gitlab.gnome.org/jwestman/blueprint-compiler/-/issues).\\n\\n```text\\nExtension = ExtAccessibility\\n| ExtAdwAlertDialog\\n| ExtAdwMessageDialog\\n| ExtAdwBreakpoint\\n| ExtComboBoxItems\\n| ExtFileFilterMimeTypes\\n| ExtFileFilterPatterns\\n| ExtFileFilterSuffixes\\n| ExtLayout\\n| ExtListItemFactory\\n| ExtSizeGroupWidgets\\n| ExtStringListStrings\\n| ExtStyles\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extension\"\n+ },\n+ \"Syntax ExtAccessibility\": {\n+ \"content\": \"\\n## Accessibility Properties\\n\\n```text\\nExtAccessibility = 'accessibility' '{' ExtAccessibilityProp* '}'\\nExtAccessibilityProp = ':' (Value | ('[' (:ref: Value ),* ']') ) ';'\\n```\\n\\nValid in any [Gtk.Widget](https://docs.gtk.org/gtk4/class.Widget.html).\\n\\nThe `accessibility` block defines values relevant to accessibility software. The property names and acceptable values are described in the [Gtk.AccessibleRelation](https://docs.gtk.org/gtk4/enum.AccessibleRelation.html), [Gtk.AccessibleState](https://docs.gtk.org/gtk4/enum.AccessibleState.html), and [Gtk.AccessibleProperty](https://docs.gtk.org/gtk4/enum.AccessibleProperty.html) enums.\\n\\n#### Note\\n\\nRelations which allow for a list of values, for example `labelled-by`, must be given as a single relation with a list of values instead of duplicating the relation like done in Gtk.Builder.\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extaccessibility\"\n+ },\n+ \"Syntax ExtAdwBreakpoint\": {\n+ \"content\": \"\\n## Adw.Breakpoint\\n\\n```text\\nExtAdwBreakpointCondition = 'condition' '(' ')'\\nExtAdwBreakpoint = 'setters' '{' ExtAdwBreakpointSetter* '}'\\nExtAdwBreakpointSetter = '.' ':' Value ';'\\n```\\n\\nValid in [Adw.Breakpoint](https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.Breakpoint.html).\\n\\nDefines the condition for a breakpoint and the properties that will be set at that breakpoint. See the documentation for [Adw.Breakpoint](https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.Breakpoint.html).\\n\\n#### Note\\n\\nThe [Adw.Breakpoint:condition](https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/property.Breakpoint.condition.html) property has type [Adw.BreakpointCondition](https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/struct.BreakpointCondition.html), which GtkBuilder doesn't know how to parse from a string. Therefore, the `condition` syntax is used instead.\\n\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extadwbreakpoint\"\n+ },\n+ \"Syntax ExtAdwAlertDialog\": {\n+ \"content\": \"\\n## Adw.AlertDialog Responses\\n\\n```text\\nExtAdwAlertDialog = 'responses' '[' (ExtAdwAlertDialogResponse),* ']'\\nExtAdwAlertDialogResponse = ':' StringValue ExtAdwAlertDialogFlag*\\nExtAdwAlertDialogFlag = 'destructive' | 'suggested' | 'disabled'\\n```\\n\\nValid in [Adw.AlertDialog](https://gnome.pages.gitlab.gnome.org/libadwaita/doc/1-latest/class.AlertDialog.html).\\n\\nThe `responses` block defines the buttons that will be added to the dialog. The `destructive` or `suggested` flag sets the appearance of the button, and the `disabled` flag can be used to disable the button.\\n\\n```blueprint\\nusing Adw 1;\\n\\nAdw.AlertDialog {\\n responses [\\n cancel: _(\\\"Cancel\\\"),\\n delete: _(\\\"Delete\\\") destructive,\\n save: \\\"Save\\\" suggested,\\n wipeHardDrive: \\\"Wipe Hard Drive\\\" destructive disabled,\\n ]\\n}\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extadwalertdialog\"\n+ },\n+ \"Syntax ExtAdwMessageDialog\": {\n+ \"content\": \"\\n## Adw.MessageDialog Responses\\n\\n```text\\nExtAdwMessageDialog = 'responses' '[' (ExtAdwMessageDialogResponse),* ']'\\nExtAdwMessageDialogResponse = ':' StringValue ExtAdwMessageDialogFlag*\\nExtAdwMessageDialogFlag = 'destructive' | 'suggested' | 'disabled'\\n```\\n\\nValid in [Adw.MessageDialog](https://gnome.pages.gitlab.gnome.org/libadwaita/doc/1-latest/class.MessageDialog.html).\\n\\nThe `responses` block defines the buttons that will be added to the dialog. The `destructive` or `suggested` flag sets the appearance of the button, and the `disabled` flag can be used to disable the button.\\n\\n```blueprint\\nusing Adw 1;\\n\\nAdw.MessageDialog {\\n responses [\\n cancel: _(\\\"Cancel\\\"),\\n delete: _(\\\"Delete\\\") destructive,\\n save: \\\"Save\\\" suggested,\\n wipeHardDrive: \\\"Wipe Hard Drive\\\" destructive disabled,\\n ]\\n}\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extadwmessagedialog\"\n+ },\n+ \"Syntax ExtComboBoxItems\": {\n+ \"content\": \"\\n## Gtk.ComboBoxText Items\\n\\n```text\\nExtComboBoxItems = 'items' '[' (ExtComboBoxItem),* ']'\\nExtComboBoxItem = ( ':' )? StringValue\\n```\\n\\nValid in [Gtk.ComboBoxText](https://docs.gtk.org/gtk4/class.ComboBoxText.html), which is deprecated as of Gtk 4.10.\\n\\nThe `items` block defines the items that will be added to the combo box. The optional ID can be used to refer to the item rather than its label.\\n\\n```blueprint\\nComboBoxText {\\n items [\\n item1: \\\"Item 1\\\",\\n item2: \\\"Item 2\\\",\\n item3: \\\"Item 3\\\",\\n ]\\n}\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extcomboboxitems\"\n+ },\n+ \"Syntax ExtFileFilter\": {\n+ \"content\": \"\\n## Gtk.FileFilter Filters\\n\\n```text\\nExtFileFilterMimeTypes = 'mime-types' '[' (ExtFileFilterItem),* ']'\\nExtFileFilterPatterns = 'patterns' '[' (ExtFileFilterItem),* ']'\\nExtFileFilterSuffixes = 'suffixes' '[' (ExtFileFilterItem),* ']'\\nExtFileFilterItem = \\n```\\n\\nValid in [Gtk.FileFilter](https://docs.gtk.org/gtk4/class.FileFilter.html).\\n\\nThe `mime-types`, `patterns`, and `suffixes` blocks define the items that will be added to the file filter. The `mime-types` block accepts mime types (including wildcards for subtypes, such as `image/*`). The `patterns` block accepts glob patterns, and the `suffixes` block accepts file extensions.\\n\\n```blueprint\\nFileFilter {\\n mime-types [ \\\"text/plain\\\", \\\"image/*\\\" ]\\n patterns [ \\\"*.txt\\\" ]\\n suffixes [ \\\"png\\\", \\\"jpg\\\" ]\\n}\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extfilefilter\"\n+ },\n+ \"Syntax ExtLayout\": {\n+ \"content\": \"\\n## Widget Layouts\\n\\n```text\\nExtLayout = 'layout' '{' ExtLayoutProp* '}'\\nExtLayoutProp = ':' Value ';'\\n```\\n\\nValid in [Gtk.Widget](https://docs.gtk.org/gtk4/class.Widget.html).\\n\\nThe `layout` block describes how the widget should be positioned within its parent. The available properties depend on the parent widget's layout manager.\\n\\n```blueprint\\nGrid {\\n Button {\\n layout {\\n column: 0;\\n row: 0;\\n }\\n }\\n Button {\\n layout {\\n column: 1;\\n row: 0;\\n }\\n }\\n Button {\\n layout {\\n column: 0;\\n row: 1;\\n row-span: 2;\\n }\\n }\\n}\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extlayout\"\n+ },\n+ \"Syntax ExtListItemFactory\": {\n+ \"content\": \"\\n## Gtk.BuilderListItemFactory Templates\\n\\n```text\\nExtListItemFactory = 'template' TypeName ObjectContent\\n```\\n\\nValid in [Gtk.BuilderListItemFactory](https://docs.gtk.org/gtk4/class.BuilderListItemFactory.html).\\n\\nThe `template` block defines the template that will be used to create list items. This block is unique within Blueprint because it defines a completely separate sub-blueprint which is used to create each list item. The sub-blueprint may not reference objects in the main blueprint or vice versa.\\n\\nThe template type must be [Gtk.ListItem](https://docs.gtk.org/gtk4/class.ListItem.html), [Gtk.ColumnViewRow](https://docs.gtk.org/gtk4/class.ColumnViewRow.html), or [Gtk.ColumnViewCell](https://docs.gtk.org/gtk4/class.ColumnViewCell.html). The template object can be referenced with the `template` keyword.\\n\\n```blueprint\\nListView {\\n factory: BuilderListItemFactory {\\n template ListItem {\\n child: Label {\\n label: bind template.item as .string;\\n };\\n }\\n };\\n\\n model: NoSelection {\\n model: StringList {\\n strings [ \\\"Item 1\\\", \\\"Item 2\\\", \\\"Item 3\\\" ]\\n };\\n };\\n}\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extlistitemfactory\"\n+ },\n+ \"Syntax ExtScaleMarks\": {\n+ \"content\": \"\\n## Gtk.Scale Marks\\n\\n```text\\nExtScaleMarks = 'marks' '[' (ExtScaleMark),* ']'\\nExtScaleMark = 'mark' '(' ( '-' | '+' )? ( ',' ( ',' StringValue )? )? ')'\\n```\\n\\nValid in [Gtk.Scale](https://docs.gtk.org/gtk4/class.Scale.html).\\n\\nThe `marks` block defines the marks on a scale. A single `mark` has up to three arguments: a value, an optional position, and an optional label. The position can be `left`, `right`, `top`, or `bottom`. The label may be translated.\\n\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extscalemarks\"\n+ },\n+ \"Syntax ExtSizeGroupWidgets\": {\n+ \"content\": \"\\n## Gtk.SizeGroup Widgets\\n\\n```text\\nExtSizeGroupWidgets = 'widgets' '[' (ExtSizeGroupWidget),* ']'\\nExtSizeGroupWidget = \\n```\\n\\nValid in [Gtk.SizeGroup](https://docs.gtk.org/gtk4/class.SizeGroup.html).\\n\\nThe `widgets` block defines the widgets that will be added to the size group.\\n\\n```blueprint\\nBox {\\n Button button1 {}\\n Button button2 {}\\n}\\n\\nSizeGroup {\\n widgets [button1, button2]\\n}\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extsizegroupwidgets\"\n+ },\n+ \"Syntax ExtStringListStrings\": {\n+ \"content\": \"\\n## Gtk.StringList Strings\\n\\n```text\\nExtStringListStrings = 'strings' '[' (ExtStringListItem),* ']'\\nExtStringListItem = StringValue\\n```\\n\\nValid in [Gtk.StringList](https://docs.gtk.org/gtk4/class.StringList.html).\\n\\nThe `strings` block defines the strings in the string list.\\n\\n```blueprint\\nStringList {\\n strings [\\\"violin\\\", \\\"guitar\\\", _(\\\"harp\\\")]\\n}\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extstringliststrings\"\n+ },\n+ \"Syntax ExtStyles\": {\n+ \"content\": \"\\n## CSS Styles\\n\\n```text\\nExtStyles = 'styles' '[' ExtStylesProp* ']'\\nExtStylesProp = \\n```\\n\\nValid in any [Gtk.Widget](https://docs.gtk.org/gtk4/class.Widget.html).\\n\\nThe `styles` block defines CSS classes that will be added to the widget.\\n\\n```blueprint\\nButton {\\n styles [\\\"suggested-action\\\"]\\n}\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extstyles\"\n+ },\n+ \"Syntax ChildExtension\": {\n+ \"content\": \"\\n## Child Extensions\\n\\n```text\\nChildExtension = ExtResponse\\n```\\n\\nChild extensions are similar to regular extensions, but they apply to a child of the object rather than the object itself. They are used to add properties to child widgets of a container, such as the buttons in a [Gtk.Dialog](https://docs.gtk.org/gtk4/class.Dialog.html). The child extension takes the place of a child type inside the square brackets.\\n\\nCurrently, the only child extension is [ExtResponse](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extresponse).\\n\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-childextension\"\n+ },\n+ \"Syntax ExtResponse\": {\n+ \"content\": \"\\n## Dialog & InfoBar Responses\\n\\n```text\\nExtResponse = 'action' 'response' '=' ( | ) 'default'?\\n```\\n\\nValid as a child extension for children of [Gtk.Dialog](https://docs.gtk.org/gtk4/class.Dialog.html) or [Gtk.InfoBar](https://docs.gtk.org/gtk4/class.InfoBar.html), which are both deprecated as of Gtk 4.10.\\n\\nThe `action response` extension sets the `action` child type for the child and sets the child's integer response type. The response type may be either a member of the [Gtk.ResponseType](https://docs.gtk.org/gtk4/enum.ResponseType.html) enum or a positive, application-defined integer.\\n\\nNo more than one child of a dialog or infobar may have the `default` flag.\\n\\n```blueprint\\nDialog {\\n [action response=ok default]\\n Button {}\\n\\n [action response=cancel]\\n Button {}\\n\\n [action response=1]\\n Button {}\\n}\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extresponse\"\n+ },\n+ \"Syntax Root\": {\n+ \"content\": \"\\n## Document Root\\n\\n```text\\nRoot = GtkDecl (Using)* (TranslationDomain)? ( Template | Menu | Object )* EOF\\n```\\n\\nA blueprint document consists of a [GTK declaration](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/document_root.html#syntax-gtkdecl), one or more [imports](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/document_root.html#syntax-using), and a list of [objects](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/objects.html#syntax-object) and/or a [template](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/templates.html#syntax-template).\\n\\n### Example\\n\\n```blueprint\\n// Gtk Declaration\\nusing Gtk 4.0;\\n\\n// Import Statement\\nusing Adw 1;\\n\\n// Object\\nWindow my_window {}\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/document_root.html#syntax-root\"\n+ },\n+ \"Syntax GtkDecl\": {\n+ \"content\": \"\\n## GTK Declaration\\n\\n```text\\nGtkDecl = 'using' 'Gtk' '4.0' ';'\\n```\\n\\nEvery blueprint file begins with the line `using Gtk 4.0;`, which declares the target GTK version for the file. Tools that read blueprint files should verify that they support the declared version.\\n\\n### Example\\n\\n```blueprint\\nusing Gtk 4.0;\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/document_root.html#syntax-gtkdecl\"\n+ },\n+ \"Syntax Using\": {\n+ \"content\": \"\\n## GObject Introspection Imports\\n\\n```text\\nUsing = 'using' ';'\\n```\\n\\nTo use classes and types from namespaces other than GTK itself, those namespaces must be imported at the top of the file. This tells the compiler what version of the namespace to import.\\n\\nYou'll need the GIR name and version, not the package name and not the exact version number. These are listed at the top of each library's documentation homepage:\\n\\n![gir-namespace.png](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/_images/gir-namespace.png)\\n\\nThe compiler requires typelib files for these libraries to be installed. They are usually installed with the library, but on some distros, you may need to install the package that provides `{namespace}-{version}.typelib` (e.g. `Adw-1.typelib`).\\n\\n### Example\\n\\n```blueprint\\n// Import libadwaita\\nusing Adw 1;\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/document_root.html#syntax-using\"\n+ },\n+ \"Syntax TranslationDomain\": {\n+ \"content\": \"\\n## Translation Domain\\n\\n```text\\nTranslationDomain = 'translation-domain' ';'\\n```\\n\\nThe translation domain is used to look up translations for translatable strings in the blueprint file. If no translation domain is specified, strings will be looked up in the program's global domain.\\n\\nSee [Gtk.Builder:translation-domain](https://docs.gtk.org/gtk4/property.Builder.translation-domain.html) for more information.\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/document_root.html#syntax-translationdomain\"\n+ },\n \"Diagnostic abstract_class\": {\n \"content\": \"\\n## abstract_class\\nObjects can't be created from abstract classes. Abstract classes are used as base classes for other classes, but they don't have functionality on their own. You may want to use a non-abstract subclass instead.\\n\\n\\n\",\n \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/diagnostics.html#diagnostic-abstract-class\"\n },\n \"Diagnostic bad_syntax\": {\n \"content\": \"\\n## bad_syntax\\nThe tokenizer encountered an unexpected sequence of characters that aren't part of any known blueprint syntax.\\n\\n\\n\",\n \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/diagnostics.html#diagnostic-bad-syntax\"\n@@ -171,100 +203,68 @@\n \"content\": \"\\n## version_conflict\\nThis error occurs when two versions of a namespace are imported (possibly transitively) in the same file. For example, this will cause a version conflict:\\n\\n```blueprint\\nusing Gtk 4.0;\\nusing Gtk 3.0;\\n```\\n\\nBut so will this:\\n\\n```blueprint\\nusing Gtk 4.0;\\nusing Handy 1;\\n```\\n\\nbecause libhandy imports `Gtk 3.0`.\\n\\n\\n\",\n \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/diagnostics.html#diagnostic-version-conflict\"\n },\n \"Diagnostic wrong_compiler_version\": {\n \"content\": \"\\n## wrong_compiler_version\\nThis version of blueprint-compiler is for GTK 4 blueprints only. Future GTK versions will use different versions of blueprint-compiler.\\n\",\n \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/diagnostics.html#diagnostic-wrong-compiler-version\"\n },\n- \"Syntax Extension\": {\n- \"content\": \"\\nProperties are the main way to set values on objects, but they are limited by the GObject type system in what values they can accept. Some classes, therefore, have specialized syntax for certain features.\\n\\n#### Note\\n\\nExtensions are a feature of `Gtk.Buildable`--see [Gtk.Buildable.custom_tag_start()](https://docs.gtk.org/gtk4/vfunc.Buildable.custom_tag_start.html) for internal details.\\n\\nBecause they aren't part of the type system, they aren't present in typelib files like properties and signals are. Therefore, if a library adds a new extension, syntax for it must be added to Blueprint manually. If there's a commonly used extension that isn't supported by Blueprint, please [file an issue](https://gitlab.gnome.org/jwestman/blueprint-compiler/-/issues).\\n\\n```text\\nExtension = ExtAccessibility\\n| ExtAdwAlertDialog\\n| ExtAdwMessageDialog\\n| ExtAdwBreakpoint\\n| ExtComboBoxItems\\n| ExtFileFilterMimeTypes\\n| ExtFileFilterPatterns\\n| ExtFileFilterSuffixes\\n| ExtLayout\\n| ExtListItemFactory\\n| ExtSizeGroupWidgets\\n| ExtStringListStrings\\n| ExtStyles\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extension\"\n- },\n- \"Syntax ExtAccessibility\": {\n- \"content\": \"\\n## Accessibility Properties\\n\\n```text\\nExtAccessibility = 'accessibility' '{' ExtAccessibilityProp* '}'\\nExtAccessibilityProp = ':' (Value | ('[' (:ref: Value ),* ']') ) ';'\\n```\\n\\nValid in any [Gtk.Widget](https://docs.gtk.org/gtk4/class.Widget.html).\\n\\nThe `accessibility` block defines values relevant to accessibility software. The property names and acceptable values are described in the [Gtk.AccessibleRelation](https://docs.gtk.org/gtk4/enum.AccessibleRelation.html), [Gtk.AccessibleState](https://docs.gtk.org/gtk4/enum.AccessibleState.html), and [Gtk.AccessibleProperty](https://docs.gtk.org/gtk4/enum.AccessibleProperty.html) enums.\\n\\n#### Note\\n\\nRelations which allow for a list of values, for example `labelled-by`, must be given as a single relation with a list of values instead of duplicating the relation like done in Gtk.Builder.\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extaccessibility\"\n- },\n- \"Syntax ExtAdwBreakpoint\": {\n- \"content\": \"\\n## Adw.Breakpoint\\n\\n```text\\nExtAdwBreakpointCondition = 'condition' '(' ')'\\nExtAdwBreakpoint = 'setters' '{' ExtAdwBreakpointSetter* '}'\\nExtAdwBreakpointSetter = '.' ':' Value ';'\\n```\\n\\nValid in [Adw.Breakpoint](https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.Breakpoint.html).\\n\\nDefines the condition for a breakpoint and the properties that will be set at that breakpoint. See the documentation for [Adw.Breakpoint](https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.Breakpoint.html).\\n\\n#### Note\\n\\nThe [Adw.Breakpoint:condition](https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/property.Breakpoint.condition.html) property has type [Adw.BreakpointCondition](https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/struct.BreakpointCondition.html), which GtkBuilder doesn't know how to parse from a string. Therefore, the `condition` syntax is used instead.\\n\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extadwbreakpoint\"\n- },\n- \"Syntax ExtAdwAlertDialog\": {\n- \"content\": \"\\n## Adw.AlertDialog Responses\\n\\n```text\\nExtAdwAlertDialog = 'responses' '[' (ExtAdwAlertDialogResponse),* ']'\\nExtAdwAlertDialogResponse = ':' StringValue ExtAdwAlertDialogFlag*\\nExtAdwAlertDialogFlag = 'destructive' | 'suggested' | 'disabled'\\n```\\n\\nValid in [Adw.AlertDialog](https://gnome.pages.gitlab.gnome.org/libadwaita/doc/1-latest/class.AlertDialog.html).\\n\\nThe `responses` block defines the buttons that will be added to the dialog. The `destructive` or `suggested` flag sets the appearance of the button, and the `disabled` flag can be used to disable the button.\\n\\n```blueprint\\nusing Adw 1;\\n\\nAdw.AlertDialog {\\n responses [\\n cancel: _(\\\"Cancel\\\"),\\n delete: _(\\\"Delete\\\") destructive,\\n save: \\\"Save\\\" suggested,\\n wipeHardDrive: \\\"Wipe Hard Drive\\\" destructive disabled,\\n ]\\n}\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extadwalertdialog\"\n- },\n- \"Syntax ExtAdwMessageDialog\": {\n- \"content\": \"\\n## Adw.MessageDialog Responses\\n\\n```text\\nExtAdwMessageDialog = 'responses' '[' (ExtAdwMessageDialogResponse),* ']'\\nExtAdwMessageDialogResponse = ':' StringValue ExtAdwMessageDialogFlag*\\nExtAdwMessageDialogFlag = 'destructive' | 'suggested' | 'disabled'\\n```\\n\\nValid in [Adw.MessageDialog](https://gnome.pages.gitlab.gnome.org/libadwaita/doc/1-latest/class.MessageDialog.html).\\n\\nThe `responses` block defines the buttons that will be added to the dialog. The `destructive` or `suggested` flag sets the appearance of the button, and the `disabled` flag can be used to disable the button.\\n\\n```blueprint\\nusing Adw 1;\\n\\nAdw.MessageDialog {\\n responses [\\n cancel: _(\\\"Cancel\\\"),\\n delete: _(\\\"Delete\\\") destructive,\\n save: \\\"Save\\\" suggested,\\n wipeHardDrive: \\\"Wipe Hard Drive\\\" destructive disabled,\\n ]\\n}\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extadwmessagedialog\"\n- },\n- \"Syntax ExtComboBoxItems\": {\n- \"content\": \"\\n## Gtk.ComboBoxText Items\\n\\n```text\\nExtComboBoxItems = 'items' '[' (ExtComboBoxItem),* ']'\\nExtComboBoxItem = ( ':' )? StringValue\\n```\\n\\nValid in [Gtk.ComboBoxText](https://docs.gtk.org/gtk4/class.ComboBoxText.html), which is deprecated as of Gtk 4.10.\\n\\nThe `items` block defines the items that will be added to the combo box. The optional ID can be used to refer to the item rather than its label.\\n\\n```blueprint\\nComboBoxText {\\n items [\\n item1: \\\"Item 1\\\",\\n item2: \\\"Item 2\\\",\\n item3: \\\"Item 3\\\",\\n ]\\n}\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extcomboboxitems\"\n- },\n- \"Syntax ExtFileFilter\": {\n- \"content\": \"\\n## Gtk.FileFilter Filters\\n\\n```text\\nExtFileFilterMimeTypes = 'mime-types' '[' (ExtFileFilterItem),* ']'\\nExtFileFilterPatterns = 'patterns' '[' (ExtFileFilterItem),* ']'\\nExtFileFilterSuffixes = 'suffixes' '[' (ExtFileFilterItem),* ']'\\nExtFileFilterItem = \\n```\\n\\nValid in [Gtk.FileFilter](https://docs.gtk.org/gtk4/class.FileFilter.html).\\n\\nThe `mime-types`, `patterns`, and `suffixes` blocks define the items that will be added to the file filter. The `mime-types` block accepts mime types (including wildcards for subtypes, such as `image/*`). The `patterns` block accepts glob patterns, and the `suffixes` block accepts file extensions.\\n\\n```blueprint\\nFileFilter {\\n mime-types [ \\\"text/plain\\\", \\\"image/*\\\" ]\\n patterns [ \\\"*.txt\\\" ]\\n suffixes [ \\\"png\\\", \\\"jpg\\\" ]\\n}\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extfilefilter\"\n- },\n- \"Syntax ExtLayout\": {\n- \"content\": \"\\n## Widget Layouts\\n\\n```text\\nExtLayout = 'layout' '{' ExtLayoutProp* '}'\\nExtLayoutProp = ':' Value ';'\\n```\\n\\nValid in [Gtk.Widget](https://docs.gtk.org/gtk4/class.Widget.html).\\n\\nThe `layout` block describes how the widget should be positioned within its parent. The available properties depend on the parent widget's layout manager.\\n\\n```blueprint\\nGrid {\\n Button {\\n layout {\\n column: 0;\\n row: 0;\\n }\\n }\\n Button {\\n layout {\\n column: 1;\\n row: 0;\\n }\\n }\\n Button {\\n layout {\\n column: 0;\\n row: 1;\\n row-span: 2;\\n }\\n }\\n}\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extlayout\"\n- },\n- \"Syntax ExtListItemFactory\": {\n- \"content\": \"\\n## Gtk.BuilderListItemFactory Templates\\n\\n```text\\nExtListItemFactory = 'template' TypeName ObjectContent\\n```\\n\\nValid in [Gtk.BuilderListItemFactory](https://docs.gtk.org/gtk4/class.BuilderListItemFactory.html).\\n\\nThe `template` block defines the template that will be used to create list items. This block is unique within Blueprint because it defines a completely separate sub-blueprint which is used to create each list item. The sub-blueprint may not reference objects in the main blueprint or vice versa.\\n\\nThe template type must be [Gtk.ListItem](https://docs.gtk.org/gtk4/class.ListItem.html), [Gtk.ColumnViewRow](https://docs.gtk.org/gtk4/class.ColumnViewRow.html), or [Gtk.ColumnViewCell](https://docs.gtk.org/gtk4/class.ColumnViewCell.html). The template object can be referenced with the `template` keyword.\\n\\n```blueprint\\nListView {\\n factory: BuilderListItemFactory {\\n template ListItem {\\n child: Label {\\n label: bind template.item as .string;\\n };\\n }\\n };\\n\\n model: NoSelection {\\n model: StringList {\\n strings [ \\\"Item 1\\\", \\\"Item 2\\\", \\\"Item 3\\\" ]\\n };\\n };\\n}\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extlistitemfactory\"\n- },\n- \"Syntax ExtScaleMarks\": {\n- \"content\": \"\\n## Gtk.Scale Marks\\n\\n```text\\nExtScaleMarks = 'marks' '[' (ExtScaleMark),* ']'\\nExtScaleMark = 'mark' '(' ( '-' | '+' )? ( ',' ( ',' StringValue )? )? ')'\\n```\\n\\nValid in [Gtk.Scale](https://docs.gtk.org/gtk4/class.Scale.html).\\n\\nThe `marks` block defines the marks on a scale. A single `mark` has up to three arguments: a value, an optional position, and an optional label. The position can be `left`, `right`, `top`, or `bottom`. The label may be translated.\\n\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extscalemarks\"\n- },\n- \"Syntax ExtSizeGroupWidgets\": {\n- \"content\": \"\\n## Gtk.SizeGroup Widgets\\n\\n```text\\nExtSizeGroupWidgets = 'widgets' '[' (ExtSizeGroupWidget),* ']'\\nExtSizeGroupWidget = \\n```\\n\\nValid in [Gtk.SizeGroup](https://docs.gtk.org/gtk4/class.SizeGroup.html).\\n\\nThe `widgets` block defines the widgets that will be added to the size group.\\n\\n```blueprint\\nBox {\\n Button button1 {}\\n Button button2 {}\\n}\\n\\nSizeGroup {\\n widgets [button1, button2]\\n}\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extsizegroupwidgets\"\n- },\n- \"Syntax ExtStringListStrings\": {\n- \"content\": \"\\n## Gtk.StringList Strings\\n\\n```text\\nExtStringListStrings = 'strings' '[' (ExtStringListItem),* ']'\\nExtStringListItem = StringValue\\n```\\n\\nValid in [Gtk.StringList](https://docs.gtk.org/gtk4/class.StringList.html).\\n\\nThe `strings` block defines the strings in the string list.\\n\\n```blueprint\\nStringList {\\n strings [\\\"violin\\\", \\\"guitar\\\", _(\\\"harp\\\")]\\n}\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extstringliststrings\"\n- },\n- \"Syntax ExtStyles\": {\n- \"content\": \"\\n## CSS Styles\\n\\n```text\\nExtStyles = 'styles' '[' ExtStylesProp* ']'\\nExtStylesProp = \\n```\\n\\nValid in any [Gtk.Widget](https://docs.gtk.org/gtk4/class.Widget.html).\\n\\nThe `styles` block defines CSS classes that will be added to the widget.\\n\\n```blueprint\\nButton {\\n styles [\\\"suggested-action\\\"]\\n}\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extstyles\"\n- },\n- \"Syntax ChildExtension\": {\n- \"content\": \"\\n## Child Extensions\\n\\n```text\\nChildExtension = ExtResponse\\n```\\n\\nChild extensions are similar to regular extensions, but they apply to a child of the object rather than the object itself. They are used to add properties to child widgets of a container, such as the buttons in a [Gtk.Dialog](https://docs.gtk.org/gtk4/class.Dialog.html). The child extension takes the place of a child type inside the square brackets.\\n\\nCurrently, the only child extension is [ExtResponse](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extresponse).\\n\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-childextension\"\n- },\n- \"Syntax ExtResponse\": {\n- \"content\": \"\\n## Dialog & InfoBar Responses\\n\\n```text\\nExtResponse = 'action' 'response' '=' ( | ) 'default'?\\n```\\n\\nValid as a child extension for children of [Gtk.Dialog](https://docs.gtk.org/gtk4/class.Dialog.html) or [Gtk.InfoBar](https://docs.gtk.org/gtk4/class.InfoBar.html), which are both deprecated as of Gtk 4.10.\\n\\nThe `action response` extension sets the `action` child type for the child and sets the child's integer response type. The response type may be either a member of the [Gtk.ResponseType](https://docs.gtk.org/gtk4/enum.ResponseType.html) enum or a positive, application-defined integer.\\n\\nNo more than one child of a dialog or infobar may have the `default` flag.\\n\\n```blueprint\\nDialog {\\n [action response=ok default]\\n Button {}\\n\\n [action response=cancel]\\n Button {}\\n\\n [action response=1]\\n Button {}\\n}\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extresponse\"\n- },\n \"Syntax IDENT\": {\n \"content\": \"\\n## IDENT\\n\\nAn identifier starts with an ASCII underscore `_` or letter `[A-Za-z]` and consists of ASCII underscores, letters, digits `[0-9]`, and dashes `-`. Dashes are included for historical reasons, since GObject properties and signals are traditionally kebab-case.\\n\\n\",\n \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/index.html#syntax-ident\"\n },\n \"Syntax NUMBER\": {\n \"content\": \"\\n## NUMBER\\n\\nNumbers begin with an ASCII digit and consist of ASCII digits, underscores, dots `.`, and letters (for radix pre-/suffixes). More than one dot in a number is not allowed. Underscores are permitted for increased readability, and are ignored.\\n\\nHexadecimal numbers may be specified using the `0x` prefix and may use uppercase or lowercase letters, or a mix. Hexadecimal values may not have a fractional part. They are generally converted to decimal in the output.\\n\\n\",\n \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/index.html#syntax-number\"\n },\n \"Syntax QUOTED\": {\n \"content\": \"\\n## QUOTED\\n\\nQuotes begin with an ASCII single quote `'` or double quote `\\\"` and end with the same character they started with. An ASCII backslash `\\\\` begins an escape sequence; this allows newlines `\\\\n`, tabs `\\\\t`, and quotes `\\\\'`, `\\\\\\\"` to be inserted. It also allows multiline strings by escaping a newline character, which will be ignored.\\n\",\n \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/index.html#syntax-quoted\"\n },\n- \"Syntax Object\": {\n- \"content\": \"\\n## Objects\\n\\n```text\\nObject = TypeName ? ObjectContent\\nObjectContent = '{' (Signal | Property | Extension | Child)* '}'\\n```\\n\\nObjects are the basic building blocks of a GTK user interface. Your widgets are all objects, as are some other features such as list models.\\n\\nOptionally, objects may have an ID to provide a handle for other parts of the blueprint and your code to access objects.\\n\\n#### Note\\n\\nObject IDs must be unique within their scope. The document root is a scope, but [sub-templates](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extlistitemfactory) have their own, isolated scope.\\n\\n### Example\\n\\n```blueprint\\nLabel label1 {\\n label: \\\"Hello, world!\\\";\\n}\\nLabel label2 {\\n label: bind-property file.name;\\n}\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/objects.html#syntax-object\"\n+ \"Syntax Menu\": {\n+ \"content\": \"\\n## Menus\\n\\n```text\\nMenu = 'menu' ? '{' MenuChild* '}'\\nMenuChild = ( MenuSection | MenuSubmenu | MenuItemShorthand | MenuItem )\\nMenuSection = 'section' ? '{' ( MenuChild | MenuAttribute )* '}'\\nMenuSubmenu = 'submenu' ? '{' ( MenuChild | MenuAttribute )* '}'\\nMenuItem = 'item' '{' MenuAttribute* '}'\\nMenuAttribute = ':' StringValue ';'\\n```\\n\\nMenus, such as the application menu, are defined using the `menu` keyword. Menus have the type [Gio.MenuModel](https://docs.gtk.org/gio/class.MenuModel.html) and can be referenced by ID. They cannot be defined inline.\\n\\n### Example\\n\\n```blueprint\\nmenu my_menu {\\n submenu {\\n label: _(\\\"File\\\");\\n item {\\n label: _(\\\"New\\\");\\n action: \\\"app.new\\\";\\n icon: \\\"document-new-symbolic\\\";\\n }\\n }\\n}\\n\\nMenuButton {\\n menu-model: my_menu;\\n}\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/menus.html#syntax-menu\"\n },\n- \"Syntax TypeName\": {\n- \"content\": \"\\n## Type Names\\n\\n```text\\nTypeName = TypeNameFull | TypeNameExternal | TypeNameShort\\nTypeNameFull = '.' \\nTypeNameExternal = '$' \\nTypeNameShort = \\n```\\n\\nThere are three forms of type names: full, short, and external. Full type names take the form `{namespace}.{name}`, e.g. `Gtk.ApplicationWindow` or `Adw.Leaflet`. Because GTK types are so common, the Gtk namespace may be omitted, shortening `Gtk.ApplicationWindow` to just `ApplicationWindow`.\\n\\nExternal type names refer to types defined in your application. They are prefixed with `$` and do not have a dot between the namespace and class name. In fact, anywhere a `$` is used in a blueprint, it refers to something that must be defined in your application code.\\n\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/objects.html#syntax-typename\"\n+ \"Syntax MenuItemShorthand\": {\n+ \"content\": \"\\n## Item Shorthand\\n\\n```text\\nMenuItemShorthand = 'item' '(' StringValue ( ',' ( StringValue ( ',' StringValue? )? )? )? ')'\\n```\\n\\nThe most common menu attributes are `label`, `action`, and `icon`. Because they're so common, Blueprint provides a shorter syntax for menu items with just these properties.\\n\\n### Example\\n\\n```blueprint\\nmenu {\\n item (\\\"label\\\")\\n item (\\\"label\\\", \\\"action\\\")\\n item (\\\"label\\\", \\\"action\\\", \\\"icon\\\")\\n}\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/menus.html#syntax-menuitemshorthand\"\n },\n- \"Syntax Property\": {\n- \"content\": \"\\n## Properties\\n\\n```text\\nProperty = ':' ( Binding | ExprValue | ObjectValue | Value ) ';'\\n```\\n\\nProperties specify the details of each object, like a label's text, an image's icon name, or the margins on a container.\\n\\nMost properties are static and directly specified in the blueprint, but properties can also be bound to a data model using the `bind` or `bind-property` keywords.\\n\\nA property's value can be another object, either inline or referenced by ID.\\n\\n### Example\\n\\n```blueprint\\nLabel {\\n label: \\\"text\\\";\\n}\\n\\nButton {\\n /* Inline object value. Notice the semicolon after the object. */\\n child: Image {\\n /* ... */\\n };\\n}\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/objects.html#syntax-property\"\n+ \"Syntax Template\": {\n+ \"content\": \"\\n## Composite Templates\\n\\n```text\\nTemplate = 'template' TypeName ( ':' TypeName )? ObjectContent\\n```\\n\\nWidget subclassing is one of the primary techniques for structuring an application. For example, a maps app might have a [Gtk.ApplicationWindow](https://docs.gtk.org/gtk4/class.ApplicationWindow.html) subclass, `MapsApplicationWindow`, that implements the functionality of its main window. But a maps app has a lot of functionality, so the headerbar might be split into its own [Gtk.HeaderBar](https://docs.gtk.org/gtk4/class.HeaderBar.html) subclass, `MapsHeaderBar`, for the sake of organization.\\n\\nYou could implement this with the following blueprint:\\n\\n```blueprint\\nusing Gtk 4.0;\\n\\n$MapsApplicationWindow window {\\n $MapsHeaderBar {\\n /* probably a lot of buttons ... */\\n }\\n\\n $MapsMainView {\\n /* a lot more UI definitions ... */\\n }\\n}\\n```\\n\\nThere are two problems with this approach:\\n\\n1. The widget code may be organized neatly into different files, but the UI is not. This blueprint contains the entire UI definition for the app.\\n\\n2. Widgets aren't in control of their own contents. It shouldn't be up to the caller to construct a widget using the correct blueprint--that's an implementation detail of the widget.\\n\\nWe can solve these problems by giving each widget its own blueprint file, which we reference in the widget's constructor. Then, whenever the widget is instantiated (by another blueprint, or by the application), it will get all the children and properties defined in its blueprint.\\n\\nFor this to work, we need to specify in the blueprint which object is the one being instantiated. We do this with a template block:\\n\\n```blueprint\\nusing Gtk 4.0;\\n\\ntemplate $MapsHeaderBar : Gtk.HeaderBar {\\n /* probably a lot of buttons ... */\\n}\\n\\nGio.ListStore bookmarked_places_store {\\n /* This isn't the object being instantiated, just an auxillary object. GTK knows this because it isn't the\\n one marked with 'template'. */\\n}\\n```\\n\\nThis blueprint can only be used by the `MapsHeaderBar` constructor. Instantiating it with `Gtk.Builder` won't work since it needs an existing, under-construction `MapsHeaderBar` to use for the template object. The `template` block must be at the top level of the file (not nested within another object) and only one is allowed per file.\\n\\nThis `MapsHeaderBar` class, along with its blueprint template, can then be referenced in another blueprint:\\n\\n```blueprint\\nusing Gtk 4.0;\\n\\nApplicationWindow {\\n $MapsHeaderBar {\\n /* Nothing needed here, the widgets are in the MapsHeaderBar template. */\\n }\\n}\\n```\\n\\n### Type & Parent Parameters\\n\\nThe type name that directly follows the `template` keyword is the type of the template class. In most cases, this will be an extern type starting with `$` and matching the class name in the application code. Templates for use in a [Gtk.BuilderListItemFactory](https://docs.gtk.org/gtk4/class.BuilderListItemFactory.html) use `ListItem` as the type name instead.\\n\\nThe parent type is optional, and may only be present if the template type is extern. It enables limited type checking for the properties and signals of the template object.\\n\\n\\n## Referencing a Template\\n\\nTo reference the template object in a binding or expression, use the `template` keyword:\\n\\n```blueprint\\ntemplate $MyTemplate {\\n prop1: \\\"Hello, world!\\\";\\n prop2: bind template.prop1;\\n}\\n```\\n\\n## Language Implementations\\n\\n- **C** `gtk_widget_class_set_template ()`: https://docs.gtk.org/gtk4/class.Widget.html#building-composite-widgets-from-template-xml\\n- **gtk-rs** `#[template]`: https://gtk-rs.org/gtk4-rs/stable/latest/book/composite_templates.html\\n- **GJS** `GObject.registerClass()`: https://gjs.guide/guides/gtk/3/14-templates.html\\n- **PyGObject** `@Gtk.Template`: https://pygobject.gnome.org/guide/gtk_template.html\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/templates.html#syntax-template\"\n },\n- \"Syntax Signal\": {\n- \"content\": \"\\n## Signal Handlers\\n\\n```text\\nSignal = ('::' )? '=>' '$' '(' ? ')' (SignalFlag)* ';'\\nSignalFlag = 'after' | 'swapped' | 'not-swapped'\\n```\\n\\nSignals are one way to respond to user input (another is [actions](https://docs.gtk.org/gtk4/actions.html), which use the [action-name property](https://docs.gtk.org/gtk4/property.Actionable.action-name.html)).\\n\\nSignals provide a handle for your code to listen to events in the UI. The handler name is prefixed with `$` to indicate that it's an external symbol which needs to be provided by your code; if it isn't, things might not work correctly, or at all.\\n\\nOptionally, you can provide an object ID to use when connecting the signal.\\n\\nThe `swapped` flag is used to swap the order of the object and userdata arguments in C applications. If an object argument is specified, then this is the default behavior, so the `not-swapped` flag can be used to prevent the swap.\\n\\n### Example\\n\\n```blueprint\\nButton {\\n clicked => $on_button_clicked();\\n}\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/objects.html#syntax-signal\"\n+ \"Syntax Value\": {\n+ \"content\": \"\\n## Values\\n\\n```text\\nValue = Translated | Flags | Literal\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/values.html#syntax-value\"\n },\n- \"Syntax Child\": {\n- \"content\": \"\\n## Children\\n\\n```text\\nChild = ChildAnnotation? Object\\nChildAnnotation = '[' ( ChildInternal | ChildExtension | ChildType ) ']'\\nChildInternal = 'internal-child' \\nChildType = \\n```\\n\\nSome objects can have children. This defines the hierarchical structure of a user interface: containers contain widgets, which can be other containers, and so on.\\n\\nChild annotations are defined by the parent widget. Some widgets, such as [HeaderBar](https://docs.gtk.org/gtk4/class.HeaderBar.html), have \\\"child types\\\" which allow different child objects to be treated in different ways. Some, such as [Dialog](https://docs.gtk.org/gtk4/class.Dialog.html) and [InfoBar](https://docs.gtk.org/gtk4/class.InfoBar.html), define child [extensions](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-childextension), which provide more detailed information about the child.\\n\\nInternal children are a special case. Rather than creating a new object, children marked with `[internal-child ]` modify an existing object provided by the parent. This is used, for example, for the `content_area` of a [Dialog](https://docs.gtk.org/gtk4/class.Dialog.html).\\n\\n#### Note\\n\\nThe objects at the root of a blueprint cannot have child annotations, since there is no root widget for them to be a child of.\\n\\n#### Note\\n\\nSome widgets, like [Button](https://docs.gtk.org/gtk4/class.Button.html), use a property to set their child instead. Widgets added in this way don't have child annotations.\\n\\n### Examples\\n\\n#### Add children to a container\\n\\n```blueprint\\nButton {\\n Image {}\\n}\\n```\\n\\n#### Child types\\n\\n```blueprint\\nHeaderBar {\\n [start]\\n Label {\\n }\\n\\n [end]\\n Button {\\n }\\n}\\n```\\n\\n#### Child extensions\\n\\n```blueprint\\nDialog {\\n // Here, a child extension annotation defines the button's response.\\n [action response=cancel]\\n Button {}\\n}\\n```\\n\\n#### Internal children\\n\\n```blueprint\\nDialog {\\n [internal-child content_area]\\n Box {\\n // Unlike most objects in a blueprint, this internal-child widget\\n // represents the properties, signal handlers, children, and extensions\\n // of an existing Box created by the Dialog, not a new Box created by\\n // the blueprint.\\n }\\n}\\n```\\n\\n\",\n- \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/objects.html#syntax-child\"\n+ \"Syntax Literal\": {\n+ \"content\": \"\\n## Literals\\n\\n```text\\nLiteral = TypeLiteral | QuotedLiteral | NumberLiteral | IdentLiteral\\nQuotedLiteral = \\nNumberLiteral = ( '-' | '+' )? \\nIdentLiteral = \\n```\\n\\nLiterals are used to specify values for properties. They can be strings, numbers, references to objects, `null`, types, boolean values, or enum members.\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/values.html#syntax-literal\"\n+ },\n+ \"Syntax TypeLiteral\": {\n+ \"content\": \"\\n## Type Literals\\n\\n```text\\nTypeLiteral = 'typeof' '<' TypeName '>'\\n```\\n\\nSometimes, you need to specify a type as a value. For example, when creating a list store, you may need to specify the type of the items in the list store. This is done using a `typeof<>` literal.\\n\\nThe type of a `typeof<>` literal is [GType](https://docs.gtk.org/gobject/alias.Type.html), GObject's \\\"meta-type\\\" for type information.\\n\\n\\n### Example\\n\\n```blueprint\\nGio.ListStore {\\n item-type: typeof;\\n}\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/values.html#syntax-typeliteral\"\n+ },\n+ \"Syntax Flags\": {\n+ \"content\": \"\\n## Flags\\n\\n```text\\nFlags = '|' ( )|+\\n```\\n\\nFlags are used to specify a set of options. One or more of the available flag values may be specified, and they are combined using `|`.\\n\\n### Example\\n\\n```blueprint\\nAdw.TabView {\\n shortcuts: control_tab | control_shift_tab;\\n}\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/values.html#syntax-flags\"\n+ },\n+ \"Syntax Translated\": {\n+ \"content\": \"\\n## Translated Strings\\n\\n```text\\nTranslated = ( '_' '(' ')' ) | ( '\\\\C_' '(' ',' ')' )\\n```\\n\\nUse `_(\\\"...\\\")` to mark strings as translatable. You can put a comment for translators on the line above if needed.\\n\\n```blueprint\\nGtk.Label label {\\n /* Translators: This is the main text of the welcome screen */\\n label: _(\\\"Hello, world!\\\");\\n}\\n```\\n\\nUse `C_(\\\"context\\\", \\\"...\\\")` to add a *message context* to a string to disambiguate it, in case the same string appears in different places. Remember, two strings might be the same in one language but different in another depending on context.\\n\\n```blueprint\\nGtk.Label label {\\n /* Translators: This is a section in the preferences window */\\n label: C_(\\\"preferences window\\\", \\\"Hello, world!\\\");\\n}\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/values.html#syntax-translated\"\n+ },\n+ \"Syntax Binding\": {\n+ \"content\": \"\\n## Bindings\\n\\n```text\\nBinding = 'bind' Expression (BindingFlag)*\\nBindingFlag = 'inverted' | 'bidirectional' | 'no-sync-create'\\n```\\n\\nBindings keep a property updated as other properties change. They can be used to keep the UI in sync with application data, or to connect two parts of the UI.\\n\\nThe simplest bindings connect to a property of another object in the blueprint. When that other property changes, the bound property updates as well. More advanced bindings can do multi-step property lookups and can even call application code to compute values. See [the expressions page](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/expressions.html#syntax-expression).\\n\\n### Simple Bindings\\n\\nA binding that consists of a source object and a single lookup is called a \\\"simple binding\\\". These are implemented using [GObject property bindings](https://docs.gtk.org/gobject/method.Object.bind_property.html) and support a few flags:\\n\\n- `inverted`: For boolean properties, the target is set to the inverse of the source property.\\n- `bidirectional`: The binding is two-way, so changes to the target property will also update the source property.\\n- `no-sync-create`: Normally, when a binding is created, the target property is immediately updated with the current value of the source property. This flag disables that behavior, and the bound property will be updated the next time the source property changes.\\n\\n### Complex Bindings\\n\\nBindings with more complex expressions are implemented with [Gtk.Expression](https://docs.gtk.org/gtk4/class.Expression.html). These bindings do not support flags.\\n\\n### Example\\n\\n```blueprint\\n/* Use bindings to show a label when a switch\\n * is active, without any application code */\\n\\nSwitch show_label {}\\n\\nLabel {\\n visible: bind show_label.active;\\n label: _(\\\"I'm a label that's only visible when the switch is enabled!\\\");\\n}\\n```\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/values.html#syntax-binding\"\n+ },\n+ \"Syntax ObjectValue\": {\n+ \"content\": \"\\n## Object Values\\n\\n```text\\nObjectValue = Object\\n```\\n\\nThe value of a property can be an object, specified inline. This is particularly useful for widgets that use a `child` property rather than a list of child widgets. Objects constructed in this way can even have IDs and be referenced in other places in the blueprint.\\n\\nSuch objects cannot have child annotations because they aren't, as far as blueprint is concerned, children of another object.\\n\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/values.html#syntax-objectvalue\"\n+ },\n+ \"Syntax StringValue\": {\n+ \"content\": \"\\n## String Values\\n\\n```text\\nStringValue = Translated | QuotedLiteral\\n```\\n\\nMenus, as well as some [extensions](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/extensions.html#syntax-extension), have properties that can only be string literals or translated strings.\\n\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/values.html#syntax-stringvalue\"\n+ },\n+ \"Syntax ArrayValue\": {\n+ \"content\": \"\\n## Array Values\\n\\n```text\\nArrayValue = '[' (StringValue),* ']'\\n```\\n\\nFor now, it only supports [Strings](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/values.html#syntax-stringvalue). This is because Gtk.Builder only supports string arrays.\\n\",\n+ \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/values.html#syntax-arrayvalue\"\n }\n }\n"}]}]}]}]}]}