LINUX.ORG.RU

Прогрессивные разработки GUI

 , , ,


2

4

Может кто-то встречал необычные идеи, концептуальыне проекты, или просто какие-то передовые и непопулярные модификации имеющихся инструментов разработки интерфейсов?

Интерфейсы довольно длительное время были в плену у объектно-ориентированного рака, где у вас есть одна кнопка, одна мышка, и вам нужно нажать мышкой на кнопку — отсюда было шизофреническое разделение интерфейса на независимые сущности, отсюда главный цикл, который обрабатывает эту самую одну мышку (либо кнопку клавиатуры), и объекты GUI как состояния кусков экрана. В Smalltalk/VisualWorks отдельные объекты были более значимо выделены (с возможностью сохранять состояния отдельных объектов), а в современных десктопных GUI весь гуй является одним состоянием, и очередь сообщений у него тоже одна.

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

Самую-присамую писечеку из рядов массового софтопрома разрабатывает гугл в своем хроме:

https://www.chromium.org/developers/design-documents/compositor-thread-archit...

В хроме поток логики с жавоскриптом остается за главного, однако, часть логики отрисовки блоков перенесена в отдельный поток композитора — за счет чего веб-страница выглядит относительно живо при висящем жавоскрипте. Само наложение текстур блоков с CSS-рюшечками, естественно, делаются уже на видеокарте в отдельном потоке, а композитор только отвечает за «быстрые» прокрутку и изменение размеров. Быстрые — то есть описанных через базовые поддерживаемые концепции HTML/CSS и без задействования JS.

Но даже этого недостаточно для того, чтобы приложения на электроне перестали быть тормозным и жрущим оперативу калом. Но достаточно, чтобы сравниться с приложениями на Java. Это забавно выглядит в 2020 году, когда производительность процессоров растет медленнее, чем растет тормознутость интерфейсов. Сижу я тут, играю в Deus Ex: Mankind Divided, и думаю: а может, и правда, в 2029 году «прогресс» дойдет до того, что интерфейс для ввода четырех циферок будет открываться-закрываться по пять секунд, как в этой игре? И выключатели на тач скринах, которые работают только на «вкл-выкл» — я ванговал в соседнем треде, что на будущих девайсах для прогрессивной молодежи должна быть только одна кнопка.

Объективно, если брать современный GUI iOS/Android, то это упрощение по сравнению с многозадачными интерфейсами десктопов: пониженные требования многозадачности, пониженные требования к отзывчивости, набор доступных действий неочевиден, что идет против концепции GUI «я должен найти все фичи программы просто гуляя по менюшкам» — последняя проблема уже имеет варианты решения в виде Pie/Marking Menus. Да, это частично оправдано малым экраном. Да, эти проблемы со временем можно будет частично решить (если тенденция ухудшения не перевесит тендинцию улучшения). Но в целом, с позиции разработки, программы для тачфонов по прежнему пишутся в стиле однопоточного цикла обработки сообщений, просто сообщения стали несколько другими.

Меня пока что манит идея «скриптовухой» выкидывать описание GUI в какую-то структуру в разделяемой памяти, чтобы потом по этой структуре происходила отрисовка интерфейса, причем, той же «сприптовухой», но параллельно работающей. Вплоть до того, что с разделяемой структурой интерфейса будет работать несколько программ, используя транзакции. Например, у нас есть программа основной логики интерфейса, которая обрабатывает окошечки/кнопочки/поля ввода, и есть задачи фонового скачивания файлов. Фоновое скачивание живет само по себе, обновляет свои специфичные элементы GUI, при этом большую часть времени не взаимодействует с потоком логики, а только взаимодействует с отрисовщиком/композитором/taskname через разделяемую память.

★★★★
Ответ на: комментарий от dadd

TUI удобнее: https://github.com/rivo/tview

В каком месте удобнее? Я могу этим фейсом пользоваться мышкой? Есть буфер обмена, drag-n-drop? TUI фактически как браузером пользуется консольным клиентом, который уже является GUI приложением, будь то иксовым gnome-terminal или фреймбуферным tty.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

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

Давным-давно так было. Логика работала параллельно с интерфейсом. Интерфейс не блокировался. Потом из-за этого несколько человек убили радиацией. С тех пор идея независимой работы интерфейса и логики считается плохой.

monk ★★★★★
()
Ответ на: комментарий от ya-betmen

Ага, а асинхронный fetch требует неявного запуска ненавистного ТСу главного цикла.

Очевидная пятница в пятницу.

ArkaDOSik ★★
()
Ответ на: комментарий от monk

Давным-давно так было. Логика работала параллельно с интерфейсом. Интерфейс не блокировался. Потом из-за этого несколько человек убили радиацией.

За плохой код программистов?

anonymous
()
Ответ на: комментарий от anonymous

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

Понял, что велосипед нужен.
Для скриптовых языков это будет своего рода «Си без компилятора».

Владимир

anonymous
()
Ответ на: комментарий от monk

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

Особенно вот это к интерфейсу имеет много отношения:

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Там всё собрали. От деления на ноль компьютер просто перезагружался. А вот «Медсестра вспомнила, что в тот день она заменяла «x» на «e». Выяснилось, что если сделать это достаточно быстро, переоблучение случалось практически со 100-процентной вероятностью.» явно связано с асинхронностью интерфейса.

monk ★★★★★
()
Ответ на: комментарий от monk

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

Хм. Ну, там был КОМПЛЕКС полной фигни, не только UI.

Shadow ★★★★★
()

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

Тут же BSD/TCP сокетов хватит со всеми вытекающими.

Shadow ★★★★★
()
Ответ на: комментарий от Shadow

Тут же BSD/TCP сокетов хватит со всеми вытекающими.

… и поверх HTML+CSS+JS. Называется Electron.

monk ★★★★★
()
Ответ на: комментарий от monk

Плохим кодом программистов.

Может быть программист об этом даже не догадывался …
Интересно виновен в этом случае?

Владимир

anonymous
()
Ответ на: комментарий от monk

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

Это было связано с адовой криворукостью кодеров, которые писали этот софт. Асинхронность тут вообще не при чем — они бы заставили сломаться любой инструмент.

byko3y ★★★★
() автор топика
Ответ на: удаленный комментарий

byko3y, было время проектом позаниматься?

Было. Но я им почти не занимался.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Было. Но я им почти не занимался.

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

PS: В форуме не хвастаюсь.
То о чем говорил - сделаю.

Владимир

anonymous
()
Ответ на: комментарий от monk

Есть один. Только он уже давно не программирует.

Следовательно он больше не допускает ошибок в коде, идеальный разработчик!

anonymous
()
Ответ на: комментарий от anonymous

Следовательно он больше не допускает ошибок в коде, идеальный разработчик!

Лучше на ЛОР о разработке говорить

И сладко и ошибок нет

Владимир

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.