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

★★★★

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

QtQuick/QML тыкал?

EXL ★★★★★
()

отсюда главный цикл

Обколются своим линупсом и js-ом и начинают бредить. Почитай хоть про общую теорию работы пекича.

peregrine ★★★★★
()

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

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

Qt какое-то.

&

Будет переписывать под с++20.

anonymous
()

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

выключатели на тач скринах, которые работают только на «вкл-выкл»

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

zendrz ★★
()

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

Ещё в Macromedia/Adobe Flash была разделена логика и рисование. Для каждого визуального объекта (MovieClip) хранится векторная картинка того что в него нарисовано и растровый кеш. Теоретически картинку можно рисовать полностью независимо от логики и при зависшем скрипте.

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

Во Flash как раз так всё и работает: при вызове команд рисования из скрипта, они просто запоминаются в памяти и ничего не рисуется. Рисованием занимается отдельная система читающая и рисующая записанные команды. При необходимости она может перерисовать всё что угодно без вызова перерисовки у скрипта.

есть задачи фонового скачивания файлов

Никто не мешает в любом тулките создавать фоновые потоки для таких задач.

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 4)

веб-страница выглядит относительно живо при висящем жавоскрипте

Щито? Ты попробуй сделать синхронный хттп запрос и посмотри как живенько выглядит твоя страница.

Дальше не читал.

ya-betmen ★★★★★
()

Проблема в том, что все знают «КАК ПРАВИЛЬНО», но

НИКТО ни чего не делает

123456

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

QtQuick/QML тыкал?

Чем он отличается от десятков аналогичных механизмов пользовательских интерфейсов? Да, это реализация для Qt/C++/JS, неплохая реализация, но в целом это те же мейнстримовые яйца под другим углом. Что они смогли сделать отрисовку отдельным тредом? Блин, игроделы так делают уже лет двадцать. Из знакомых мне либ Virtual Tree и Developer Express умели делать отложенную рисовку безо всяких потоков, то есть, устраняя проблему «я изменил 30 свойств и у меня перерисовался интерфейс 30 раз», устранением которой гордятся создатели QML. А если остальное рисование становится банальным, после расчета положений элементов, ширины шрифтов, и прочего, то и смысла в потоке остается немного.

byko3y ★★★★
() автор топика

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

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

НИКТО ни чего не делает

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

Ни одна обезьяна не сумела стать человеком

123456

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

SerenityOS. Сделали свой тулкит на основе современного C++ с лямбдами для колбеков

Кто-то решил скопирайтить древний GUI тулкит? Похоже на Qt, к слову: Window = QWindow, QFileDialog = FilePicker, HorizontalBoxLayout = QHBoxLayout, и так далее.

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

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

anonymous
()

Так как надо?

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

Похоже на Qt, к слову: Window = QWindow, QFileDialog = FilePicker, HorizontalBoxLayout = QHBoxLayout, и так далее.

А как должно быть? Без окон, диалогов, разметок? В основе все тулкиты похожи друг на друга.

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

Ещё в Macromedia/Adobe Flash была разделена логика и рисование. Для каждого визуального объекта (MovieClip) хранится векторная картинка того что в него нарисовано и растровый кеш. Теоретически картинку можно рисовать полностью независимо от логики и при зависшем скрипте

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

Во Flash как раз так всё и работает: при вызове команд рисования из скрипта, они просто запоминаются в памяти и ничего не рисуется. Рисованием занимается отдельная система читающая и рисующая записанные команды. При необходимости она может перерисовать всё что угодно без вызова перерисовки у скрипта

Но логика рисования и логика построения модели объектов для последующего рисования реализуцются абсолютно разными инструментами. Примерно как и в браузере. В этом плане QML даже выгоднее, потому что все-таки дает возможность писать на крестах обе задачи. А вот во флеше и браузере ты можешь писать только логику, при этом рисовка тебе неподконтрольна.

Никто не мешает в любом тулките создавать фоновые потоки для таких задач

Более того — запускать отдельные процессы для этого. Слишком жирная получается изоляция. не повзаимодействуешь особо.

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

GUI разный бывает …
Обычно под GUI подразумевают диалоговые окна.
То бишь сами себя «бьют по рукам», а потом героически пытаются «улучшить» интерфейс.

Почему так?

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

То бишь API похоже на «танцора» …

123456

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

Щито? Ты попробуй сделать синхронный хттп запрос и посмотри как живенько выглядит твоя страница

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

главный поток->растеризатор->композитор->поток GPU.

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

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

Но тебя не смущает макака с делфи.

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

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

И, тем не менее, Chromium рисует страницу плиткой.

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

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

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

А как должно быть? Без окон, диалогов, разметок? В основе все тулкиты похожи друг на друга

GTK значительно отличается, nanogui не такое, некрестовые либы и вовсе другие. Да, есть и без разметок, особенно если либа малогабаритная.

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

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

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

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

GTK значительно отличается

лол, чем? Всё тоже самое. В GTK так уж точно.

И некрестовые либы все одинаковые. Ты просто разбиваешь на сетку, и потом рисуешь. В вебе точно также.

fsb4000 ★★★★★
()

Пользовательский ввод - самое медленное, что есть на планете, зачем на это быстро реагировать?

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

как будет готово — вываливаем на экран

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

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

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

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

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

И некрестовые либы все одинаковые. Ты просто разбиваешь на сетку, и потом рисуешь. В вебе точно также

В вебе сетка появилась последние несколько лет с появлением CSS Grid Layout, а до этого было:

https://en.wikipedia.org/wiki/Holy_grail_(web_design)

Для справки: https://ru.wikipedia.org/wiki/Святой_Грааль
«Легендарные рыцари Круглого стола проводили свою жизнь в бесплодных поисках Святого Грааля»

Можно даже сказать, что таки CSS Flexbox и Grid Layout были взяты таки из Qt. Правда, форма итоговой реализации разительным образом отличается.

В GTK так уж точно

Знаешь, мне кажется, что там по диалогам файлов даже ближе к GTK, чем к Qt. Не исключено, что и надергано по кускам.

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

«Легендарные рыцари Круглого стола проводили свою жизнь в бесплодных поисках Святого Грааля»

Исполнение заповедей Бога и есть - источник жизни.
Кто этого не понимает

Ищет Святой Грааль

123456

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

Пользовательский ввод - самое медленное, что есть на планете, зачем на это быстро реагировать?

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

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

Так-то с твоей позиции можно сказать «нахер нам GUI — можно же программировать коробки из переключателей и светодиодов». А вот нельзя.

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

Музыканты умудряются распознавать единицы миллисекунд отличия ритма, и в эти единицы миллисекунд попадать — как они это делают, если мартышки такие медленные?

Так что делать «мартышкам», которые GUI разрабатывают?

anonymous
()

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

встречал

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

ну и? ты хочешь сказать что одно состояние это хорошо или скорее плохо? имхо, это скорее плохо.

вот например в Dolphin SmallTalk – интерпретируемый смоллток под винду, открытые исходники, интеграция с ActiveX и прочими вендотехнологиями:

на ютубе есть штук шесть роликов от автора – компании objectarts

где последовательно прорабатываются примеры в компонентизацию гуя и среды разработки.

  • берём хелловорд простой – см. примеры из поставки

  • смотрим первый ролик и создаём гуй программатически в objectInitialize / initialize который вызывается после конструктора – второй хелловорд

  • смотрим Better Hello world ролик и переходим к MVC то есть, MVP паттерну – Model-View-Presenter. в ролике есть вдохновляющий пример про то, что аналогично тому как в в Delphi TComponent отдельно устанавливается в панель компонентов в тулбаре – здесь начинаем разработку с модели (отсеивается 90% быдломышекликателей – над моделью думать надо, хотя есть и стандартные простые типа как asView в примере) и переходим к визуальному View (типа как в дельфи мышкой GUI накликали, набросав из панелей на форму) – но тут привязываем к модели и к Presenter (контроллер из MVC). здесь никакой логики в OnButtonClick – обработка делается в контроллере (аналогично TAction из дельфей).

вдохновляющий пример из обучающего видео: создали селектор нового обработчика на форме – метод не реализован. вываливаемся в отладчик. не вопрос! тут же парой кликов создаём отсутствующий метод, и прописываем его обработку, сохраняем/компилируем (один этот метод, то есть, быстро). и продолжаем перезапущенное из отладчика, уже в только что дописанную реализацию.

  • далее он в последующих роликах развивает эту мысль в идею, что MVC / MVP /MVVM паттерны получаются композабельны, составимы. то есть, это более полноценные компоненты чем те же TComponent.

  • далее в ролике про подключение iTunes показывается, как можно в полпинка прикрутить к GUI COM-автоматизацию и готовые бинарные компоненты – создать из type library прокси класс к COM coclass и интерфейсам, подёргать за события в EventSink, включить логирование событий и прикрутить свои MVP поверх них.

  • далее нужно понимать что объекты могут храниться в ООСУБД типа GemStone, динамически реплицироваться по сети, синхронизироваться объектными брокерами через протоколы вроде TeaTime из OpenCobalt и т.п.

  • в том же OpenCobalt новый его коммерческий форк постепенно переписывали из SmallTalk на Nim. есть простой компилируемый через Nim как бы смоллток времени компиляции – Spry. в Nim самом есть метапрограммирование и т.п. в смоллтоке самом тыщу лет есть FFI.

  • далее например есть PetitParser – композабельный на парсер-комбинаторах и PEG. а сам смоллток – и среда, и компилятор и парсер давным-давно доступны через предопределённые объекты этой живущей в образе среды.

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

  • далее это надо как-то инкрементально развивать, раскручивать из такого вот прототипа в образе с объектами-акторами.

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

смоллток здесь ну как бы такой пример метапрог сам на себе – то есть, среды из объектного языка. ну или скорее, объектного метаязыка, точнее, метаобъектного (метаклассного) метаязыка – то есть, метаобъектного протокола, например.

вся сложность программирования на смоллтоке состоит в том, что нужно знать «словарь» такого метаязыка, то есть, готовые классы и методы платформы (и как их обернуть).

хотя в ролике у авторов Dolphin SmallTalk довольно лихо получается – взяли и через IntelliSense подсказкой таб-дополнением почти всё набили. остаётся загадкой, откуда он помнит все эти классы и методы, и обёртки над ними (хотя бойлерплейт и минимален, но всё-таки ещё не DSL).

здесь опять же, нормальные люди аккуратно создают свой пакет для экспериментов – пространство имён, категорию объектного протокола, в котором и резвятся. одной кнопкой что в Dolphin SmallTalk, что в Pharo можно как выгрузить из образа в файл весь пакет целиком, так и снова загрузить/установить.

всё это делается в таком вот Refactoring Class Browser очень бодро и весело, в пару мышекликов: создать класс как потомка, ему метод, реализовать интерфейс, отрефакторить, добавить тесты. в том же Cincom аналогично парой мышекликов реализуется MVC / Presenter из MVP из готовых потомков, в Dolpin похоже просто GUI не допилили, но тоже возможно реализовать.

опять же, есть REPL (Workspace), Transcript, нормальный текстовый редактор типа Scintilla, создание инсталлятором самодостаточного бинаря без компилятора с выпиливанием всего лишнего из образа, и т.п.

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

смоллток здесь как один из вариантов такой настраиваемой «сам на себе» программной среды живущих объектов в образе – но не единственный.

например, Oberon OS классический;AOS/ BlueBottle на Active Oberon; Inferno на Limbo; OpenGenera Symbolics Common Lisp Operating Environment – а не просто ОС.

везде ровно та же самая идея – 1) компонентная среда, 2)активных объектов 3)исполняющих процессы – а не просто голые консольные процессы и станочки-приложения.

BlackBox Component Pascal – в основе лежит BlackBox Component Framework с Carier/Rider паттернами аналогично MVC; документно-ориентированный интерфейс; бинарные замороженные объекты/компоненты/документы; активности явно не выражены, но могут запускаться виджетами из документов/компонентов – либо реализовываться кооперативно (см. И.Ермаков) или поверх;

AOS – Active Oberon/ Active Objects как набор акторов

Zonnon – протоколы как средства объединения композабельности, можно явно программировать протокол (ср. Аду и task с рандеву или те же активные объекты/акторы)

метаобъектный протокол в CLOS; в OpenGenera явно есть средства для «True Unix GUI» из объектов в стиле PowerShell только на коммон лиспе (и Flavors а не CLOS)

Inferno, Plan 9 – есть Plumber, который роутит событие по настраиваемым паттернами правилам сразу в нужное приложение запускаясь из средней мышекнопки

да тот же Factor, наконец.


практически везде есть языковая/программная среда живых объектов в образе – настраиваемая под себя самим программистом – эдакий метапрог сам на себе

сравни это с cockpit-style IDE.

это ж каменный век по сравнению с ними, с такими средами – и уже лет 30 почти ничего в этих IDE по сути то и не изменяется.

  • только текст, а не гипертекст

  • livecoding ограничен

  • плагины пишутся трудоёмко если вообще есть среди готовых

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

вот тебе «свежих» идей для GUI. да просто старые ещё не совсем осилили.

anonymous
()

см. также Morphic GUI в Pharo/Squeak SmallTalk.

те же «композабельные объекты» как акторы, с раздельным поведением и состоянием.

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

Из знакомых мне либ Virtual Tree и Developer Express умели делать отложенную рисовку безо всяких потоков, то есть, устраняя проблему «я изменил 30 свойств и у меня перерисовался интерфейс 30 раз», устранением которой гордятся создатели QML

опять же, все эти DOM/Shadow DOM/Virtual DOM по сути есть костыли к «ООП в стиле C++», представляющему такую объектную модель компаунд композабельных документов.

а по сути нужен какой-то протокол/категория метакласса из смоллтока/объектный протокол ну или метаобъектный протокол вроде MOP из CLOS.

а DOM-2 не нужен, родной. лишняя навязанная костылеООП сучность, из-за которой всё тормозит, свистит и пердит – но не работает.

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

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

поиграй в любую тактико-стратегическую игрушку, с долгоиграющими процессами типа апгрейда/ресерча и экономикой, с перезапуском процессов.

везде это более наглядно и удобно представлено чем в типичной среде «ОС и приложения и 10500 костылей и подпорок».

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

Кто не согласен с этим пусть первый вбросит в форум пост

ну я не согласен

«Конструктор графического пользовательского интерфейса» (или «GUI-конструктор»), также известный как «GUI-редактор», является инструментарием разработки программного обеспечения, который упрощает создание графического интерфейса пользователя (GUI), позволяя разработчику упорядочить элементы интерфейса (часто называемые виджетами) используя редактор drag-and-drool WYSIWYG.

а нужен DWIM, WYSIWIM интерфейс. наподобие того же смоллтокового окна Workspace : Do it, evaluate it, show it. и/или, Emacs org-mode C-c C-c выполнения «блоков кода».

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

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

святая граната антиоховская

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

можно придумать получше текущего гуя.

например, пусть есть некая среда типа «метапрог сам на себе».

таких вот композабельных MVP Model-View_Presenter объектов, активных объектов, акторов. для дэшборда реактивного гуя.

и программируемый интерфейс к нему – тоже «сам на себе». простой как палка с верёвками:

текстовый редактор типа окна Workspace REPL из Dolphin SmallTalk. с табдополнением, подстановкой, поиском, гиперссылками.

внизу окна три вкладки: Doc/WEB/Code. WEB здесь в смысле Literate Programming Single Source document Дональда нашего Кнута – а не то, что ты подумал.

вверху каждой вкладки ещё две: Logical/Physical.

в Logical «логические» чанки, в Physical – физические файлы.

ну или не вкладки, а интерфейс в духе NeXT file browser или SmallTalk refactoring browser.

над окном тулбар с тремя кнопками: WEAVE, PARSE, TANGLE.

кнопка PARSE с белым фоном если не редактировалось, с красным если есть ошибки парсинга WEB документа, с зелёным если WEB сохранён и распарсен.

пишем себе самодостаточные смысловые единицы в LitProg разметке в вкладке WEB. сохраняем, парсим. ну или сразу нажимаем WEAVE/TANGLE.

сначала

  • TANGLE – из смыслосодержащего Single Source WEB документа на вкладке WEB парсятся чанки «блоков документации», «блоков кода», «блоков данных (и метаданных с метамоделями данных)».

из вкладки WEB обновляется содержимое вкладки Code, в ней подвкладки «логические» чанки «блоков кода» (с их именами) и «физические» – файлы.

затем

  • WEAVE – из вкладки WEB обновляется вкладка Doc. В ней тоже есть подвкладки:

** DocView как «paper document» типа PDF литературного с откомментированными исходниками – с индексами, гиперссылками, прочими кросс-ссылками

*** other Presenter view как «compound document» типа .odc в BlackBox с внедрёнными виджетами, на самом обероне как модули / активные объекты написанные

*** compose MVVM – other MVP-MVP View, типа реактивного гуя.

ну там, где «жгутики с проводочками» – то есть, схема соединений. отдельных таких виджетов/гаджетов/активных объектов в общий composite app Active Dashboard.

и всё это должно

  • программироваться и настраиваться в полппинка самим программирующим пользователем

  • быть свистящим, пердящим, анимэрованным – настраиваемым и адаптируемым под конкретные места применения, легко как скин

  • позволять LiveCoding и выполнение в духе REPL.

ну то есть, например как коммандеры кнопкой в BlackBox .odc документах позволяют запускать новый модуль и метод.

или как в Jupyter notebook – передать текущие данные из этого виджета/блока/модели данных ещё далее куда-то, по жгутикам и квадратикам, ога.

в идеале мы делаем эдакую тыкалку из «жгутиков, квадратиков и проводочков», и работаем через неё.

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

конченному юзеру влезать в это совсем не обязательно.

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

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

например, пусть есть некая среда типа «метапрог сам на себе».

ИМХО нужно четко сформулировать каков должен быть GUI и разработать его, а

Метапрог из палок не разрабатывать
anonymous
()
Ответ на: комментарий от anonymous

drag-and-drop WYSIWYG.

drug-and-drool вивисек

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

по диалогам файлов даже ближе к GTK

Хуже чем в гы-ты-ка уже не сделать. Подумать только, файловый диалог не умеет в сортировку по суффиксам.

thunar ★★★★★
()

Всё это и даже больше делает Tcl/Tk

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

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

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

Метапрог из палок не разрабатывать

ща по-быстрому накидаем из «говна и палок» – и если попадёт на вентилятор (см. на ютубе как гипопотамчики бодро срутся, хвостиком размахивая) – то взлетит

=;^)))

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

ИМХО нужно четко сформулировать каков должен быть GUI и разработать его

Предлагайте …

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