{"diffoscope-json-version": 1, "source1": "/srv/reproducible-results/rbuild-debian/r-b-build.Su8vTN7b/b1/blueprint-compiler_0.16.0-1_i386.changes", "source2": "/srv/reproducible-results/rbuild-debian/r-b-build.Su8vTN7b/b2/blueprint-compiler_0.16.0-1_i386.changes", "unified_diff": null, "details": [{"source1": "Files", "source2": "Files", "unified_diff": "@@ -1,2 +1,2 @@\n \n- 765716674c5c906897aebc4f81beed57 69720 gnome optional blueprint-compiler_0.16.0-1_all.deb\n+ 353e76b46b1dca7a4e77881977b62c16 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     2756 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    66768 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,64 +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 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-    },\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<GObject.Object>;\\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 = <first:IDENT> '|' ( <rest:IDENT> )|+\\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 = ( '_' '(' <string:QUOTED> ')' ) | ( '\\\\C_' '(' <context:QUOTED> ',' <string:QUOTED> ')' )\\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     \"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@@ -75,18 +19,14 @@\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 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     \"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@@ -191,14 +131,38 @@\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 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 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 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@@ -262,9 +226,45 @@\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 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+    },\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<GObject.Object>;\\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 = <first:IDENT> '|' ( <rest:IDENT> )|+\\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 = ( '_' '(' <string:QUOTED> ')' ) | ( '\\\\C_' '(' <context:QUOTED> ',' <string:QUOTED> ')' )\\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"}]}]}]}]}]}