История изменений

Ох и понаписали за ночь.

Поехали по порядку:

беглый взгляд показывает наличие gtk_widget_get_preferred_height_for_width() — т.е. «примитивным рекурсивным обходом дерева с дерганием конструкторов на каждом узле» дело, похоже, не ограничивается

Мне кажется, ты как-то путаешь конфиг и собственную семантику виджета. У виджета есть свойства, методы, слоты сигналов. (Как минимум, из всего этого свойства и слоты в gtk run-time inspectable). Таблица - это такой контейнер с интересной семантикой, и всё, что от него нужно, он делает.

Но мы можем эту таблицу создавать, надрачивая gtk_grid_*(blabla, blabla), а можем завернуть всё в файл конфигурации, и пусть библиотека сама с этим разбирается. Способ с конфигом — понятно — и гибче, и концептуально мощнее. Но при этом в обработке конфига никакой магии нет, это действительно тупой обход дерева.

как мне избавится от идиотской неудаляемой панели инструментов в аппликухе — чтобы это было так же просто, как написать css selector (а то и вообще без этого, через гуй stylish-а или аналогов?) а как мне сделать кнопочку, которая эту панель включает-выключает? в хтмл-прокси это простенький регексп, который в нужном месте добавляет кнопку с маленьким ява-скриптом

Для этого достаточно, например, в gtk дать стандартный способ пользователю вмешаться в логику построения дерева виджетов и их свойств при помощи задания правил на каком-нибудь декларативном языке. Правда после этого половина существующих приложений развалится, не ожидая такого подвоха. Но это я к тому, что это в принципе возможно и при помощи application-side тулкита.

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

Проблема в том, что абстрагироваться от дополнительных примочек ты можешь («нам нужно просто поле ввода, а насколько оно удобно сделано, пусть у сервера голова болит»), а вот конкретизироваться на нах — нет. Потому что если в этом общем знаменателе нет, например, вот такого няшного поля ввода со списком, иконками и свитоперделками, то никак ты его и не получишь. Единственный способ — закачивать код виджета на дисплей, т.е. JS. И вся совместимость тулкитов на этом и заканчивается.

Теперь про недостатки и достоинства. Сначала про достоинства. Преимущества дескриптивного подхода к GUI ты уже описывал тут, посмотрим, что будет, если их развить:

1. GUI не должно быть stateless, должна быть возможность прямо из декларативного представления интерфейса работать с его состоянием. По типу «нажали на кнопочку, и представление данных в рабочей области сменилось с таблицы на сетку иконок». Какой-то язык выборки узлов интерфейса, по типу того, что используется в jquery, дополненный возможностью изменять состояние этих узлов. Пример в псевдокоде:

<a href="query: #dataarea::class(list_view)" group="view_mode" class="radioitem">Список<a/> | <a href="query: #dataarea::class(grid_view)" group="view_mode" class="radioitem">Сетка<a/>

2. Львиная доля скриптов — это тупо «отправить запрос приложению и подставить результат в какой-нибудь узел». Это тоже можно описывать декларативно, без километров императивщины на JS:

<a href="query: #dataarea::content(application::page(1))">Предыдущая страница</a> |
<a href="query: #dataarea::content(application::page(3))">Следующая страница</a>

На этом преимущества заканчиваются.

Про узкие места. Какие у нас могут быть варианты интерфейса:

1. Пусть у нас есть простое приложение, которое по интерфейсу не сильно отличается от сайта библиотеки Мошкова. Всё отлично, всё работает. Это такой своеобразный юниксвей: один компонент умеет рисовать интерфейсы по конфигу, второй реализует прикладную логику, между ними лежит чисто текстовый протокол, доступный для вмешательства пользователем, при необходимости.

2. Всё то же самое, но облагороженное с целью улучшения эргономики. Более интерактивные компоненты, обновление без полной перезагрузки гуя и т.п. Всё это делается сейчас на JS, но всё это можно делать при помощи декларативного языка.

3. А узкие места возникают как раз тогда, этих возможностей становится не достаточно. Даже на уровне упомянутого «няшного поля ввода».

Проблема первая: чтобы «расширить» GUI, нам нужен мощный тьюринг-полный язык на дисплее. Это сразу на корню подрезает саму концепцию «простого декларативного интерфейса».

Проблема вторая: мы ничего не знаем о том, как виджеты реализованы дисплеем, и не сможем сделать на уровне look and feel «так же, но лучше». В качестве костыля придётся переопределять на собственные ВООБЩЕ ВСЕ виджеты и натягивать на них свой собственный look.

Проблема третья: пройдёт 2 года, все разработчики подсядут на иглу этого языка, и никому не нужена будет развитая семантика декларативного языка. (Впрочем, это точно так же, как с иксами. Есть XRender и OGL, но криворукому разработчику не осилить их правильное использование, лучше повозмущаться про «иксы устарели ололо».) Даже те приложения, которым бы за глаза хватило декларативного языка, будут неюзабельны без кучи императивных костылей. Ну и производительность соответствующая.

4. Кроме того, есть еще проблема эффективного взаимодействия с дисплеем для вывода «быстрой» графики. Растровые и векторные изображения, видеопоток, OGL и т.п. Но это в принципе решаемо.

И еще: всё это требует очень аккуратного программирования со стороны авторов фреймворков и прикладных программ. Потому что интерфейс дисплея будет предлагать как высокоуровневые возможности, в семантике готовых виджетов, так и возможности для сырой обработки ввода и вывода. Будет очень много вариантов, как можно это API использовать НЕПРАВИЛЬНО. (Частный случай я выше называл.) Соответственно, это налагает довольно высокие требования на чувство архитектуры у прикладного программиста.

Ох и понаписали за ночь.

Поехали по порядку:

беглый взгляд показывает наличие gtk_widget_get_preferred_height_for_width() — т.е. «примитивным рекурсивным обходом дерева с дерганием конструкторов на каждом узле» дело, похоже, не ограничивается

Мне кажется, ты как-то путаешь конфиг и собственную семантику виджета. У виджета есть свойства, методы, слоты сигналов. (Как минимум, из всего этого свойства и слоты в gtk run-time inspectable). Таблица - это такой контейнер с интересной семантикой, и всё, что от него нужно, он делает.

Но мы можем эту таблицу создавать, надрачивая gtk_grid_*(blabla, blabla), а можем завернуть всё в файл конфигурации, и пусть библиотека сама с этим разбирается. Способ с конфигом — понятно — и гибче, и концептуально мощнее. Но при этом в обработке конфига никакой магии нет, это действительно тупой обход дерева.

как мне избавится от идиотской неудаляемой панели инструментов в аппликухе — чтобы это было так же просто, как написать css selector (а то и вообще без этого, через гуй stylish-а или аналогов?) а как мне сделать кнопочку, которая эту панель включает-выключает? в хтмл-прокси это простенький регексп, который в нужном месте добавляет кнопку с маленьким ява-скриптом

Для этого достаточно, например, в gtk дать стандартный способ пользователю вмешаться в логику построения дерева виджетов и их свойств при помощи задания правил на каком-нибудь декларативном языке. Правда после этого половина существующих приложений развалится, не ожидая такого подвоха. Но это я к тому, что это в принципе возможно и при помощи application-side тулкита.

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

Проблема в том, что абстрагироваться от дополнительных примочек ты можешь («нам нужно просто поле ввода, а насколько оно удобно сделано, пусть у сервера голова болит»), а вот конкретизироваться на нах — нет. Потому что если в этом общем знаменателе нет, например, вот такого няшного поля ввода со списком, иконками и свитоперделками, то никак ты его и не получишь. Единственный способ — закачивать код виджета на дисплей, т.е. JS. И вся совместимость тулкитов на этом и заканчивается.

Теперь про недостатки и достоинства. Сначала про достоинства. Преимущества дескриптивного подхода к GUI ты уже описывал тут, посмотрим, что будет, если их развить:

1. GUI не должно быть stateless, должна быть возможность прямо из декларативного представления интерфейса работать с его состоянием. По типу «нажали на кнопочку, и представление данных в рабочей области сменилось с таблицы на сетку иконок». Какой-то язык выборки узлов интерфейса, по типу того, что используется в jquery, дополненный возможностью изменять состояние этих узлов. Пример в псевдокоде:

<a href="query: #dataarea::class(list_view)" group="view_mode" class="radioitem">Список<a/> | <a href="query: #dataarea::class(grid_view)" group="view_mode" class="radioitem">Сетка<a/>

2. Львиная доля скриптов — это тупо «отправить запрос приложению и подставить результат в какой-нибудь узел». Это тоже можно описывать декларативно, без километров императивщины на JS:

<a href="query: #dataarea::content(application::page(1))">Предыдущая страница</a> |
<a href="query: #dataarea::content(application::page(3))">Следующая страница</a>

На этом преимущества заканчиваются.

Про узкие места. Какие у нас могут быть варианты интерфейса:

1. Пусть у нас есть простое приложение, которое по интерфейсу не сильно отличается от сайта библиотеки Мошкова. Всё отлично, всё работает. Это такое своеобразный юниксвей: один компонент умеет рисовать инерфейсы по конфигу, второй реализует прикладную логику, между ними лежит чисто текстовый протокол, доступный для вмешательства пользователем, при необходимости.

2. Всё то же самое, но облагороженное с целью улучшения эрногомики. Более интерактивные компоненты, обновление без полной перезагрузки гуя и т.п. Всё это делается сейчас на JS, но всё это можно делать при помощи декларативного языка.

3. А узкие места возникают как раз тогда, этих возможнсотей становится не достаточно. Даже на уровне упомянутого «няшного поля ввода».

Проблема первая: чтобы «расширить» GUI, нам нужен мощный тьюринг-полный язык на дисплее. Это сразу на корню подрезает саму концепцию «простого декларативного интерфейса».

Проблема вторая: мы ничего не знаем о том, как виджеты реализованы дисплеем, и не сможем сделать на уровне look and feel «так же, но лучше». В качестве костыля придётся переопределять на собственные ВООБЩЕ ВСЕ виджеты и натягивать на них свой собственный look.

Проблема третья: пройдёт 2 года, все разработчики подсядут на иглу этого языка, и никому не нужена будет развитая семантика декларативного языка. (Впрочем, это точно так же, как с иксами. Есть XRender и OGL, но криворукому разработчику не осилить их правильное использование, лучше повозмущаться про «иксы устарели ололо».) Даже те приложения, которым бы за глаза хватило декларативного языка, будут неюзабельны без кучи императивных костылей. Ну и производительность соответствующая.

4. Кроме того, есть еще проблема эффективного взаимодействия с дисплеем для вывода «быстрой» графики. Растровые и векторные изображения, видеопоток, OGL и т.п. Но это в принципе решаемо.

И еще: всё это требует очень аккуратного программирования со стороны авторов фреймворков и прикладных программ. Потому что интерфейс дисплея будет предлагать как высокоуровневые возможности, в семантике готовых виджетов, так и возможности для сырой обработки ввода и вывода. Будет очень много вариантов, как можно это API использовать НЕПРАВИЛЬНО. (Частный случай я выше называл.) Соответственно, это налагает довольно высокие требования на чувство архитектуры у прикладного программиста.

Ох и понаписали за ночь.

Поехали по порядку:

беглый взгляд показывает наличие gtk_widget_get_preferred_height_for_width() — т.е. «примитивным рекурсивным обходом дерева с дерганием конструкторов на каждом узле» дело, похоже, не ограничивается

Мне кажется, ты как-то путаешь конфиг и собственную семантику виджета. У виджета есть свойства, методы, слоты сигналов. (Как минимум, из всего этого свойства и слоты в gtk run-time inspectable). Таблица - это такой контейнер с интересной семантикой, и всё, что от него нужно, он делает.

Но мы можем эту таблицу создавать, надрачивая gtk_grid_*(blabla, blabla), а можем завернуть всё в файл конфигурации, и пусть библиотека сама с этим разбирается. Способ с конфигом — понятно — и гибче, и концептуально мощнее. Но при этом в обработке конфига никакой магии нет, это действительно тупой обход дерева.

как мне избавится от идиотской неудаляемой панели инструментов в аппликухе — чтобы это было так же просто, как написать css selector (а то и вообще без этого, через гуй stylish-а или аналогов?) а как мне сделать кнопочку, которая эту панель включает-выключает? в хтмл-прокси это простенький регексп, который в нужном месте добавляет кнопку с маленьким ява-скриптом

Для этого достаточно, например, в gtk дать стандартный способ пользователю вмешаться в логику построения дерева виджетов и их свойств при помощи задания правил на каком-нибудь декларативном языке. Правда после этого половина существующих приложений развалится, не ожидая такого подвоха. Но это я к тому, что это в принципе возможно и при помощи application-side тулкита.

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

Проблема в том, что абстрагироваться от дополнительных примочек ты можешь («нам нужно просто поле ввода, а насколько оно удобно сделано, пусть у сервера голова болит»), а вот конкретизироваться на нах — нет. Потому что если в этом общем знаменателе нет, например, вот такого няшного поля ввода со списком, иконками и свитоперделками, то никак ты его и не получишь. Единственный способ — закачивать код виджета на дисплей, т.е. JS. И вся совместимость тулкитов на этом и заканчивается.

Теперь про недостатки и достоинства. Сначала про достоинства. Преимущества дескриптивного подхода к GUI ты уже описывал тут, посмотрим, что будет, если их развить:

1. GUI не должно быть stateless, должна быть возможность прямо из декларативного представления интерфейса работать с его состоянием. По типу «нажали на кнопочку, и представление данных в рабочей области сменилось с таблицы на сетку иконок». Какой-то язык выборки узлов интерфейса, по типу того, что используется в jquery, дополненный возможностью изменять состояние этих узлов. Пример в псевдокоде:

<a href="query: #dataarea::class(list_view)" group="view_mode" class="radioitem">Список<a/> | <a href="query: #dataarea::class(grid_view)" group="view_mode" class="radioitem">Сетка<a/>

2. Львиная доля скриптов — это тупо «отправить запрос приложению и подставить результат в какой-нибудь узел». Это тоже можно описывать декларативно, без километров императивщины на JS:

<a href="query: #dataarea::content(application::page(1))">Предыдущая страница</a> |
<a href="query: #dataarea::content(application::page(3))">Следующая страница</a>

На этом преимущества заканчиваются.

Про узкие места. Какие у нас могут быть варианты интерфейса:

1. Пусть у нас есть простое приложение, которое по интерфейсу не сильно отличается от сайта библиотеки Мошкова. Всё отлично, всё работает. Это такое своеобразный юниксвей: один компонент умеет рисовать инерфейсы по конфигу, второй реализует прикладную логику, между ними лежит чисто текстовый протокол, доступный для вмешательства пользователем, при необходимости.

2. Всё то же самое, но облагороженное с целью улучшения эрногомики. Более интерактивные компоненты, обновление без полной перезагрузки гуя и т.п. Всё это делается сейчас на JS, но всё это можно делать при помощи декларативного языка.

3. А узкие места возникают как раз тогда, этих возможнсотей становится не достаточно. Даже на уровне упомянутого «няшного поля ввода».

Проблема первая: чтобы «расширить» GUI, нам нужен мощный тьюринг-полный язык на дисплее. Это сразу на корню подрезает саму концепцию «простого декларативного интерфейса».

Проблема вторая: мы ничего не знаем о том, как виджеты реализованы дисплеем, и не сможем сделать на уровне look and feel «так же, но лучше». В качестве костыля придётся переопределять на собственные ВООБЩЕ ВСЕ виджеты и натягивать на них свой собственный look.

Проблема третья: пройдёт 2 года, всер разработчики подсядут на иглу этого языка, и никому не нужена будет развитая семантика декларативного языка. (Впрочем, это точно так же, как с иксами. Есть XRender и OGL, но криворукому разработчику не осилить их правильное использование, лучше повозмущаться про «иксы устарели ололо».) Даже те приложения, которым бы за глаза хватило декларативного языка, будут неюзабельны без кучи императивных костылей. Ну и производительность соответствующая.

4. Кроме того, есть еще проблема эффективного взаимодействия с дисплеем для вывода «быстрой» графики. Растровые и векторные изображения, видеопоток, OGL и т.п. Но это в принципе решаемо.

И еще: всё это требует очень аккуратного программирования со стороны авторов фреймворков и прикладных программ. Потому что интерфейс дисплея будет предлагать как высокоуровневые возможности, в семантике готовых виджетов, так и возможности для сырой обработки ввода и вывода. Будет очень много вариантов, как можно это API использовать НЕПРАВИЛЬНО. (Частный случай я выше называл.) Соответственно, это налагает довольно высокие требования на чувство архитектуры у прикладного программиста.

Ох и понаписали за ночь.

Поехали по порядку:

беглый взгляд показывает наличие gtk_widget_get_preferred_height_for_width() — т.е. «примитивным рекурсивным обходом дерева с дерганием конструкторов на каждом узле» дело, похоже, не ограничивается

Мне кажется, ты как-то путаешь конфиг и собственную семантику виджета. У виджета есть свойства, методы, слоты сигналов. (Как минимум, из всего этого свойства и слоты в gtk run-time inspectable). Таблица - это такой контейнер с интересной семантикой, и всё, что от него нужно, он делает.

Но мы можем эту таблицу создавать, надрачивая gtk_grid_*(blabla, blabla), а можем завернуть всё в файл конфигурации, и пусть библиотека сама с этим разбирается. Способ с конфигом — понятно — и гибче, и концептуально мощнее. Но при этом в обработке конфига никакой магии нет, это действительно тупой обход дерева.

как мне избавится от идиотской неудаляемой панели инструментов в аппликухе — чтобы это было так же просто, как написать css selector (а то и вообще без этого, через гуй stylish-а или аналогов?) а как мне сделать кнопочку, которая эту панель включает-выключает? в хтмл-прокси это простенький регексп, который в нужном месте добавляет кнопку с маленьким ява-скриптом

Для этого достаточно, например, в gtk дать стандартный способ пользователю вмешаться в логику построения дерева виджетов и их свойств при помощи задания правил на каком-нибудь декларативном языке. Правда после этого половина существующих приложений развалится, не ожидая такого подвоха. Но это я к тому, что это в принципе возможно и при помощи application-side тулкита.

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

Проблема в том, что абстрагироваться от дополнительных примочек ты можешь («нам нужно просто поле ввода, а насколько оно удобно сделано, пусть у сервера голова болит»), а вот конкретизироваться на нах — нет. Потому что если в этом общем знаменателе нет, например, вот такого няшного поля ввода со списком, иконками и свитоперделками, то никак ты его и не получишь. Единственный способ — закачивать код виджета на дисплей, т.е. JS. И вся совместимость тулкитов на этом и заканчивается.

Теперь про недостатки и достоинства. Сначала про достоинства. Преимущества дескриптивного подхода к GUI ты уже описывал тут, посмотрим, что будет, если их развить:

1. GUI не должно быть stateless, должна быть возможность прямо из декларативного представления интерфейса работать с его состоянием. По типу «нажали на кнопочку, и представление данных в рабочей области сменилось с таблицы на сетку иконок». Какой-то язык выборки узлов интерфейса, по типу того, что используется в jquery, дополненный возможностью изменять состояние этих узлов. Прмиер в псевдокоде:

<a href="query: #dataarea::class(list_view)" group="view_mode" class="radioitem">Список<a/> | <a href="query: #dataarea::class(grid_view)" group="view_mode" class="radioitem">Сетка<a/>

2. Львиная доля скриптов — это тупо «отправить запрос приложению и подставить результат в какой-нибудь узел». Это тоже можно описывать декларативно, без километров императивщины на JS:

<a href="query: #dataarea::content(application::page(1))">Предыдущая страница</a> |
<a href="query: #dataarea::content(application::page(3))">Следующая страница</a>

На этом преимущества заканчиваются.

Про узкие места. Какие у нас могут быть варианты интервейса: