chronological, 
Additive GUIs
Specify the attributes of the GUI and let the computer generate the GUI
I have a idea whereby you specify the relationships of widgets on the screen and the computer generates the layout.
Rather than positioning widgets manually, the computer generates the layout. Essentially the widgets are an inequality formula where X and y is set relative to one another.
We say that one widget is left of another widget or another widget is below another. This is how you might describe practically any GUI
The idea is that the computer generates variations of the layout and the human reviews them.
You also define the data flow between widgets. BackedBy is how we set the data source for a widget. MappedTo is a reference to a template that defines the GUI for an item in a collection. It's the same as a functional map.
The system is configured in triples.
Have you ever heard of Todo MVC? https://todomvc.com/
It's a simple problem implemented in many frameworks. The problem is a to-do list.
This is a to-do app written in additive GUIs.
You should notice that it is extremely compact.
{
"predicates": [
"NewTodo leftOf insertButton",
"Todos below insertButton",
"Todos backedBy todos",
"Todos mappedTo todos",
"Todos key .description",
"Todos editable $item.description",
"insertButton on:click insert-new-item",
"insert-new-item 0.pushes {\"description\": \"$item.NewTodo.description\"}",
"insert-new-item 0.pushTo $item.todos",
"NewTodo backedBy NewTodo",
"NewTodo mappedTo editBox",
"NewTodo editable $item.description",
"NewTodo key .description"
],
"widgets": {
"todos": {
"predicates": [
"label hasContent .description"
]
},
"editBox": {
"predicates": [
"NewItemField hasContent .description"
]
}
},
"data": {
"NewTodo": {
"description": "Hello world"
},
"todos": [
{
"description": "todo one"
},
{
"description": "todo two"
},
{
"description": "todo three"
}
]
}
}
I have a working implementation of additive GUIs here.
Интересно, делает ли OpenAI Codex внутреннее представление, подобное вашему формализму аддитивных графических интерфейсов пользователя, при неформальных инструкциях, как в this видео?
Я думаю, что это было бы большим упрощением для более строгого определения пользовательского интерфейса. Мы могли бы просто предоставить такие компактные спецификации пользовательского интерфейса, как ответ API, и если бы во всех браузерах были предварительно загружены определенные библиотеки (например, кем-то, создавшим расширение браузера с предварительной загрузкой nmp), он мог бы отображать пользовательский интерфейс очень быстро, без дополнительных веб-запросов, в основном , что делает ненужным интерфейсную разработку и заменяет ее стандартизированными представлениями API таких декларативных операторов.
I wonder, is the OpenAI Codex making an internal representation similar to your formalism of Additive GUIs, when being instructed informally, like in this video?
I think it would be great simplification for defining UIs more rigorously. We could just provide such compact UI specifications as an API response, and if all browsers just had the certain libraries preloaded (e.g., by someone making an nmp preloading browser extension), it could render the UI very fast, without extra web requests, basically, making the front-end development unnecessary, and replacing it by standardized API views of such declarative statements.
Да Графические интерфейсы пользователя Mindey Additive основаны на концепции, согласно которой графический интерфейс представляет собой запрос, соединяющий многомерные многомерные плоскости. Где каждое измерение является виджетом, а точки - состояниями этого виджета. Существует функция, которая определяет отношение точек каждого измерения к другому набору точек для каждого измерения, возможно, посредством взаимодействия человека или взаимодействия с сервером.
Если API-интерфейсы могут возвращать очень плотное определение того, как графический интерфейс должен работать и отображаться, тогда мы можем удалить много настраиваемого кода.
Большинство взаимодействий с графическими интерфейсами, ориентированными на данные, такими как бесконечность, - это просто глаголы против элементов в списках. Они реагируют на сбор данных. Или добавляйте предметы в коллекции.
Для рисования графических интерфейсов, таких как инструменты диаграмм, такие как PowerPoint или рисование, я думаю, вам понадобится другая модель.
Yes Mindey Additive GUIs is based on the concept that a GUI is a query that splices multiple dimensions multidimensional plane. Where each dimension is a widget and the points are states of that widget. There is a function that defines the relation of the points of each dimension to another set of points for each dimension, perhaps by human interaction or server interaction.
If APIs can return a highly dense definition of how the GUI should work and be rendered, then we can remove a lot of custom code.
Most interaction with data orientated GUIs like infinity are just verbs against items in lists. They are reactive in response to data collections. Or add items to collections.
For drawing GUIs like diagram tools like PowerPoint or paint I think you need a different model.
// Если API-интерфейсы могут возвращать очень плотное определение того, как графический интерфейс должен работать и отображаться, тогда мы можем удалить много настраиваемого кода.
Понятно. Чтобы упростить ситуацию, проблема состоит в том, чтобы полностью определить такой декларативный язык, а затем построить сопоставление между спецификацией такого языка и реализацией через триплеты (HTML, JS, CSS) как компоненты, что и определяет реактивные элементы пользовательского интерфейса, независимо от того, в чистом или виртуальном DOM. Тогда пространство состояний каждого такого триплета в качестве компонента соответствует тому, что вы определяете как измерение, а пространство состояний всего пользовательского интерфейса - как декартово произведение кодоменов этих компонентов, причем каждое конкретное состояние всего пользовательского интерфейса является «многомерной плоскостью».
Я вижу, что эта концепция работает и является важной, но для того, чтобы она действительно работала, я вижу, что требуется много работы, чтобы определить исчерпывающий набор терминов, а затем привязанный к браузеру интерпретатор для его запуска.
// If APIs can return a highly dense definition of how the GUI should work and be rendered, then we can remove a lot of custom code.
I see. To simplify the matters, the problem then is fully-defining such declarative language, and then constructing the mapping between specification of such language and the implementation via the (HTML, JS, CSS) triplets as components, that is what defines reactive UI elements, regardless of whether its in pure or virtual DOM. The state space of each such triplet as component then corresponds to what you define as the dimension, and state space of entire UI as the Cartesian product of the codomains of those components, each particular state of entire UI being a "multidimensional plane".
I see this concept go, and being important, but to get it actually working, I see a lot of work being required to define the exhaustive set of terms, and then the browser-bound interpreter for this to run.
Я написал очень простой интерпретатор, который работает с этим примером. Он использует React. Визуализированный HTML уродлив, но добавление Todo работает.
Самое сложное - это то, что вы говорите, предоставляя достаточно гибкий язык, который может поддерживать большинство графических интерфейсов.
Моя цель заключалась в том, чтобы IDE можно было представить в этом формате графического интерфейса.
Я боюсь взглянуть на код для IntelliJ, держу пари, что это очень, очень очень сложно.
I've written a very simple interpreter that works with the example. It uses React. The rendered HTML is ugly but Todo adding works.
The hard part is what you say, providing a flexible enough language that can support most GUIs.
My goal was for IDEs to be representable with this format of GUI.
I dread to look at the code for IntelliJ I bet it's very very very complicated.