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 через разделяемую память.

★★★★

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

визуально любым, устраивающим по usability, но:

  • интуитивно понятным

  • ориентированным на поддержку понятных конкретных действий, которые самоочевидно как запускать

  • реактивным, лайвкодинговым

  • интерактивным

  • программируемым и скриптуемым «из коробки»

  • композабельным в какие-то процессы, цепочки событий, логику – из коробки

  • ориентированным на симультанное восприятие одновременно многого, но только важного типа ZUI

  • легко тестируемым

  • адаптируемым под ситуацию и настраиваемым легко, в полпинка – самим «программирующим пользователем»

и да, в 90% случаев это должны быть готовые виджеты и гаждеты с тыкалкой с проводочками. которые просто не нужно сложным образом программировать ну вообще, да и настраивать проще чем такой вот WYSIWIG GUI конструктор.

то есть: текст как интерфейс, документ как интерфейс, схема, звенья схемы автоматически композабельны – модель как интерфейс

простой переход от модели к реализации к метамодели и наоборот.

anonymous
()
Ответ на: комментарий от anonymous
  • API должно предоставить набор «стандартных» controls и возможность разработки новых типов controls так, чтобы их «понимал» designer GUI

123456

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

то есть, добавлять свои custom controls, которые должны создаваться полуавтоматически типа MVP-MVVM composable из какого-то простого визарда/конструктора? ну вот очень на те же ролики про Dolphin SmallTalk похоже.

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

то есть, добавлять свои custom controls, которые должны создаваться полуавтоматически типа MVP-MVVM composable из какого-то простого визарда/конструктора?

Где-то так.
Да и «стандартные» controls должны быть разработаны так, чтобы они не были «гвоздями прибиты» к реализации.

123456

anonymous
()

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

Ты многопоток в питоне сначала доделал бы, а то бросил на полпути. Конечно оно никому не нужно в таком виде.

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

Удваиваю этого господина. Любой эффективный GUI это абсолютно такой же I/O серверок как nginx, ток с устройствами и протоколами другими работает. То, что для недалёких это прячут за абстракциями - чисто нужда индустрии, т.к. работы в этом направлении много а одекватов мало. Прячут в нормальных решениях при этом - дюже не глубоко.

pon4ik ★★★★★
()

Мне нравится GUI в IBM System I. Там устройства это файлы, пользователь это файл, и форма это файл. Главный цикл обработки событий можно прям на select’e строить. Повтори - будет прикольно.

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

это не многопоток в питоне

Многопоточный питон… снова.

Но дело не в этом. В статье ни тестов, ни демонстрации решения каких-либо проблем(в чём автор сам признавался). Не важно, что именно там было.

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

Любой эффективный GUI это абсолютно такой же I/O серверок как nginx, ток с устройствами и протоколами другими работает. То, что для недалёких это прячут за абстракциями - чисто нужда индустрии, т.к. работы в этом направлении много а одекватов мало.

в Plan9 или Inferno? а может, в PlanB. где-то там есть публикация на эту тему. что GUI как многопоточный concurent coroutine движок аналогичный 10K connection lock-free типа nginx и т.п.

ну то есть, уже есть вот такая реализация гуе сервера. в Limbo через Dis VM, в Go в рантайме, в Plan9 через библиотеку на сишечке.

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

аналогично в Plan9/PlanB. а в GTK server что-то подобное плейнтекстом запилили.

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

Да любая реализация GUI приложения современного в своей основе содержит такой асинхронный сервер, либо прокси. Просто протоколы зашиты на уровне GUI API. Цикл обработки событий что в асинхронном высокопроизводительном сервере, что в GUI приложении, суть одно и то же, с точностью до примитивов ожидания события и устройства очереди событий. В некоторых случаях, можно из тех же примитивов собрать конечно менее эфективную для i/o bound приложений не чувствительных к лэйтенси схему, например агрессивную, но непонятно зачем, т.к. в 99% случаев проще классический цикл обработки событий как понимать, так и реализовывать.

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

Любой эффективный GUI это абсолютно такой же I/O серверок как nginx, ток с устройствами и протоколами другими работает.

Конечно же нет. «серверок» имеет одну проблему, из которой вытекают все остальные - неопределённо высокую нагрузку. Отсюда все проблемы с масштабированием и балансировкой. Где та же проблема в гуе?

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

Да любая реализация GUI приложения современного в своей основе содержит такой асинхронный сервер, либо прокси.

Windows все это предоставляет «из коробки».
А Linux?

anonymous
()

Если совсем из необычного, то оставьте хотя бы как есть.

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

Ты скажи чего ты там хочешь конкретно? Чтобы не было никакой возможности засунуть дополнительную логику в гуёвый поток даже если программист очень этого хочет?

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

Эшо гуглим «очередь сообщений linux controls GUI».
Понял так, что «стандартного» набора сообщений от controls нет.
Если это так, то

Их нужно реализовать

123456

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

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

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

https://habr.com/ru/post/165981/ Очередь сообщений (Message Queue)

http://citforum.ck.ua/programming/unix/svid_ipc_objects/ Программирование для Linux. Объекты SVID IPC

GTK, QT, … безусловно имеют свои наборы сообщений.
Так можно ли разработать «стандартный» набор сообщений для GUI?
Безусловно ДА!

123456

anonymous
()

ЕМНИП, в BeOS/Haiku для GUI всех приложений всегда отдельный поток.

ls-h ★★★★★
()

Tcl/Tk уже предлагали? Я конечно ниче не понял из стартового поста кроме слова «скриптуха», но может ну его нафиг этот прогресс. Вот сейчас пытаемся натянуть прототип гуйни с Tk на вебню. Это ахтунг, товарищи. Вебмакакам нужно стаж считать год за 3. У них работа в экстремальных условиях типа крайнего севера.

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

Ну у X11 есть api например. Под онтопиком это вообще одно из самых ярких отражений этой идеи.

В GTK, QT, то же есть …

123456

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

Ну у X11 есть api например.

Это ты про синхронный X11/Xlib? Который потом в GUI-тулкитах выкинули и заменили на недоделаный но асинхронный XCB без внятной документации?

Под онтопиком это вообще одно из самых ярких отражений этой идеи.

Завязка на X.Org – одна из самых ярких причин почему «Linux Desktop sucks».

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

FFTGJ

Вебмакакам нужно стаж считать год за 3. У них работа в экстремальных условиях типа крайнего севера сервера.

у них всегда сервер крайний, а макака ни причём :)

anonymous
()

Само наложение текстур блоков с CSS-рюшечками, естественно, делаются уже на видеокарте в отдельном потоке, а композитор только отвечает за «быстрые» прокрутку и изменение размеров.

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

PPP328 ★★★★★
()

Ты вот кажется пытаешься что-то противопоставить, однако противопоставлять нечего - объектный подход к GUI и организация главного цикла с обработкой сообщений не менялся с момента появляния этого самого GUI, и он одинаковый что в DOSовском софте 30летней давности, что в современном хроме, игрушках и андроиде. Вынести вычисления в отдельный поток чтобы они не вешали интерфейс, или там рисовать на GPU, или сам интерфейс описывать не в коде, а в xml, html или qml - это детали реализации на архитектуру никак не влияющие.

slovazap ★★★★★
()

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

Это «нормально», когда неважно, что делает игрок, что видит игрок, что делают противники, и вообще, сама игра не важна - видеофильм с опциональной интерактивностью.

anonymous
()

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

Software gets slower faster than hardware gets faster.
-- Niklaus Wirth. (February 1995). "A Plea for Lean Software". Computer 28 (2): pp. 64-68
xaizek ★★★★★
()

Интерфейсы довольно длительное время были в плену у объектно-ориентированного рака […]

В Smalltalk/VisualWorks отдельные объекты были более значимо выделены

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

Так я ничего не понял, у нас ООП рак? Но Smaltalk тоже ООП! Или просто системы так делают?

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

Или просто системы так делают?

Ему не нравится, что многопоточность не пихают куда попало. И вообще почему только многопоточность? Надо пихать многопроцессность, а обмен сообщениями только через ядерный IPC (однопоточный, «но это другое»).

anonymous
()

макакам хоть многопоточность помноженную на многопроцессорность дай - они всё засрут и ещё попросят.

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

Ему не нравится, что многопоточность не пихают куда попало.

судя по вот этому

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

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

seiken ★★★★★
()

играю в Deus Ex: Mankind Divided, и думаю […]

так игруны должны страдать, это нормально

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

а в чем проблема-то? Какие были проблемы при скачке файлов?

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

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

Применительно к чему написано это? К тому, что

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

Отзывчивость, интерактивность, реалтаймовость.

И для этого у него есть единственное правильное решение - многопоточность (или многокомпонентность?). Как будто многопоточность автоматически решает проблемы разбиения задачи на более легкие подзадачи, которые автоматически компонуются в цельное решение без накладных расходов и по времени, и по памяти.

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

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

Класс! Я почти до конца дочитал

Теперь ты знаешь, как бороться с сегфолтами в тредах. С пользой потратил время!

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

Класс!

К сожалению

Странные у тебя эмоции. Хотя «День Победы» - «Это радость со слезами на глазах»

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

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

Именно. Бесит неимоверно.

У меня никогда не было Windows, я его считал и считаю говно-софтом. У меня летали последовательно серии DOS, затем OS/2 (Warp, Merlin, Aurora), потом ALT-Linux (2, 3, 4…) Я никогда не мог работать на чужих виндокомпьютерах — они почему-то тормозили. Их владельцы изумлялись, когда я говорил им об этом, никто им не говорил ничего подобного. А я привык работать с другими системными задержками. И я думал, что это наверно из-за непривычной клавиатуры. Друзья же с трудом сидели за моим компьютером — стоило им задуматься, буквы стреляли очередями из-за настроек клавиатуры, к которым я привык еще со времен турбированной БК0010. И я честно все эти годы думал, что дело в удачном типе клавиатуры, которой я пользуюсь много-много лет! А дело-то в специфической на грани осознавания реакции системы — примерно то, о чем недавно говорил Arkanoid, только про мобильные телефоны.

Леонид Каганов, 2008 год (за прошедшие годы линукс, к сожалению, успешно догнал винду по этому показателю).

hobbit ★★★★★
()

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

eaglemode

Больше ничего прогрессивного в GUI за последние 30 лет не было.

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

У меня никогда не было Windows, я его считал и считаю говно-софтом.

В Windows ничего кардинально не изменяют из-за того, что многие имеют такой недостаток/достоинство - привычка.

С Windows не удобно работать, когда производится копирование директорий с большим количеством небольших по размеру файлов /не архивация, …/.
В это время Windows работает как MSDOS 1.0.

Владимир

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