{"diffoscope-json-version": 1, "source1": "/srv/reproducible-results/rbuild-debian/r-b-build.FDMVhEQF/b1/blueprint-compiler_0.16.0-1_amd64.changes", "source2": "/srv/reproducible-results/rbuild-debian/r-b-build.FDMVhEQF/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- 94ae57f831300848c54345d5e929ebda 69716 gnome optional blueprint-compiler_0.16.0-1_all.deb\n+ 85de5d6319acf3bfd577c4a9d3d07927 69688 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    66772 2025-01-22 20:21:28.000000 data.tar.xz\n+-rw-r--r--   0        0        0    66744 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,124 +1,8 @@\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 = '.' <property:IDENT>\\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-        \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/expressions.html#syntax-lookupexpression\"\n-    },\n-    \"Syntax ClosureExpression\": {\n-        \"content\": \"\\n## Closures\\n\\n```text\\nClosureExpression = '$' <name:IDENT> '(' ( Expression ),* ')'\\n```\\n\\nClosure expressions allow you to perform additional calculations that aren't supported in blueprint by writing those calculations as application code. These application-defined functions are created in the same way as [signal handlers](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/objects.html#syntax-signal).\\n\\nExpressions are only reevaluated when their inputs change. Because blueprint doesn't manage a closure's application code, it can't tell what changes might affect the result. Therefore, closures must be *pure*, or deterministic. They may only calculate the result based on their immediate inputs, not properties of their inputs or outside variables.\\n\\nBlueprint doesn't know the closure's return type, so closure expressions must be cast to the correct return type using a [cast expression](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/expressions.html#syntax-castexpression).\\n\\n\\n\",\n-        \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/expressions.html#syntax-closureexpression\"\n-    },\n-    \"Syntax CastExpression\": {\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 <string>\\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 Object\": {\n-        \"content\": \"\\n## Objects\\n\\n```text\\nObject = TypeName <id:IDENT>? 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 TypeName\": {\n-        \"content\": \"\\n## Type Names\\n\\n```text\\nTypeName = TypeNameFull | TypeNameExternal | TypeNameShort\\nTypeNameFull = <namespace:IDENT> '.' <name:IDENT>\\nTypeNameExternal = '$' <name:IDENT>\\nTypeNameShort = <name:IDENT>\\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 Property\": {\n-        \"content\": \"\\n## Properties\\n\\n```text\\nProperty = <name:IDENT> ':' ( 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 Signal\": {\n-        \"content\": \"\\n## Signal Handlers\\n\\n```text\\nSignal = <name:IDENT> ('::' <detail:IDENT>)? '=>' '$' <handler:IDENT> '(' <object:IDENT>? ')' (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 Child\": {\n-        \"content\": \"\\n## Children\\n\\n```text\\nChild = ChildAnnotation? Object\\nChildAnnotation = '[' ( ChildInternal | ChildExtension | ChildType ) ']'\\nChildInternal = 'internal-child' <internal-child:IDENT>\\nChildType = <child_type:IDENT>\\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 <name>]` 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 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 = <name:IDENT> ':' (Value  | ('[' (:ref: Value <Syntax 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' '(' <condition:QUOTED> ')'\\nExtAdwBreakpoint = 'setters' '{' ExtAdwBreakpointSetter* '}'\\nExtAdwBreakpointSetter = <object:IDENT> '.' <property:IDENT> ':' 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 = <id:IDENT> ':' 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 = <id:IDENT> ':' 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 = ( <id:IDENT> ':' )? 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 = <item:QUOTED>\\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 = <name:IDENT> ':' 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 <StringObject>.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' '(' ( '-' | '+' )? <value:NUMBER> ( ',' <position:IDENT> ( ',' 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 = <id:IDENT>\\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 = <name:QUOTED>\\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' '=' ( <name:IDENT> | <id:NUMBER> ) '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 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 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     \"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@@ -203,14 +87,42 @@\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 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 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' <namespace:IDENT> <version:NUMBER> ';'\\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' <domain:QUOTED> ';'\\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 = <value:QUOTED>\\nNumberLiteral = ( '-' | '+' )? <value:NUMBER>\\nIdentLiteral = <ident:IDENT>\\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@@ -239,32 +151,120 @@\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+    \"Syntax Object\": {\n+        \"content\": \"\\n## Objects\\n\\n```text\\nObject = TypeName <id:IDENT>? 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 TypeName\": {\n+        \"content\": \"\\n## Type Names\\n\\n```text\\nTypeName = TypeNameFull | TypeNameExternal | TypeNameShort\\nTypeNameFull = <namespace:IDENT> '.' <name:IDENT>\\nTypeNameExternal = '$' <name:IDENT>\\nTypeNameShort = <name:IDENT>\\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 Property\": {\n+        \"content\": \"\\n## Properties\\n\\n```text\\nProperty = <name:IDENT> ':' ( 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 Signal\": {\n+        \"content\": \"\\n## Signal Handlers\\n\\n```text\\nSignal = <name:IDENT> ('::' <detail:IDENT>)? '=>' '$' <handler:IDENT> '(' <object:IDENT>? ')' (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 Child\": {\n+        \"content\": \"\\n## Children\\n\\n```text\\nChild = ChildAnnotation? Object\\nChildAnnotation = '[' ( ChildInternal | ChildExtension | ChildType ) ']'\\nChildInternal = 'internal-child' <internal-child:IDENT>\\nChildType = <child_type:IDENT>\\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 <name>]` 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 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 = <name:IDENT> ':' (Value  | ('[' (:ref: Value <Syntax 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' '(' <condition:QUOTED> ')'\\nExtAdwBreakpoint = 'setters' '{' ExtAdwBreakpointSetter* '}'\\nExtAdwBreakpointSetter = <object:IDENT> '.' <property:IDENT> ':' 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 = <id:IDENT> ':' 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 = <id:IDENT> ':' 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 = ( <id:IDENT> ':' )? 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 = <item:QUOTED>\\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 = <name:IDENT> ':' 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 <StringObject>.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' '(' ( '-' | '+' )? <value:NUMBER> ( ',' <position:IDENT> ( ',' 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 = <id:IDENT>\\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 = <name:QUOTED>\\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' '=' ( <name:IDENT> | <id:NUMBER> ) '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 Menu\": {\n         \"content\": \"\\n## Menus\\n\\n```text\\nMenu = 'menu' <id:IDENT>? '{' MenuChild* '}'\\nMenuChild = ( MenuSection | MenuSubmenu | MenuItemShorthand | MenuItem )\\nMenuSection = 'section' <id:IDENT>? '{' ( MenuChild | MenuAttribute )* '}'\\nMenuSubmenu = 'submenu' <id:IDENT>? '{' ( MenuChild | MenuAttribute )* '}'\\nMenuItem = 'item' '{' MenuAttribute* '}'\\nMenuAttribute = <name:IDENT> ':' 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+    \"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 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+    \"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 Using\": {\n-        \"content\": \"\\n## GObject Introspection Imports\\n\\n```text\\nUsing = 'using' <namespace:IDENT> <version:NUMBER> ';'\\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+    \"Syntax LookupExpression\": {\n+        \"content\": \"\\n## Lookups\\n\\n```text\\nLookupExpression = '.' <property:IDENT>\\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+        \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/expressions.html#syntax-lookupexpression\"\n     },\n-    \"Syntax TranslationDomain\": {\n-        \"content\": \"\\n## Translation Domain\\n\\n```text\\nTranslationDomain = 'translation-domain' <domain:QUOTED> ';'\\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+    \"Syntax ClosureExpression\": {\n+        \"content\": \"\\n## Closures\\n\\n```text\\nClosureExpression = '$' <name:IDENT> '(' ( Expression ),* ')'\\n```\\n\\nClosure expressions allow you to perform additional calculations that aren't supported in blueprint by writing those calculations as application code. These application-defined functions are created in the same way as [signal handlers](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/objects.html#syntax-signal).\\n\\nExpressions are only reevaluated when their inputs change. Because blueprint doesn't manage a closure's application code, it can't tell what changes might affect the result. Therefore, closures must be *pure*, or deterministic. They may only calculate the result based on their immediate inputs, not properties of their inputs or outside variables.\\n\\nBlueprint doesn't know the closure's return type, so closure expressions must be cast to the correct return type using a [cast expression](https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/expressions.html#syntax-castexpression).\\n\\n\\n\",\n+        \"link\": \"https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/expressions.html#syntax-closureexpression\"\n+    },\n+    \"Syntax CastExpression\": {\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 <string>\\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 }\n"}]}]}]}]}]}