Pull to refresh

Comments 75

Поздравляю, вы изобрели HTML и HTTP, только на JSON и WebSocket. Дальше добавьте поддержку стилей, учредите комитет для выработки единого стандарта, чтобы разные AppBrowser-ы показывали ваш GUI одинаково, добавьте возможность запускать локальные скрипты на AppBrowser-е (чтобы логику репрезентации отделить от бизнес-логики, потому что наш API-сервер ведь занимается только важными бизнес-вещами)… работы непочатый край.

Никакой разметки нет. Только чистые, ничем не замутненные данные. Конструкция Block нужна для логической группировки, чтобы данные шли в том порядке, в котором вы ожидаете их увидеть. Стили — это дело uniGUI и пользователя, не меня, как программиста. две прошитых темы для бизнес-app, соотвествующих Google MD по мне так достаточно. Вся логика на сервере, на одном языке. Сделал, чтобы не тратить время на GUI. Уже не трачу.
Оборачивает всю разметку в JSON
Оформляет в JSON даже таблицы
Никакой разметки

ну-ну

покажите где вы видите разметку. мож мы понимаем термин по разному…
{‘name’:’My table’, 'headers'=[‘Name’, ‘Synonym’], rows = [
[‘young’, ‘youthful’],
[‘small’, ‘ meager’],
...]
}

Знакомьтесь, это — разметка. Вы взяли какие-то данные и сказали "я хочу, чтобы эти данные были в форме таблицы".


Или вот:


{‘name’: ‘Switch something’, value: ‘choice1’, options=[‘choice1’, ‘choice2’,’choice3’]}

Найдите 3 отличия от <select><option>choice1</option><option>choice2</option><option>choice3</option></select>.


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

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

Нет, ну почему же все? Только приведенные вами примеры. Вот, например, данные без какой-либо разметки:


{
    "users": [
        { "name": "John Doe", age: 42, roles: ["admin", "bureaucrat"] },
        { "name": "Jane Doe", age: 34, roles: ["nobody"] },
    ],
    "session": {
        "expires": "2020-05-13T04:17:46.298Z"
    }
}

Не-а. У вас идет разметка — "это таблица, и вот ее строки". "Это чекбокс, и вот его состояние". "Это метка, вот ее текст". "Это комбобокс, вот варианты выбора".


Данные же лишены вариативности выбора (это не схема, где можно было бы подсмотреть варианты возможных значений), данные не содержат подписей, данные не имеют в принципе поля "name", потому что name — это имя некоего контрола, это аттрибут разметки, где сами данные, возможно, находятся в поле value.


Так что у вас обычная разметка, смиритесь.


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

И не подумаю смириться. Я передаю именно данные таблицы. А вы же ставите в упрек что любые данные JSON uniGUI автоматом не сконвертит в нормальный вид. Отображение ваших данных в данные таблицы — это дело ваше личное. Любой JSON сконвертить в редактируемое GUI представление — ноу проблем (делал такое). Но здесь речь идет о нормальном app GUI. и для этого нужны минимально необходимые данные описания элемента(ов). повторюсь — потомки нас рассудят.
Я передаю именно данные таблицы
Данные — это чистая информация, ее можно представлять разными способами — таблицей, диаграммами, текстом с разделителями. Вот эти перечисленные способы — это и есть разметка.
По этому если вы просто передаете некий словарь в виде JSON — это данные, если Вы при этом явно указываете, как они должны быть отображены (таблица, диаграмма и т.п.) — это данные с разметкой.

а по моему всё XML подобное должно уйти в прошлое, пусть это и разметка, но имеет право на жизнь

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

Что-то подобное видел в ExtJs, правда там данные от разметки разделены, но представление так же в json подобном виде

А как выглядят данные таблицы без разметки?

"Как выглядит разметка без разметки". Когда вы говорите "таблица", вы уже изъявляете желание придать данным определенную форму, разметить их под определенное представление. Вы не можете просто взять выхлоп GraphQL-запроса и "показать" его через ваш uniGUI — вам нужно сконвертировать объект, обладая знаниями о его схеме, в нечто, что uniGUI поймет как таблицу — т.е. разметить.


Нет совершенно никакой разницы, выразите вы это как


{
    name: 'My table',
    headers: ['Name', 'Synonym'],
    rows: [
        ['young', 'youthful'],
        ['small', 'meager']
    ]
}

или как


<table>
    <caption>My table</caption>

    <tr><th>Name</th><th>Synonym</th></tr>

    <tr><td>young</td><td>youthful</td></tr>
    <tr><td>small</td><td>meager</td></tr>
</table>
Ерунда. Если данные содержат разметку, то можно ее оттуда убрать. И получить данные без разметки. Есть вы не можете убрать разметку, оставив корректные для отрисовки данные, то это только данные, напоминающие вам разметку, но это только минимально необходимое описание.
Например вот так могли бы выглядеть данные
 [
        {"word":"young", "synonym":"youthful"},        
        {"word":"small", "synonym":"meager"}
]

Описание того что «word» нужно писать в колонку «Name», а «synonym» в колонку «Synonym» — это разметка.

А зачем же вы это пишете мне? Убеждайте george3, это у него все ему сплошную ерунду пишут, а разметки никакой нигде отродясь не было :)

Когда я был маленьким, я захотел понять как должна выглядеть идеальная операционная система (тогда это были СМ1420 и первые IBM PC). Подумал, что если все разложить по полочкам и максимально абстрагировать от аппаратуры (тогда я таких слов не знал), то программы для такой ОС будут взаимодействовать с аппаратурой только посредством системных вызовов. Даже попытался составить список таких абстракций, как не пытался закрытый (конечный) у меня не получался. По различным причинам раз за разом хотелось, что то добавить и в итоге проект рушился. Постепенно пришло понимание что это не я такой, «это жизнь такая»(вспомните историю развития вычислительной техники). Пришло понимание, что в рамках существующей вычислительной парадигмы такая универсальность невозможна. Оставим вычислительную технику, да же «люди» создавшие ее не имеют константного отношения к окружающему миру, даже языки общения различны и постоянно плывут (изменяются и расщепляются), при этом пока нет корректного способа осуществить перевод между уже имеющимися языками.
Для получения все более универсального GUI необходимо рассматривать проблему со все более высокого уровня абстракции (хочешь получить универсальный калькулятор — рассматривай и решай задачу с уровня абстракции «Фортран» и тд). Для сегодняшнего случая следующий уровень абстракции это ИИ. Простое упорядочивание, удаление повторов и не оптимальных элементов не поможет в решении проблемы — вы просто создадите еще одно не совместимое подмножество.
Встроенный автодизайнер можно рассматривать как ИИ web-дизайнера. но это не точно.

Статья занимательная. Есть о чем задуматься. Вот только я не уверен, что у Вас на этом страдания закончатся.

тот набор элементов и функционала, который есть в uniGUI на данный момент покрывает все мои потребности. багов от него не ловил уже 2 недели.
Не о чем. «Готовый UI» изобретают с прошлого века. Загуглите borland turbo vision. А разгадка очень проста: если у нас UI не ограничен строго по домену и по функционалу, то попытка реализовать конструктор — всегда окончится придумыванием очередного UI Framework, в отношении которого другие программисты будут говорить «и нафига мне учить очередной фреймворк».

Более того, велосипедные поделки на эту тему — они все без исключения наступают всё на те же грабли, по которым уже от души походили крупные фреймворки.

У автора классический случай «своего болота», когда успешно реализовав свой собственный узенький кейс, он считает, что его решение достаточно общее, и взлетит за пределами этого узенького кейса.
Кейс научного и бизнес софта не маленький. я поделился идеей. для меня она решает все мои задачи. взлет не планирую. мои интересы в другой области. это побочный продукт.
Тогда, возможно, не стоило набрасывать и делать кликбейтный заголовок? У меня сейчас он показывается как «универсальный GUI», что, как бы, довольно вызывающе претендует на прямо-таки решение всех проблем (вместе с «конец страданиям» оттуда же).

И это вам еще не начали задавать вопросы про безопасность и авторизацию. Протокол у вас HTTP? А если кто-то еще подключится к этому же серверу?
А, например, если у вас поле ввода пароля есть на форме — вы содержимое в открытом виде передаете?
Универсальный в том что работает везде в моем случае, потому что на flutter. С любыми языками потому что JSON. На мой взгляд лукавства нет.
websocket может быть защищенный. шифрованный. в чем проблема.
UFO just landed and posted this here
назначение uniGUI — избавить программиста от знания любых деталей o GUI, отдав ему минимальное описание своих данных. проще говоря — не думать o GUI и не программить GUI. только реакция на изменение юзером данных.
Подобный GUI хорошо выглядит на простых примерах, где просто эдитки, чекбоксы и так далее. С этими «голый» HTML тоже отлично справляется. Но в реальной жизни все намного сложнее и запутаннее. Подумайте, например, как бы можно было реализовать на таком GUI данную страницу хабра, со статьей, комментариями, голосованием, выделением отдельно кусков кода и т.д. Как бы автокомпоновщик это расположил на странице, чтобы не превратить все в кашу. Вам придется изобретать стили и сильно усложнять ваш протокол (картинка про 14 стандартов и 15ый, который должен исправить всё)…
у меня сложные Gui. Скрин с редактора мед. знаний. весьма богатый на деревья, таблицы, doc viewers…
Любой блок должен влазить на экран. если не влазит — обрезается. если блоков много и их всех можно задизайнить/отрисовать на экране — будет сделано.

А если у юзера 4к монитор 27+ дюймов — как отобразится? Размеры вообще в чём задаются?

вообще ни в чем размеры не задаются кроме как для Image. все размеры считаются автодизайнером, чтобы вместить все, что на экране хотите увидеть. в этом фишка.
UFO just landed and posted this here
Все верно. клиент и сервер может быть на чем угодно. Главное — соответствие описанию данных.
UFO just landed and posted this here
flutter легче. работает быстрее.
вот событие [Glossary, Terms, =, 658] значит что юзер в блоке Glossary выбрал строку в таблице Terms с id 658.вот нажали кнопку на тулбаре с именем _Back [toolbar, _Back, =, _Back] и т. д.
UFO just landed and posted this here
мышью, клавой, без разницы. при редактировании шлется еще номер поля и значение: [id строки, номер поля, значения]. т е при наборе java сервер получит 4 мессаджа со значениями j, ja, jav, java. Как на это реагировать: 1 автоматом, при отсутствии обработчика, значения кладется в value связанного элемента. 2. задан обработчик с именем chаnged — будет вызван 4 раза. он может откатить изменение, послать autocomplete массив строк,…
UFO just landed and posted this here
там, если глянуть на скрин есть кнопка редактирования в таблице. для начала нужно ее нажать.тогда начнет проваливаться.ширина полей считается автоматом автодизайнером в зависимости от показываемых данных. то же про ширину/высоту таблицы, равно как и остальных элементов. автодизайнер вытается все отрисовать максимально правильно (без обрезаний). с учетом окружающих элементов.
UFO just landed and posted this here
1. при добавлении строки таблица переходит в режим редактирования автоматом.
2. есть мультивыделения (см. переключатель с иконкой 1 на скрине) тогда появляются checkbox слева от каждой строки.

про задержку/игнор событий — дело сервера. игнорить или нет — дело обработчика. он вызовется всегда если пришло событие.
UFO just landed and posted this here
>>Ну т.е. перепрыгнет через одно.
1.Websocket гарантирует очередность доставки событий, насколько я знаю.
2.нет событие — нет реакции. событие занимает ~ 20 байт. 3 события за секунду при интенсивном наборе чего-то максимум.
Дело не в объеме данных, а в пинге и задержках. У вас система очень сильно зависит от стабильности канала, при плохой связи реакция на действия пользователя будет жестоко тормозить, пользоваться приложением будет крайне некомфортно. Попробуйте посидеть в GUI на сервере через RDP на плохом канале, поймете, как это выматывает. Поэтому и стараются реализовать большинство логики пользовательского интерфейса на фронте, чтобы сеть не тормозила действия пользователя.
После смены Vue на uniGUI отзывчивость интерфейса субъективно возросла в 3x раз. он работает как нормальный desktop GUI. не ждет реакции сервера. некая задержка возникает когда полностью меняется-пересылается экран. впрочем все равно быстрее чем VUE в этом моменте.
правда это скорее заслуга больше flutter чем моя в скорости отрисовки.
Флаг с тремя состояниями это {name:, value, options=['1','2','3']}
Будет отрисован в виде кнопочной группы. На скрине справа вверху пример такой Stable, Virtual, Both.
UFO just landed and posted this here
SelectGroupButtons, SelectEdit у меня стандартные. Их разумеется можно впихнуть в таблицу, равно как и остальное. Кастомных элементов не предусмотрено, ибо это идет вразрез идее чистые данные -> GUI автоматом.
это app, который не требует затрат на программирование, дизайн, обслуживание и способный одинаково работать с любыми языками, и на любой платформе без всяких подстроек

Почему-то подумал о командной строке. Но даже она требует затрат на программирование.
Мне кажется вам стоит почитать про X Window System — в основе именно похожая идея — протокол, который просто сообщает серверу о том что нужно показывать пользователю. Сервер реализован для конкретной ОС, а приложение, таким образом, освобождается от жесткой привязки и становится кросс-платформенным. Теоретически.

Идеи X11 появились еще 36 лет назад. В общем случае, приложение может работать на удаленном сервере, но формы и весь интерфейс вы можете использовать локально на своем ноутбуке с Mac, Linux или Windows — поддерживается довольно много транспортов.

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

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

Тогда гляньте ещё попытки упрощения xserver через отрывание сетевой подсистемы и уменьшение количества примитивов и утилит.
Из живых ныне wayland, mir.
Но по серьёзному у вас получается ещё один гуи фреймворк теперь с JSON вместо "стандартных" биндингов.

может и так. но я не программлю GUI кроме как реакции обработчиков высокоуровневых событий. если это несущественно то да, это «просто еще один гуи фреймворк теперь с JSON».
С одной стороны сразу упомянут PyQt; с другой, статья выглядит будто написана только про вэб и что крутится в браузерах. Поэтому не ясно зачем тут PyQt, или вы предлагаете даже десктопные приложения обязать стучаться на какой-то сервер за формами?

Дополнительный вопрос:
— что будет, если клиент ещё старый, а сервер выдаёт ему формы с новыми контролами, которые только что появились(ведь не все сразу появятся в начальной реализации)? Скажем, добавили combobox в который можно текст вписывать, а до этого были только read-only comboboxes.

Edit: убрал остальные дополнительные вопросы :)
1. Он написана сразу про все платформы, внутри и внеброузерные. Смысл — не думать о платформе. Как задизайнить под конкретную платформу — дело конкретного клиента на платформе, конкретного автодизайнера. Например, для меня основная платформа — десктопный клиент.
2. Я не предусмотрел такие вопросы пока. но если он встанет, то по логике uniGUI если не сможет определить тип должен отрисовать пустое пространство с сообщением об ошибке, если данные не подходят ни какому виду-виджету. Если подходят — отрисовать им и предупреждение.
Спасибо за ответ, но вопросов меньше не стало :)

1. Начинаю не понимать, что будет делаться на сервере, если еще нужна какая-то прослойка на каждую конкретную платформу. Кто будет писать эти прослойки? И где они будут бежать?
2. Что делать тем, у кого интернет отсутствует(здравствуйте режимные предприятия) или нестабильный(нажали кнопочку сохранить, прога пошла на сервер за формой диалога сохранения, да и повисла)?
3. Кто и когда будет отрисовывать формы? Что будет отвечать за перевод JSON от сервера в картинку на экране? Если локальная прослойка, то опять же не ясно, что делает сервер.
4. Цитата "… сервер получает поток сообщений JSON, которые полностью описывают что сделал юзер...". Хм, то есть предлагается всем на какой-то сервер слать свои пароли/логины(а как иначе рассказать серверу, что было нажато)? Как вообще будет работать то, что должно быть под грифом «секретно»?
5. Многие GUI библиотеки имею классную штуку, позволяющую расширять набор контролов и менять отрисовку (custom controls), чтобы реализовать приятное и выделяющееся из остальных приложение. Да, это не для каждого типа приложений подойдёт. Как это будет при универсальности?
1. Автодизайнер дизайнит под конкретное разрешение используя логику web-дизайнера-программиста, когда ему нужно отобразить данные. если все данные вместить невозможно, то нарисует первый(е) блоки, на остальные нарисует иконы в тулбаре.
Прослойки — это адаптеры для языка которые только обеспечивают автоматизм отправки-синхронизации данных пользователя <-> данные GUI. для питона например такая прослойка занимает ~ 250 строк кода. и она универсальная а не прошитая под мои потребности.
2. Локально запускайте сервер-app. Без сервера работать не должно)
3.Сервер дает описание данных. Клиент обеспечивает все остальное.
4.https соединение. клиент шлет только свои события.
5. Расширение типов. Сейчас на некоторые типы данных возможна отрисовка по разному. Если на один тип данных более одного виджета, просто всунуть type:MyNewTree. Если такие типы будут написаны на Dart, то динамическая стыковка вполне реализуема. но как по мне то что в Google MD поддерживать автоматом не морочиться этим.
UFO just landed and posted this here
Хоть мильон. У каждого своя GUI websocket сессия.
UFO just landed and posted this here
не так. состояние GUI — это экран юзера и он соответсвует только ему. для сервера это какой то экземпляр Screen, уникальный для юзера, и создающийся для него при коннекте клиента. режим эха-зеркала и правда доступен на сервере. это будет, если нескольким вернуть один экран (тот же объект сервера).
UFO just landed and posted this here
Задача что внутри сервер делает с событиями, синхронизации пользователей, данных сервера — это прикладной уровень и к условному uniGUI не относится. Его задача отрисовать описание, и передавать инфу об его(описании) изменениях юзером(и).
1. А где disabled? Где всплывающая подсказка? Где маска ввода, допустимые значения? Где логика (например, выбрали из списка -> подгрузили данные в другой список, disabled такой-то контрол)?
2. Почему всё вдруг в строку и нужно нажать кнопку, чтобы увидеть невлезшее? Почему не flow?
3. Кроме UI есть UX, а его так просто в JSON не запихнешь. Вернее запихнешь, но, как сказали выше, получится еще один html/javascript.
1.
сложные элементы управления такие Таблицы, Viewers, могут иметь дополнительные параметры, как то ‘colors’, ‘params’,… которые могут использоваться для специфической отрисовки или выбора доступных опций

По умолчанию — максимальный набор опций,

2.Здесь дело вкуса и информативности. вы сразу видите, что в экране еще чего-то есть, не скроллируя.
нажать кнопку и переместиться на нужный блок быстрее чем скролл и поиск. Но такие мелочи могут настраиваться в опциях автодизайнера, который учтет вкусы пользователя, пользователем.
3. все можно описать декларативно, кратчайшим образом. Все то, что за пределами логики стандартного GUI описывается в сервер логике. Маски, допустимость ввода обрабатываются сервером когда получил событие. Прослойка автоматом имеет на все обработку по умолчанию. Свой обработчик позволяет принять или откатить и сделать в ответ все что угодно с экраном пользователя, послав ему новый экран или апдейт экрана.
Sign up to leave a comment.

Articles