В качестве причины создания проекта называется привязка применяемых в GTK ui-файлов описания интерфейса к формату XML, который перегружен и неудобен для написания или редактирования разметки вручную.

Эта цитата - блестящий пример того, как посредством одного предложения можно снизить IQ целого форума.

Во-первых, XML - это контекстно-свободный язык разметки, который используется в первую очередь для сериализации сложно устроенных данных в текстовое представление по заранее известной схеме.

Во-вторых, вот что важно знать про XML:

  1. Он не предназначен для ручного редактирования через простой текстовый редактор живым человеком. Если вы исправляете его содержимое руками, то это сродни забивания гвоздей микроскопом. Для работы с XML вы должны иметь редактор, который изначально работает с описанными в нем объектами. Для автоматизации преобразования XML-объектов вне редакторов есть XSLT. Ну или в крайнем случае вы создаёте свой редактор и инструментарий с последующим преобразованием, как это сделал автор.
  2. Он не может быть распарсен регулярным выражением, потому что он имеет КС-грамматику. Любая попытка найти что-то в XML посредством работы с ним как со структурированным текстом закончится болью и страданиями. Если вам нужно получить данные оттуда, для этого придуман XPath
  3. Согласно спецификации XML данные фрагменты идентичны:
    Фрагмент 1:
    <elements>
       <item>1</item>
       <item>2</item>
    </elements>
    Фрагмент 2:
    <elements>
       <item>2</item>
       <item>1</item>
    </elements>
    В тегах XML нет порядка. Порядок нужно указывать явно, объявляя его как атрибут к каждому элементу и трактуя так, как хочется. Исходя из этого, утилиты вроде diff не могут быть использованы для XML по смыслу, потому что, помимо лютого вырвиглазного неудобства, будут показывать отличия в XML-файлах, которых нет в реальности.

Использование XML для декларативного описания интерфейсов более чем разумно, вот только это совсем не значит, что они будут писаться людьми от руки. Дальше всё сводится к наличию тулсета по работе с XML и удобства изначального редактора, который его генерирует.

А что мы имеем у разработчика:

  1. diff
  2. VS Code

Я не собираюсь тут критиковать конкретно GTK.Builder, а лишь скажу что 2 вышеозначенных инструмента - главная проблема, почему автору так не удобно жить. И вот он создаёт транслятор на python, на языке в стандартной библиотеке которого чуть ли не самая убогая реализация XML, чтобы пихнуть его в другой редактор. Это, кстати, тоже такой способ пытки, работать с XML в Python, но я уверен, что у автора и на это есть причины, чай интеграция с Builder.

Вообще работа с XML в Linux в целом - дело трудное, потому что стандартная для большинства дистрибутивов libxml2 (изначально часть проекта GNOME, ЕМНИП) - редкостный мусор с точки зрения поддержки современных стандартов. Обычно XML используется там, где нужно работать с большими объемами и/или сложно устроенными данными, для организации удаленного вызова процедур и потоковой проливки объектов с последующей фильтрацией и преобразованием между несколькими разными информационными системами. То что никто не старается привести в порядок libxml2 не удивительно, потому что в GNOME масштабы не те…

Вот и получается идиотство. Есть разработчик Blueprint, который создаёт себе костыль^W автоматизацию, потому что те инструменты, которые есть, его не устраивают (что вполне логично). Есть разработчики GNOME, которых всё устраивает как есть и которые не предоставляют вменяемого инструментария по работе с XML даже за деньги. И есть писатель новости, у которого XML виноват в том, что его не удобно редактировать как INI-образный файлик, которых тьма тьмущая в /etc, потому что понятия не имеет что такое XML, кому и зачем это надо.

Для пущей радости не хватает набега смузихлёбов с JSON, которые понятия не имеют ни о схеме, ни о трансформации, ни о запросов без полной десериализации в ОЗУ.

И еще не хватает откровенных маргиналов с YAML, форматом данных, который перегружен посильнее XML, но в отличии от последнего при большом объеме данных не может быть эффективно прочитан и отредактирован ни человеком, ни компьютером. Ой всё…