GTK 4.22

Я надеюсь, увеличение размера шрифта не приводит к увеличению или расползанию самих объектов. Или размер шрифта выбирается в момент компиляции и неизменен.

Чтобы что?

Чтобы отслеживать вложенность.

Любая struct состоящая из чайлдов со ссылками на свойства и на «методы» будет ок.

Ага, а теперь сделай это на пятидесяти кнопках с пятидесятью картинками, пятидесятью подписями, сотню сигналов, и парой сотен свойств.

Более того, практика показала, что даже человеки легче глазами парсят JSON

Конечно.

{"ac_output_load":{"2026":{"01":{"23":{"22":4.674,"23":318.801},"24":[298.648,327.213,293.127,408.793,392.58,379.076,386.727,406.928,418.327,488.951,904.2,583.006,334.377,302.255,233.449,301.861,349.809,1071.013,1145.765,51.081,0]}}},"ac_input_load":{"2026":{"01":{"23":{"22":0,"23":0},"24":[878.492,566.877,337.19,51.351,0,0,0,0,680.639,1617.592,1877.312,119.112,0,0,0,0,327.724,1356.464,1380.362,22.365,0]}}},"pv_input_load":{"2026":{"01":{"23":{"22":0,"23":0},"24":[1.534,1.512,1.494,0.226,0,0.001,0.066,3.98,47.638,138.1,190.111,208.019,250.757,232.801,216.003,167.294,27.317,2.519,2.249,0.056,0]}}},"bat_discharged":{"2026":{"01":{"23":{"22":6.573,"23":390.12},"24":{"0":127.229,"3":435.852,"4":470.651,"5":465.527,"6":466.625,"7":485.235,"8":289.918,"11":390.322,"12":129.193,"13":111.937,"14":58.259,"15":187.449,"16":232.45,"19":42.405}}}},"bat_capacity":{"2026":{"01":{"23":{"22":0,"23":0},"24":[1.535,1.513,1.495,0.226,0,0.001,0.066,3.984,47.69,138.177,190.21,208.124,250.87,232.891,216.105,167.35,27.318,2.52,2.25,0.056,0]}}},"bat_charged":{"2026":{"01":{"24":{"0":615.081,"1":197.957,"2":7.29,"3":0.765,"8":480.584,"9":1088.238,"10":993.702,"11":47.358,"14":5.104,"16":151.608,"17":215.415,"18":167.13,"19":3.645}}}},"bat_ac_charge":{"2026":{"01":{"24":{"0":615.081,"1":197.957,"2":7.29,"3":0.765,"8":480.584,"9":1088.238,"10":993.702,"11":47.358,"16":151.608,"17":215.415,"18":167.13,"19":3.645}}}},"bat_pv_charge":{"2026":{"01":{"24":{"8":480.584,"9":1088.238,"10":993.702,"11":47.358,"14":5.104,"16":151.608,"17":43.8}}}}}

читабельнее чем

<ac_output_load>
    <2026>
      <01>
        <23>
          <22>4.674</22>
          <23>318.801</23>
        </23>
        <24>298.648</24>
        <24>327.213</24>
        <24>293.127</24>
        <24>408.793</24>
        <24>392.58</24>
        <24>379.076</24>
        <24>386.727</24>
        <24>406.928</24>
        <24>418.327</24>
        <24>488.951</24>
        <24>904.2</24>
        <24>583.006</24>
        <24>334.377</24>
        <24>302.255</24>
        <24>233.449</24>
        <24>301.861</24>
        <24>349.809</24>
        <24>1071.013</24>
        <24>1145.765</24>
        <24>51.081</24>
        <24>0</24>
      </01>
    </2026>
  </ac_output_load>
  <ac_input_load>
    <2026>
      <01>
        <23>
          <22>0</22>
          <23>0</23>
        </23>
        <24>878.492</24>
        <24>566.877</24>
        <24>337.19</24>
        <24>51.351</24>
        <24>0</24>
        <24>0</24>
        <24>0</24>
        <24>0</24>
        <24>680.639</24>
        <24>1617.592</24>
        <24>1877.312</24>
        <24>119.112</24>
        <24>0</24>
        <24>0</24>
        <24>0</24>
        <24>0</24>
        <24>327.724</24>
        <24>1356.464</24>
        <24>1380.362</24>
        <24>22.365</24>
        <24>0</24>
      </01>
    </2026>
  </ac_input_load>
  <pv_input_load>
    <2026>
      <01>
        <23>
          <22>0</22>
          <23>0</23>
        </23>
        <24>1.534</24>
        <24>1.512</24>
        <24>1.494</24>
        <24>0.226</24>
        <24>0</24>
        <24>0.001</24>
        <24>0.066</24>
        <24>3.98</24>
        <24>47.638</24>
        <24>138.1</24>
        <24>190.111</24>
        <24>208.019</24>
        <24>250.757</24>
        <24>232.801</24>
        <24>216.003</24>
        <24>167.294</24>
        <24>27.317</24>
        <24>2.519</24>
        <24>2.249</24>
        <24>0.056</24>
        <24>0</24>
      </01>
    </2026>
  </pv_input_load>
  <bat_discharged>
    <2026>
      <01>
        <23>
          <22>6.573</22>
          <23>390.12</23>
        </23>
        <24>
          <0>127.229</0>
          <3>435.852</3>
          <4>470.651</4>
          <5>465.527</5>
          <6>466.625</6>
          <7>485.235</7>
          <8>289.918</8>
          <11>390.322</11>
          <12>129.193</12>
          <13>111.937</13>
          <14>58.259</14>
          <15>187.449</15>
          <16>232.45</16>
          <19>42.405</19>
        </24>
      </01>
    </2026>
  </bat_discharged>
  <bat_capacity>
    <2026>
      <01>
        <23>
          <22>0</22>
          <23>0</23>
        </23>
        <24>1.535</24>
        <24>1.513</24>
        <24>1.495</24>
        <24>0.226</24>
        <24>0</24>
        <24>0.001</24>
        <24>0.066</24>
        <24>3.984</24>
        <24>47.69</24>
        <24>138.177</24>
        <24>190.21</24>
        <24>208.124</24>
        <24>250.87</24>
        <24>232.891</24>
        <24>216.105</24>
        <24>167.35</24>
        <24>27.318</24>
        <24>2.52</24>
        <24>2.25</24>
        <24>0.056</24>
        <24>0</24>
      </01>
    </2026>
  </bat_capacity>
  <bat_charged>
    <2026>
      <01>
        <24>
          <0>615.081</0>
          <1>197.957</1>
          <2>7.29</2>
          <3>0.765</3>
          <8>480.584</8>
          <9>1088.238</9>
          <10>993.702</10>
          <11>47.358</11>
          <14>5.104</14>
          <16>151.608</16>
          <17>215.415</17>
          <18>167.13</18>
          <19>3.645</19>
        </24>
      </01>
    </2026>
  </bat_charged>
  <bat_ac_charge>
    <2026>
      <01>
        <24>
          <0>615.081</0>
          <1>197.957</1>
          <2>7.29</2>
          <3>0.765</3>
          <8>480.584</8>
          <9>1088.238</9>
          <10>993.702</10>
          <11>47.358</11>
          <16>151.608</16>
          <17>215.415</17>
          <18>167.13</18>
          <19>3.645</19>
        </24>
      </01>
    </2026>
  </bat_ac_charge>
  <bat_pv_charge>
    <2026>
      <01>
        <24>
          <8>480.584</8>
          <9>1088.238</9>
          <10>993.702</10>
          <11>47.358</11>
          <14>5.104</14>
          <16>151.608</16>
          <17>43.8</17>
        </24>
      </01>
    </2026>
  </bat_pv_charge>

И это я тебе показал JSON всего лишь на полтора килобайта и пяток объектов.

Конечно.

{
	"ac_output_load": {
		"2026": {
			"01": {
				"23": {
					"22": 4.674,
					"23": 318.801
				},
				"24": [
					298.648,
					327.213,
					293.127,
					408.793,
...

Это не JSON

Я бы сказал, что то - отстой, что - то отстой. И вообще есть блюпринт, камбала и ещё окончательно не сдохший glade. На монгольский йенг это программирование в xml/json/yaml/ещё-какая-фигня.

Я джейсоны пять лет по API гоняю и в бд, не надо меня не форматированный пугать. Из XML задолбаешься атрибуты тегов парсить.

Я джейсоны пять лет по API гоняю и в бд, не надо меня не форматированный пугать. Из XML задолбаешься атрибуты тегов парсить.

Нахрена тебе парсить атрибуты тегов?

Мы говорим за разметку интерфейса, а не программирование с XML'ом.

Фу. GTK3 последний нормальный тулкит впринципе.

скинь скрин своего десктопа, а мы потом решим что хуже

рад за всех пользователей современных DE

Для CAD нужен размер экрана, разрешение будет вторично.

Я не про твои потуги в TinkerCAD, а про профессиональное применение.

только нормальный типа либры:

Ущербное UI, на тебя сразу вываливают 100500 кнопок, из которых тебе нужно 5-15 штук максимум в 99% случаев. Причем, то что самое нужное ещё и спрятано за 3-4 кликами.

Wireshark

С точки зрения сложности и навороченности интерфейся Wireshark подобен рельсу - такой же прямой и простой.

читабельнее чем

LOL! Давно я такую тупую разводку не видел. Нет, Shadow прав и JSON преимущество при парсинге человеком. Ему только комментов не хватает, приходится ключом ‘rem: «Комментарий»’ выкручиваться.

1. Какое отношение это имеет к проектированию UI?

2. Попробуй разметить интерфейс своим JSON. Если не знаешь синтаксис GTK-UI - можешь сымитировать HTML.

 <object class="GtkWindow" id="window1">
    <property name="title" translatable="yes">Stack</property>
    <child>
      <object class="GtkGrid">
        <property name="visible">1</property>
        <child>
          <object class="GtkStackSwitcher">
            <property name="visible">1</property>
            <property name="stack">stack</property>
            <property name="halign">center</property>
          </object>
          <packing>
            <property name="left_attach">0</property>
            <property name="top_attach">0</property>
          </packing>
        </child>
        <child>
          <object class="GtkStack" id="stack">
            <property name="visible">1</property>
            <property name="can_focus">1</property>
            <property name="transition-type">crossfade</property>
            <child>
              <object class="GtkImage">
                <property name="visible">1</property>
                <property name="margin-top">20</property>
                <property name="margin-bottom">20</property>
                <property name="icon-name">gtk3-demo</property>
              </object>
              <packing>
                <property name="name">page1</property>
                <property name="title" translatable="yes">Page 1</property>
              </packing>
            </child>
            <child>
              <object class="GtkCheckButton">
                <property name="label" translatable="yes">Page 2</property>
                <property name="visible">1</property>
                <property name="can_focus">1</property>
                <property name="draw_indicator">1</property>
                <property name="halign">center</property>
                <property name="valign">center</property>
              </object>
              <packing>
                <property name="name">page2</property>
                <property name="title" translatable="yes">Page 2</property>
              </packing>
            </child>
            <child>
              <object class="GtkSpinner">
                <property name="visible">1</property>
                <property name="halign">center</property>
                <property name="valign">center</property>
                <property name="active">1</property>
              </object>
              <packing>
                <property name="name">page3</property>
                <property name="icon-name">face-laugh-symbolic</property>
              </packing>
            </child>
          </object>
          <packing>
            <property name="left_attach">0</property>
            <property name="top_attach">1</property>
          </packing>
        </child>
      </object>
    </child>
  </object>

А теперь то же самое разметь своим JSON.

Если вдруг ты не знаком с форматом JSON и тебя дернет заюзать онлайн конвертер - спускайся сразу вниз, и рассказывай какая из читабельных закорючек }}}} какой блок закрывает. А потом вставь новый блок в блок.

Це усьо потому что ты путаешь программирование и разметку, т.е. обсуждаешь передачу данных, и тебе кажется что жсон круче. Для передачи он и вправду круче.

Но для блочной разметки - теговый блочный язык, где блок открывается именем и закрывается именем - подходит лучше всего.

Но для блочной разметки - теговый блочный язык, где блок открывается именем и закрывается именем - подходит лучше всего.

Еще более тупая разводка. Спокойно копируешь блок {…} в нужное месте, не забывая добавить его родителя и «,». Всё.

А если тебя так напрягает }}}}, используй команду

cat my_fuckin.json | jq .

и будет тебе счастье - и разметка и подсветка синтаксиса. Не благодари.

Будь добр отвечать на мысль, а не на два выборочных слова с мысли - тогда продолжим дискуссию.

тогда продолжим дискуссию

Скатертью, как говорится, по жопе.

Рассказ про то как удобен xml по сравнению с json можешь оставить своей матушке или девушке, а не сугубому практику типа меня, начинавшему с императивного использования xml в своем коде и пришедшего, в итоге, к выбору между json и ini. Suum cuique.

Какой json, какой ini, ты совсем нейроразнообразный что ли?

Речь идет о РАЗМЕТКЕ UI. Что тебе не понятного в этих двух словах?

        <child>
          <object class="GtkStackSwitcher">
            <property name="visible">1</property>
            <property name="stack">stack</property>
            <property name="halign">center</property>
          </object>
          <packing>
            <property name="left_attach">0</property>
            <property name="top_attach">0</property>
          </packing>
        </child>

Какой только херни не придумывают, только бы не пользоваться подмножеством HTML/CSS

да проблема xml не в том что идея плоха, а в том во что всю идею превратили. Если использовать xml для «структуры» в небольших документах и бить по палкой по рукам людям которые хотят чего-то большего, то имхо вполне можно пользоваться. json - простой, но есть свои минусы.

ps: тоже познал всю боль xslt/xml

По моему опыту, это будет несколько тысяч строк только с gtk_box_new -> gtk_button_new -> gtk_image_new_from_file только на рисование.

Будет одна функция gtk_image_button, вызывающая вышеописанное. И, например, на блок кнопок MSPAG будет одна функция. А в рисовалках сделать свой параметрический виджет почти нигде нельзя и приходится все эти box/button/image каждый раз вручную описывать.

Речь идет о РАЗМЕТКЕ UI. Что тебе не понятного в этих двух словах?

Мусьё, пофиг о какой нагрузке в описалове идет речь - если должен читать человек, то xml он читать не должен, ибо ему от этого больно. Ты вот обчитался, похоже, и теперь просто перестал понимать простые человеческие слова

Вот как выглядит одна из менюх гимпа: https://ibb.co/cKrD661q

Здесь только перечисление идентификаторов. Всё от наименования этих элементов, до картинок рядом и состояния, где то ещё.

Я бы сказал последний нормальный GTK-2

за исключением конечно конских размеров заголовков

Я в терминале вот такой лапшой смог порезать табы до нормальной высоты. С помощью нейронки(сам я в гткашном css не особо шарю) и какой-то матери.

tabbox {
  min-height: 0px;
  padding-top: 0px;
  padding-bottom: 0px;
}

scrolledwindow {
  min-height: 0px;
  padding-top: 0px;
  padding-bottom: 0px;
}
tabbar tab {
  padding-top: 2px;
  padding-bottom: 2px;
  min-height: 0px;
}

/* 1) фон/область табов */
tabbar tabbox {
  min-height: 0;
  padding-top: 0;
  padding-bottom: 0;
margin-left: -10px;
padding-left: 0;
}

/* 2) сами вкладки в libadwaita обычно кнопки */
tabbar button {
  min-height: 0;
  padding-top: 2px;
  padding-bottom: 2px;
padding-left: 0;
}

/* 3) внутренние контейнеры кнопок тоже могут задавать высоту */
tabbar button > box,
tabbar button > box > label,
tabbar button > box > image {
  margin-top: 0;
  margin-bottom: 0;
  padding-top: 0;
  padding-bottom: 0;
padding-left: 0;
}

Я это к чему? Если уж даете css для настройки внешнего вида, то дайте его полноценно(примерно как это в дотнете в xaml сделано), а то тут нельзя, там нельзя и приходится извращаться с отрицательными маргинами.

PS: Почему-то блоки перестали сворачиваться.

не заметил разницы. Я бы вообще предпочел от заголовков отказаться, в документации к river есть такой костыль:

/* No (default) title bar on wayland */                                                                                
headerbar.default-decoration {                                                                                         
  /* You may need to tweak these values depending on your GTK theme */                                                 
  margin-bottom: 50px;                                                                                                 
  margin-top: -100px;                                                                                                  
}                                                                                                                      
                                                                                                                       
/* rm -rf window shadows */                                                                                            
window.csd,             /* gtk4? */                                                                                    
window.csd decoration { /* gtk3 */                                                                                     
  box-shadow: none;                                                                                                    
}

в некоторых приложениях сработало, например в pcmanfm (gtk3) и transmission (gtk4). Еще радиуса попробовал убрать, мой gtk.css

gtk3 конечно тяжёлый, но он очень много всякого положительного и удобного принёс, так что не соглашусь.

Какой только херни не придумывают, только бы не пользоваться подмножеством HTML/CSS

Да пофиг в целом. Важна общая мысль - теговая разметка для описания структур UI подходит намного лучше, чем комбинация из закорючек.

Будет одна функция gtk_image_button

С какого это перепугу?

В коде будет столько строк, сколько элементов будет видно на экране. И не потому что нельзя сделать одну функцию или класс делающий все и сразу, а потому что программирование подразумевает доступ к каждому из элементов.

Вывел ты GtkLabel - ок. А потом понадобилось изменить его, или любое из его свойств. Все равно обращение будет.

Просто возьми любой ЯП с прибинденным GTK через классы, и поймешь о чем я. К примеру идеальный язык программирования PHP.

<?php
Gtk::init();
function GtkWindowDestroy($widget=NULL, $event=NULL)
{
	Gtk::main_quit();
}
$win = new GtkWindow();
$win->set_default_size(640, 480);
$win->connect("destroy", "GtkWindowDestroy");
$box = new GtkBox(GtkOrientation::VERTICAL, 20);
$win->add($box);
$win->show_all();
Gtk::main();

Что тебе дало ООП? Тебе перестало быть нужным выставлять желаемый размер окна? Или добавлять в это окно GtkBox? Нет.

Просто теперь вместо gtk_container_add($win, $box) ты делаешь $win->add($box) - но все равно делаешь.

То есть замена на ООП не принесла ни одного выхлопа.

Мусьё, пофиг о какой нагрузке в описалове идет речь - если должен читать человек, то xml он читать не должен, ибо ему от этого больно.

Человеки придумали что удобнее читать XML. И не только читать, а и парсить как ни странно.

Я бы сказал последний нормальный GTK-2

Нет, все таки третий.

Во-первых, переход на CSS - мастхев. До сих пор не понимаю кедерастов, как они живут в своем манямирке с их этим как его там ...

Во-вторых, мониторы уже давно перешагнули за 1024х768, а с HiDPI у GTK2 боль - скажет любой у кого относительно древний ноут с 1920х1080 на 13". Без лупы работать не получается.

В-третьих, устройства ввода. Они как ни странно тоже пополнились новыми девайсами, которые могут определять не только кнопка true\false, а еще и на сколько именно «true» - сильно или не очень.

В-четвертых, адаптивность. Тебе как пользователю конечно пофигу, а вот программерам извращаться с математическим вычислением пропорций - было так себе. Пример: у тебя есть иконка размера которой ты не знаешь (так бывает, да), тебе ее нужно сжать так чтоб она уместилась в поле. В GTK2 - тебе нужно было определять ее размер, высчитывать пропорцию, отталкиваться от ширины или высоты, и тд итп. В GTK3 - ты просто указываешь желаемую ширину (или высоту), второй параметр в -1, и оно само посчитает пропорции.

В-пятых, появились полезности. И если с CSD еще можно поспорить, то вот Stack, и ListBox - однозначно круто.

- - -

Могу назвать еще примерно 20 полезностей по сравнению с GTK2, если захочешь ;)

а потому что программирование подразумевает доступ к каждому из элементов.

Так у box есть children. Или, если очень хочется, можешь в функции в глобальный хеш по имени все указатели сложить. Будет как id из рисовалки. Или по нормальному в поле структуры.

Кстати, а как в GTK 4.22 (комментарий) поменять видимость для GtkCheckButton из этого описания?

Вывел ты GtkLabel - ок. А потом понадобилось изменить его, или любое из его свойств. Все равно обращение будет.

Что собираешься менять, то и записываешь. В соответствующее поле структуры, отвечающей за работу с интерфейсом. И искать эту Label по автоматически сгенерированному идентификатору после того, как дизайнер интерфейс натыкал, тоже не особо удобно.

Какой только ошибочной херни человеки не придумали… Сначала они придумали SGML, но он оказался слишком. Поэтому, чтобы джавистам было чем заняться на рабочем месте они его упростили и так появился XML. В качестве занятия всего доступного времени язык оказался годным, а в качестве удобного инструмента для описания структуры - так себе.

Человеки придумали что удобнее читать XML. И не только читать, а и парсить как ни странно.

Человеки придумали, что иерархические данные удобнее читать деревом. А рисуется оно ASCII отступами или графическим элементом, неважно.

Уникума, который умеет прочитать XML с глубиной вложенности хотя бы 7, написанный одной строкой, я не встречал.

По сравнение с JSON у XML есть только одно преимущество: строковые атрибуты. Если они у данных есть, лучше XML, если нет, то JSON.

Так у box есть children. Или, если очень хочется, можешь

Ты вот это специально, да?)))

Ну окей. У box есть children и в функциональном программировании и в ООП.

Что собираешься менять, то и записываешь.

Ну окей. Что я собираюсь менять то и записываю и в функциональном программировании, и в ООП.

- - -

В моем комментарии нет ничего про обучение меня программированию под GTK.

Здесь есть утверждение того, что ООП не привнесет ничего нового и ничего удобного в силу устройства самого GTK.

В качестве занятия всего доступного времени язык оказался годным, а в качестве удобного инструмента для описания структуры - так себе.

Это ты расскажешь Майкрософту и сотне компаний помельче, использующих XML в описаниях структур. И в отличие от твоего красноглазикса, это - сериос бузинесс.

Человеки придумали, что иерархические данные удобнее читать деревом. А рисуется оно ASCII отступами или графическим элементом, неважно.

Конечно же важно.

Человек воспринимает слова. Воспринимает контекстно.

Блок "begin of #function" и "end of #function" читабельнее чем " #function { " и " } ".

Уникума, который умеет прочитать XML с глубиной вложенности хотя бы 7, написанный одной строкой, я не встречал.

Одной строкой передают данные. Разметка делается в колонку, тегоподобную разметку намного проще редактировать.

<Дом Васи>
 <Комната Пети>
  Гитара
 </Комната Пети>
 <Комната Маши>
  Баян
  <Шкаф Маши>
   Трусы
  </Шкаф Маши>
 </Комната Маши>
</Дом Васи>

Если тебе нужно добавить второй шкаф в комнату Маши, то ты просто ищешь ее имя с закрывающим слешем, и добавляешь второй шкаф перед закрывающим тегом.

Если тебе нужно сделать то же самое в JSON, то ты как дурак начинаешь считать закрывающиеся закорлючки, или героически писать велосипед под свой vim\geany\kate\notepad++ (нужное подчеркнуть), чтобы выделить блок цветом.

JSON'овские «удобства» вида «так, а это \n - у нас часть данных, или красивый перевод строки редактора» - пока опустим.

Ну окей. Что я собираюсь менять то и записываю и в функциональном программировании, и в ООП.

Я не против функционального. Я против «программирования» на XML. Потому что в нормальной программе, даже на функциональном Haskell, я могу написать функцию add_image_button, которая мне сделает три блока Gtk, а в XML только копипастить, потому что определение новых тегов в XML невозможно.

Человек воспринимает слова. Воспринимает контекстно.

Блок «begin of #function» и «end of #function» читабельнее чем " #function { " и " } ".

???

Вот ты сейчас серьёзно? Тебе может и «квадрат суммы а и б равен сумме квадрата а, удвоенного произведения а и б и квадрата б» читабельнее, чем «(a+b)² = a² + 2ab + b²»? Если ты только слова воспринимаешь.

Последний раз словами пытались писать в КОБОЛе.

COMPUTE-GROSS-PAY.
    IF HOURS-WORKED > 40 THEN
        MULTIPLY PAY-RATE BY 1.5 GIVING OVERTIME-RATE
        MOVE 40 TO REGULAR-HOURS
        SUBTRACT 40 FROM HOURS-WORKED GIVING OVERTIME-HOURS
        MULTIPLY REGULAR-HOURS BY PAY-RATE GIVING REGULAR-PAY
        MULTIPLY OVERTIME-HOURS BY OVERTIME-RATE
            GIVING OVERTIME-PAY
        ADD REGULAR-PAY TO OVERTIME-PAY GIVING GROSS-PAY
    ELSE
        MULTIPLY HOURS-WORKED BY PAY-RATE GIVING GROSS-PAY
    END-IF

Это идеальный язык?

Если тебе нужно сделать то же самое в JSON, то ты как дурак начинаешь считать закрывающиеся закорлючки, или героически писать велосипед под свой vim\geany\kate\notepad++ (нужное подчеркнуть), чтобы выделить блок цветом.

Какой велосипед? В любом нормальном редакторе для программистов есть переход на парную скобку (в vi %, в Emacs C-M-f).

и добавляешь второй шкаф перед закрывающим тегом

И пишешь почти вдвое больше слов, чем необходимо для информации.

JSON’овские «удобства» вида «так, а это \n - у нас часть данных, или красивый перевод строки редактора» - пока опустим.

Так это же в XML проблема. Как ввести не «Баян», а "Баян " или «\n Баян \n».

Я не против функционального. Я против «программирования» на XML.

На XML никто не программирует.

Программируют на ЯП, а XML'ем размечают интерфейс, поскольку визуально блочная разметка понятней чем функциональная - видно где она начинается, и где она заканчивается.

определение новых тегов в XML невозможно

Определять новые теги в XML не нужно, как я уже написал выше - здесь не программируют XML'ем, а размечают интерфейс, теги лишь повторяют структуру GTK.

<object class>, <property name>, <attribute name>, <style>, <child>, <packing>, <signal name>. Остальное - их комбинация.

Так это же в XML проблема. Как ввести не «Баян», а «Баян » или «\n Баян \n».

Здесь обсуждается не XML, а разметка для GTK-приложения.

Определять новые теги в XML не нужно, как я уже написал выше - здесь не программируют XML’ем, а размечают интерфейс, теги лишь повторяют структуру GTK.

Так я про это и пишу. Надо сделать десять кнопок с цифрами и вместо

for(i = 0; i <= 9; i++) add_num_button(i);

пишут портянку на три страницы.

Последний раз я такую жуть на Delphi видел. Там ещё и обработчики автоматически генерировались и программа состояла из функций с именами типа Button253Click. И каждая однотипная кнопка вырисована индивидуально.

Сейчас даже HTML генерируют, а не размечают в нём интерфейс вручную.

KDE последнее пристанище для людей которые видят монитор. Надеюсь, в следущей версии будут менюшки и тайтл бары во весь экран, чтобы точно разглядеть можно было.

пишут портянку на три страницы.

Пишут не поэтому. 10 кнопок в цикле - это конечно хорошо. А теперь давай как в калькуляторе - 3 столбца, 3 рядка, 9 кнопок без авторасширения, 0 - с авто.

Циклы - это конечно хорошо, но это не про интерфейс.

Сейчас даже HTML генерируют, а не размечают в нём интерфейс вручную.

Ты конечно будешь смеяться, но в вебне используется тот же самый принцип: разметка сайта статична при помощи темплейта, а контент добавляется динамически. Если бы не этот принцип, изменение «темы сайта» было бы невозможно без переписывания всего кода.

Тебе никто не мешает рисовать твои кнопки хоть циклом, хоть вхардкоженными функциями.

Просто когда у тебя их станет пушисто - ты начнешь путаться, какое свойство и какой обработчик сигнала принадлежит к какой кнопке, не говоря уже о том чтоб добавить новую кнопку между вот той, и другой.

Раньше я тоже не понимал смысла этих разметок. Сейчас, когда начал заниматься вплотную - понял преимущества.

Попробуй разметить интерфейс своим JSON. Если не знаешь синтаксис GTK-UI - можешь сымитировать HTML.

{
  "class": "GtkWindow",
  "id": "window1",
  "property": [
    {
      "title": "Stack",
      "translatable": "yes"
    }
  ],
  "child": {
    "class": "GtkGrid",
    "property": [{ "visible": 1 }],
    "children": [
      {
        "class": "GtkStackSwitcher",
        "property": [
          { "visible": 1 },
          { "stack": "stack" },
          { "halign": "center" }
        ],
        "packing": [
          { "left_attach": 0 },
          { "top_attach": 0 }
        ]
      },
      {
        "class": "GtkCheckButton",
        "property": [
          {
            "label": "Page 2",
            "translatable": "yes"
          },
          { "visible": 1 },
          { "can_focus": 1 },
          { "draw_indicator": 1 },
          { "halign": "center" },
          { "valign": "center" }
        ],
        "packing": [
          { "name": "page2" },
          {
            "title": "Page 2",
            "translatable": "yes"
          }
        ]
      },
      {
        "class": "GtkSpinner",
        "property": [
          { "visible": 1 },
          { "halign": "center" },
          { "valign": "center" },
          { "active": 1 }
        ],
        "packing": [
          { "name": "page3" },
          { "icon-name": "face-laugh-symbolic" }
        ]
      }
    ]
  },
  "packing": [
    { "left_attach": 0 },
    { "top_attach": 1 }
  ]
}

а разметка для GTK-приложения

Так давай к нему примеры и приводить, а не к шкафам Маши. Вот есть GTK 4.22 (комментарий), надо добавить в GtkGrid ещё один элемент. Как в </child></object></child></object> найти куда?

Вот мой JSON: GTK 4.22 (комментарий) здесь виден массив элементов и явно виден его конец.

Пишут не поэтому. 10 кнопок в цикле - это конечно хорошо. А теперь давай как в калькуляторе - 3 столбца, 3 рядка, 9 кнопок без авторасширения, 0 - с авто.

Вот моё старое:

https://github.com/Kalimehtar/gtk-cffi/blob/master/examples/calc-cffi.lisp