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

★★★★

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

а вот то что загружено как растровая картинка то и использовалось как растр

Спасибо, Капитан. Помимо этого там в редакторе можно рисовать векторные картинки и через ActionScript можно рисовать векторную графику. Возможность вставок растровых картинок не отменяет векторной графики.

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

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

во flash возможно (было) конвертирование растра в вектор.

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

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

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

нет он не основан на векторной графике он основан на растровой

Ты прав, но не до конца. Для мобилок сделали ускорение:

https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/dis...

«AIR profile support: This feature is supported on mobile devices, but it is not supported on desktop operating systems. It also has limited support on AIR for TV devices. Specifically, on AIR for TV devices, supported transformations include scaling and translation, but not rotation and skewing. See AIR Profile Support for more information regarding API support across multiple profiles.

With cacheAsBitmapMatrix set, the application retains a cached bitmap image across various 2D transformations, including translation, rotation, and scaling. If the application uses hardware acceleration, the object will be stored in video memory as a texture. This allows the GPU to apply the supported transformations to the object. The GPU can perform these transformations faster than the CPU.»

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

возьмем например flash игру там врядли нужно рисование чего именно векторного. Основа все равно растр.

Чисто векторные Flash-игры тоже есть. Под Flash есть встроенный набор векторных контролов на основе UIComponent.

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

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

Где-то так …
Сделано.

Владимир

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

Где-то так … Сделано.

Бинарный формат, но данные всего дерева /ни xml, json, … /, объектов, … можно выгрузить/загрузить в xml /для отладки, загрузки данных из каких-либо xml, …/.
А вот листья - объекты /любой сложности иерархии/.

Все наши "хотелки" уже кем то реализованы

PS: Интересно бывает на форуме почитать рассуждения «теоретиков» о том, что такое метаданные, …, …, …

Владимир

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

А вот листья - объекты /любой сложности иерархии/.

Вот потому-то и придется разработать GUI с scratch.
Переделывать существующие - попусту время тратить.

GUI будет основано на метаданных /ни в коем случае xml, json, txt, … /.
Бинарный формат /как ранее было сказано сериализация в xml имеется/.

Интересны были бы посты о том, какую функциональность хотелось бы иметь, помимо общепринятой.

Насколько понял тред для этого и создан.
Ранее в треде кое о чем сказал /да надеюсь и реализовано/.

Ругать и чихвостить существующие GUI занятие - «так себе».

Владимир

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

Я бы не сказал, что бросил

А я бы именно так и сказал. Потому что при «гуляющих» интересах это типичная ситуация. До тебя здесь была парочка идейных - ckotinko и steevejobs. Те тоже рвались запилить «прогрессивное» и «революционное». Итог предсказуем.

Во-вторых, это не многопоток, а многозадачность

Неважно.

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

я тут ничей бюджет не распиливаю, потому пишу правду

Я не обвиняю, если вдруг так показалось. Но отчётливо видно отсутствие цели. Вскукареки адептов «tests first» здесь были бы к месту.

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

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

и будет у тебя как у чувака на автаре

https://www.linux.org.ru/people/dyasny/profile

нафиг нужен такой гуй

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

и будет у тебя как у чувака на автаре
www.linux.org.ru/people/dyasny/profile
нафиг нужен такой гуй

На картинке — MessageBox, выданный в результате некорректной проверки успешности вызова функции, в результате чего GetLastError = 0 и FormatMessage форматирует по нему строку «Success», что мы и видим в окошке. При чем тут это к описываемому мной?

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

Хотелось бы немного о Си кой-чего сказать …

Си прекрасно подходит для системного программирования.
Он позволяет произвести разработку алгоритмов любой сложности и функциональности.

«Бантики», которые так многие ныне любят полезны лишь для «надувания щек» и трепа на конференциях, сайтах, форумах …

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

Выше сказанное говорит лишь о том что, Си предоставляет возможность записи эффективных алгоритмов.
То бишь Си позволяет разработать эффективное API для работы с объектами, …

Скорее всего тем кто не понимает этого лучше не тратить время и нервы на использование Си.

Ныне стандарты C++ как бы чегой-то там предоставляет для разработки алгоритмов.
Но зачем мне не эффективный STL или классы, когда Си позволяет реализовать API для работы с абстракциями любой сложности.
Зачем брать какую-то весьма спорную абстракцию типа class и потом
героически решать все сложности?
Нынешние стандарты C++ якобы предоставляют возможность программистам вести разработку с использование развитых абстракций.
Направление то работ похвальное, но тратить время на решение задачи удобной езды на велосипеде с квадратными колесами как-то нет желания.

PS: Особо не обращайте внимание на пост.
Он лишь о системном программировании.

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

Владимир

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

На картинке — MessageBox

а в голове - трава

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

я последний раз интересовался в 2004, безусловно многое изменилось

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

Может, да, и вот ты собственно почти подошёл к ответу, почему в GUI прогах это один поток. Сам уже догадаешься?

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

По теме треда о перспективном GUI будут предложения?

Повторюсь.

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

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

ИМХО это о «фундаменте» GUI.
То бишь все стандартные и любой иной controls не должны быть «прибитыми гвоздями» к реализации.
Реализация должна уметь предоставить всю функциональность некоего абстрактного control.

PS: Вот тогда действительно легко можно будет произвести кастомизацию и даже расширение функциональности любого control.

Владимир

anonymous
()

Мне интересно мнение на счёт WPF. Преподносится как прогрессивная. В статье на википедии (https://en.wikipedia.org/wiki/Windows_Presentation_Foundation#Interoperability) сказано что приложение стартует с двумя потоками. Один отвечает за управление интерфейсом, а второй за отрисовку графики. Отрисовку делает сам WPF, а пользователю отдаётся поток с диспетчером событий и приоритетами.

Мне оно не очень нравится, ибо переусложнено и отлаживать сложнее, чем классические системы типа Windows Forms, например, но для эстетов может самое то.

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

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

Конечно. А как только доделают модный молодёжный вэйланд, так все сразу на линукс и перейдут.

К слову, никакого сарказма, возможно так и будет. Если вейланд доделают году к 2030-му, к этому же времени большинство перейдёт на планшеты-смартфоны-ещё-какую-ересь, гугль выберет вейланд в качествы базы для андроида, то где-то так всё и выйдет.

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

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

Разве Wx не так делает? У него всё на C++, а биндинги типа сигналы и всё такое...

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

Если вейланд доделают году к 2030-му

Гы, но там будет только gtk+... Гхм.
А qt меньше не будет тормозить.

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

гугль выберет вейланд в качествы базы для андроида

Зачем? Там уже и так всё замечательно с SurfaceFlinger+WindowManager. Этот Wayland никому кроме фанатиков не нужен, во всех серьёзных продуктах что-то своё делают.

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

Зачем?

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

SurfaceFlinger+WindowManager

Ну мало ли, найдут в них какие-нибудь недостатки. Может они угнетают кого-нибудь. Да мало ли какие загоны будут в 2030.

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

решения, у которого всё … есть из коробки … это тупик.

это признак развитой системы. А тупик это иксы и верующие в чудо иксов.

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

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

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

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

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

А безопасных и быстрых языков у нас нынче не так много.

MUMPS

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

возьмем например flash игру там врядли нужно рисование чего именно векторного. Основа все равно растр.

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

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

Во-вторых, это не многопоток, а многозадачность, поскольку многоинтерпретаторы изолированы друг от друга. Проблема такого подхода заключается в том, что ты не можешь просто вызвать из одного интерпретатора функцию в контексте другого интерпретатора — как делает multiprocessing, например, и как у него отвратительно это получается делать. Мой подход на разделяемой памяти и примитивах синхронизации (вместо RPC) чисто теоретически лучше, поскольку провоцирует написание в асинхронном стиле с уменьшением связанности.

Ого, ты пишешь JS WebWorker’s для питона. Здорово.

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

А вот листья - объекты /любой сложности иерархии/.

Вот потому-то и придется разработать GUI с scratch. Переделывать существующие - попусту время тратить.

GUI будет основано на метаданных /ни в коем случае xml, json, txt, … /. Бинарный формат /как ранее было сказано сериализация в xml имеется/.

что Вы думаете, Владимир, о проекте Вир Алексея Недори (автора XDS-Modula-2/Oberon-2/C) ???

на вид, похоже – по крайней мере, по целям и подходу (компонентное сборочное программирование)

про Вир начало, по-видимому здесь

Вир-2 ожидается быть кроссплатформенным на базе LLVM с синтаксисом Go на русском языке

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

Зачем брать какую-то весьма спорную абстракцию типа class и потом героически решать все сложности? Нынешние стандарты C++ якобы предоставляют возможность программистам вести разработку с использование развитых абстракций. Направление то работ похвальное, но тратить время на решение задачи удобной езды на велосипеде с квадратными колесами как-то нет желания.

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

Владимир

вот вам: CLIP/CLOP vs pure OOP

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

В. И. Ленин, полн. собр. соч. — 5-е изд. — Т. 44. — С. 579: Беседа В. И. Ленина с А. В. Луначарским

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

почему даже жирные приложения на жаве 90-х годов кушали пару десятков мегабайт памяти, а электрон с чистым листом начинается от сотки.

Это же неправда. Electron, даже не с чистым листом, а дефолтным превью в котором рендерится svg-анимация - в памяти занимает 40Mb (33-39).

Зачем ты врёшь, можешь объяснить?

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

Это же неправда. Electron, даже не с чистым листом, а дефолтным превью в котором рендерится svg-анимация - в памяти занимает 40Mb (33-39).

У меня от сотки.

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

Ты понимаешь что WS в Process Explorer включает в себя все шаренные либы используемые процессом, все отображенные в память файлы и прочие ресурсы, которые так же шарятся между процессами?

Понимаешь разницу между частным набором и рабочим?

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

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

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

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

В досовских софтинах частенько гуй был не объектным, так тчо не надо мне тут.

Как следствие он был иерархическим. То есть, чтобы в другом окне открыть диалог и что-то сделать, надо было выйти со всех вложенных диалоговых окошек в текущем. Иначе как было понять, куда ввод от клавы девать? А мышки были далего не у всех.

ООП для ГУИ это то, что доктор прописал.

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

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

Поддерживаю

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

В формате xlsx. Это по сути xml сжатый в zip. Готовый решения есть , но тормозные. Пришлось на коленке свой класс сделать для потокового формирования отчета.

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

Да-да, даже для разных окон перерисовка отправляется в единую главную очередь потока GUI.

А как иначе? Пусть есть клик мышкой и клавиатурная комбинация, переключающая окна.

Если вначале обработать клик, а потом клаву, то кнопка нажмется на первом окне. А если обработать клаву, а потом клик, то кнопка нажмется на втором окне.

Так что порядок важен.

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

Кек. Может сначала следует научиться правильно считать память занимаемую процессами, мань?

Private Bytes - частный набор, это память реально [b]запрошенная[/b] процессом, которая ему выделенная, но не факт что используется. В том числе, сюда включены те страницы памяти которые выгружены в файл подкачки.

Working Set = Private Bytes + all shared resource. Сюда включаются размеры абсолютно всех библиотек в системе, которые использует процесс.

Теперь отправляйся в старый добрый taskmgr.exe, выстави там себе отображение столбца - Рабочий [b]активный[/b] набор , который и показывает фактически используемую память процессом.

И вот потом считай.

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

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

Ты понимаешь что WS в Process Explorer включает в себя все шаренные либы используемые процессом, все отображенные в память файлы и прочие ресурсы, которые так же шарятся между процессами?

https://postimg.cc/PCYzXV47 — добавил больше столбцов
https://postimg.cc/nsmKLRG5 — структура памяти самого жирного процесса (--type=gpu-process):

Математика такая:
Private = Private WS + Sharable WS - Shared WS + (выделенные, но не использованные страницы)
Total WS = Private WS + Sharable WS

Общее потребление физической памяти процессами — это сумма «Private WS + Sharable WS - Shared WS» для всех процессов плюс уникальные блоки Shared WS.

Конкретно по этому запущенному электрону самые большие разделяемые блоки памяти — это electron.exe, node.dll, и v8_context_snapshot.bin (последний не загружается процессом GPU). Эти три бинарника весят 18.1 Мб. Оставшиеся 7-11 Мб в основном занимают системные либы — отбросим их полностью при расчете потребленной оперативки.

Главный процесс: Private WS + Sharable WS - Shared WS = 15.6 + 35.9 - 28.1 = 23.4
GPU процесс: Private WS + Sharable WS - Shared WS = 20.0 + 24.9 - 13.6 = 31.3
Renderer: Private WS + Sharable WS - Shared WS = 17.0 + 35.6 - 24.2 = 28.4

Итого: 23.4 + 31.3 + 28.4 + 18.1 = 101.2 мегабайт. Как в воду смотрел. Близкую цифру можно получить, если просуммировать столбец «Private bytes»: 21.7 + 63.7 + 28.6 = 114.0 мегабайт. Но суммировать одно лишь Private WS? Извините, это некорректно.

byko3y ★★★★
() автор топика
Последнее исправление: byko3y (всего исправлений: 2)
Ответ на: комментарий от Psilocybe

А как иначе? Пусть есть клик мышкой и клавиатурная комбинация, переключающая окна.
Если вначале обработать клик, а потом клаву, то кнопка нажмется на первом окне. А если обработать клаву, а потом клик, то кнопка нажмется на втором окне

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

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

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

У меня маленький файл подкачки и много оперативки, потому подкачка не отсвечивает.

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

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

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

X512 ★★★★★
()

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

Всегда интересовало, «писечка» там женская или мужская? Что мне представлять?

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