Здравствуйте, Aquilaware, Вы писали:

A>Ништяк? Абсолютный. Не нужно никаких клиентов и серверов, все происходит как в самом обычном приложении.

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

Здравствуйте, rm2, Вы писали:

rm2>Здравствуйте, Aquilaware, Вы писали:

rm2>Ништяк оно будет, когда будет легко и просто собирать приложения в дизайнере форм. не думая о html тегах, думах, css, Js, и всем остальном прочем. накидал полей и кнопок, обработал события, все, интерфейс готов.

Согласен. Для продуктивной работы это и есть суть ништяка. Но есть дилемма: концепция дизайнера подразумевает пиксельную разметку, когда достигается WYSIWYG (what you see is what you get, что ты видищь то и получаешь).

Но как быть с responsive layout (отзывчивой разметкой), которая сама подстраивается под DPI и размеры экрана? Все современные UI именно такие, и это не прихоть их разработчиков, а реальность, которая надиктована широчайшим зоопарком пользовательских устройств появившихся в последнее десятилетие.

Поэтому возникает вопрос: как сделать такой дизайнер, который бы мог обеспечить поддержку и WYSIWYG и responsive layout в одном флаконе? Есть ли существующие примеры таких дизайнеров?

Здравствуйте, Shmj, Вы писали:

S>Великая мечта — пишешь один раз, отлаживаешь используешь везде — все-таки приближается к реальности.
https://youtu.be/DiA2hOqoL9k?t=600

Здравствуйте, vaa, Вы писали:

S>>Великая мечта — пишешь один раз, отлаживаешь используешь везде — все-таки приближается к реальности.
vaa>https://youtu.be/DiA2hOqoL9k?t=600

Операционная среда Оберон. Очень интересно, но напрягает то, что опять же это тюрьма одного языка. Если я захочу использовать сервисы этой среды, например, из С#, то как это сделать? Ответа готовго нет. В этом и корневой проёб этого проекта, очередная тюрьма. Из-за такого узкого взгляда на суть вещей и имеем то, что имеем.

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

Приведу пример по этой теме не относящийся к UI. Есть приложение работающее в области forensics. Приложение должно уметь читать архивы и прочие файловые контейнеры — само собой смотреть в .ZIP, уметь заглядывать в .MSI (который не является чистым архивом, а скорее инсталлятором). Чтобы смотреть в .MSI как следует, нужно уметь смотреть и в .CAB архивы. И т. д. насколько хватает сил.

Вопрос, как это сделать? Очевидный вариант — это натаскать библиотек по этим темам и дёргать их из кода приложения. Но получится так, что велосипед будет изобретаться вновь и вновь в каждом таком приложении. Почему бы тогда не заиспользовать функции ОС? Аргументов против этого несколько: а) таких функций зачастую нет б) эти функции могут быть нейстойчивыми из-за конфигурации/версии ОС, что будет мешать некоторым типам приложений, например, в которых сделан упор на безопасности или на работе из коробки.

И здесь на сцену выходит так называемая операционная среда (operating environment). Операционная среда — это как ОС, только она работает поверх существующего хоста.

Яркий пример — Windows 3.1 — это была операционная среда, работающая поверх операционной системы DOS. Но мало кто знает, что она имела и режим, в котором Windows выступала как operating runtime (операционная среда выполнения). В этом режиме Windows могла идти как библиотека к приложению, обеспечивая некоторые его "хотелки" такие как, например, UI. А приложение линковалось с этой "библиотекой" в момент построения. Таким образом, на выходе компилятора получался артифакт, который был способен использовать полноценный UI с окнами, кнопками и всем остальным характерным для Windows, но при этом оставался всего-лишь DOS .exe файлом способным работать на голом DOS`е без установленной Windows. Это и есть operating runtime, концепция, которая сейчас неизвестна для большинства.

Так вот. Если бы был такой operating runtime сейчас, то цены ему бы не было. Во-первых, он мог бы закрывать назревшие проблемы кроссплатформенного UI, во-вторых, решать и другие задачи как в примере с архивами. Этот operating runtime мог бы идти как набор пакетов для множества языковых экосистем. Например, хотим UI, подключаем пакет, и вуаля — всё готово, занимаемся решением своей задачи, а не изобретением очередных велосипедов. Хотим смотреть в архивы? Подключаем еще один пакет, и вуаля.

И всё это могло бы быть доступно для многих языков одновременно, а не так как сейчас — имеем тесную связку "технология X ↔ язык Y", что приводит к мультипликативному росту сложности X * Y, вместо того, чтобы оставаться X + Y.

Эх мечты, мечты...

Здравствуйте, Aquilaware, Вы писали:

A>Яркий пример — Windows 3.1 — это была операционная среда, работающая поверх операционной системы DOS. Но мало кто знает, что она имела и режим, в котором Windows выступала как operating runtime (операционная среда выполнения). В этом режиме Windows могла идти

мне казалось я знаю win 3 — 3.11 но о таком не слыхал, что это за режим ?



A>Так вот. Если бы был такой operating runtime сейчас, то цены ему бы не было. Во-первых, он мог бы закрывать назревшие проблемы кроссплатформенного UI, во-вторых, решать и другие задачи как в примере с архивами. Этот operating runtime мог бы идти как набор пакетов для множества языковых экосистем. Например, хотим UI, подключаем пакет, и вуаля — всё готово, занимаемся решением своей задачи, а не изобретением очередных велосипедов. Хотим смотреть в архивы? Подключаем еще один пакет, и вуаля.

в docker можно писать и GUI приложения

Здравствуйте, sergey2b, Вы писали:

S>мне казалось я знаю win 3 — 3.11 но о таком не слыхал, что это за режим ?

Давно это было, подробностей уже и не припомню. Помню еще что Windows 3.1 умела в ROM образы заходить, опять же, малоизвестная фича из этой же области.

S>в docker можно писать и GUI приложения

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

Здравствуйте, Aquilaware, Вы писали:

A>HTML движок есть готовый на всех более-менее распространненых ОС. Но самое интересное это то, что реализация такой можели приложений получилась бы относительно компактной, так как львинная доля работы ложится на плечи уже готового HTML движка, который по-умолчанию брался бы из ОС и не требовал распространения в составе самого приложения.

Либо все ОС завязывать нужно на один движок и одной версии, либо будут интересные результаты на разных системах.
Сейчас конечно время практически победившего Blink, но пока ещё встречаются сайты, которые плывут на разных браузерах.

A>Почему HTML? Потому что это де-факто стандарт UI.

Этот стандарт без JS не жизнеспособен

A>Многие конечно возразят, что нативные контролы лучше и т. д., но вы видели в каком состоянии эти контролы в последних релизах ОС? Возьмём High-DPI монитор и сможем быстро увидим, что те же Win32 сontrols — это просто динозавры, которые рендерятся в высоком разрешении с хаками и некрасивостями. Да, они были отточены для 96 DPI, но на high-DPI на них трудно смотреть без слёз.

Нативные контролы — это привычный вид и поведение. Если человек сидит на данной ОС, значит его устраивает вид нативных контролов.

A>И вот он, HTML. Скоромно сияет в сторонке, как диаманд на фоне всего этого уныния вокруг и ждет своего часа.

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

Здравствуйте, Shmj, Вы писали:

S>Великая мечта — пишешь один раз, отлаживаешь используешь везде — все-таки приближается к реальности.
FoxPro 2.6 for DOS
самое оно.
самый удобный интерфейс на HTML проиграет в скорости и удобстве ввода.
изначально HTML это способ представления знаний и данных, т.е. удобная интерактивная библиотека для ученых.
первичный интерактив HTML UI — клик мышкой по ссылке. не более. сам же HTML это вообще протокол, лишенный интерактивности по сути.
Замена нормальному интерфейсу так себе.
Достаточно попробовать день посидеть без мышки и тачпада в интернете.
я уже не говорю про веб-приложения где нужно активно вводить данные.

Здравствуйте, velkin, Вы писали:

S>>Основные: React Native (HTML), Flutter (Canvas), Xamarin (как я понял, вызывают API ОС?)
S>>Есть половинчатые — типа ElectronJS — не поддерживают моб.
S>>Кто что может сказать по этому добру? Тупиковая ветвь или это наше ебудущее?

V>Попробую выразиться как-то помягче, это лютое говнище. Нормальные приложения на том же C/C++ будут рвать их в хламину.

Стоит заметить, что нормальных пользовательских приложений на С++ становится все меньше и меньше. Старые отживают своё, а новых не появляется. Вместо них стартуют проекты на веб-технологиях.

Весь десктоп целиком плавно перетекает в веб уже много лет.

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

Этих профи надо примерно в 10...100 раз больше. Где их взять, откуда они придут, если до сих пор спрос на программистов дико перегрет?

V>Говносервисы спасает лишь то, что реально крутых программистов в мире не так уж и много.

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

Здравствуйте, Pauel, Вы писали:

P>Весь десктоп целиком плавно перетекает в веб уже много лет.

Кстати, интересно было бы посмотреть на то, чем пользуются на десктопе. Как по мне, всё основное осталось на том, на чём и было написано. Оно, как правило, большое, тяжёлое, требует развитого и сложного UI.
Всё то, что проще условных Фотошопов и Автокадов, в принципе на десктопе не развивается, а уходит даже не в веб, а в приложения на телефоне: мессенджеры, ютьб, банковские приложения, даже Госуслуги. Что из десктопного уходит в веб?

vaa>FoxPro 2.6 for DOS
vaa>самое оно.
vaa>самый удобный интерфейс на HTML проиграет в скорости и удобстве ввода.
Кстати, текстовый режим выводится в html 1:1 практически без дополнительных трудозатрат. Почему это до сих пор не взлетело? Учитывая, с какой радостью публика восприняла чОрные лапидарные иконки и всю эту примитивизацию UI "назад в windows 1.0". Почему до сих пор микрософт не объявил это ультрасовременным подходом и не переделал обратно в текстовый режим все свои сайты и продукты?

Здравствуйте, Osaka, Вы писали:

vaa>>FoxPro 2.6 for DOS
vaa>>самое оно.
vaa>>самый удобный интерфейс на HTML проиграет в скорости и удобстве ввода.
O>Кстати, текстовый режим выводится в html 1:1 практически без дополнительных трудозатрат. Почему это до сих пор не взлетело? Учитывая, с какой радостью публика восприняла чОрные лапидарные иконки и всю эту примитивизацию UI "назад в windows 1.0". Почему до сих пор микрософт не объявил это ультрасовременным подходом и не переделал обратно в текстовый режим все свои сайты и продукты?
ни разу не видел, даже в таких продуктах как 1c тонкий клиент и им подобным, не дотягивает даже до вин-форм.
не хватает безмышевого режима работы. после открытия страницы, нужно полчаса жать таб чтобы выйти на ввод запроса например.
вот свежее:
https://demo.lsfusion.org/mycompany/

вижу customer(F5) вкладка POS
жму — и вуаля — перегрузка страницы.
веб и html не гарантирует поведение.
вообще все уже было в java web start.
почему-то мало кто знает и использует.
это было бы идеальным решением для нормального ПО.

Перефразирую более обобщённо — для Web нужна виртуальная машина а-ля .Net/Java/QML рантайм — то, против чего Google боролась, но к чему в итоге придёт

Здравствуйте, Skorodum, Вы писали:

S>Electron плохой выбор для текстового мессенджеров, т.к. даже небольшие лаги в набирании текста раздражают.

VS Code, который основан на Electron совсем не лагает при вводе текста, и вообще очень отзывчивый. Это один из самых быстрых (в смысле латентности ввода) редакторов. Субъективно — намного отзывчевее Emacs'а.

Здравствуйте, vaa, Вы писали:

vaa>вижу customer(F5) вкладка POS
vaa>жму — и вуаля — перегрузка страницы.
vaa>веб и html не гарантирует поведение.

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

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

Приведу пример: приложение Apple Music на айфонах использует именно HTML для своего UI. Может ли конечный пользователь это как-то определить, может оно кривое какое-нибудь? Абсолютно нет. Всё отполировано настолько, что не подкопаешься. Поэтому когда есть такой мощный стандарт, все дисскуссии по поводу того, на чем делать тот или иной UI со временем будут уходить в небытие.

Тут пожалуй есть единственная проблема — это проблема восприятия. Многие воспринимают HTML как некий блокнот, в котором работает скриптъ, есть перегрузки страниц с потерей состояния и это всё бяка-бяка, кака-кака. Но это иллюзия идущая от вэба. На самом деле, HTML просто задаёт разметку UI, а наполнятся и моцифицироваться она может из любого языка програмирования. То же самое относится и к состоянию — оно может иметь любое время жизни. Проще всего смотреть на HTML документ как на window (окно) или даже как на элемент управления (control). Например, закрыли окно и потеряли состояние, т.к. оно более не нужно. Логично ведь? Так же происходит и в MFC, и в Windows Forms и в WPF. Открыли новое окно, UI нарисовался из разметки, приобрёл новое состояние. Дернули элемент управления — получили событие, промодифицировали свойство кнопки. Эта известные всем UI'щикам истины, и в HTML они работают точно так же.

Никаких серверов, портов и прочего для этого не нужно! Это просто опциональные надстройки для вэба. Берем окно, кладем в него HTML и дёргаем DOM. Обеспечиваем работу с ресурсами, чтобы можно было ссылатся, например, на файлы стилей прямо из исполняемого файла без всяких HTTP серверов. Всё. UI готов.

Хотим быстрого старта? Берем какой-нибудь готовый CSS ништяк, например, Bootstrap. Если буквально — кладем этот готовый скачанный CSS файл в наш проект как ресурс и ссылаемся на него из HTML. Получаем на выходе очень достойный UI за очень короткое время, c полной поддержкой high-DPI, разных форм-факторов устройств и разных платформ.

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

Здравствуйте, ins-omnia, Вы писали:

IO>VS Code, который основан на Electron совсем не лагает при вводе текста
Это как бы ожидается от любого редактора.

IO> Субъективно — намного отзывчевее Emacs'а.
Это лишь говорит о том, что emacs — говно

Здравствуйте, CreatorCray, Вы писали:

IO>>VS Code, который основан на Electron совсем не лагает при вводе текста
CC>Это как бы ожидается от любого редактора.

Это должно ожидаться от любого редактора по-хорошему. По факту многие популярные IDE тормозят при вводе текста. Либо из-за движка своего редактора, либо из-за довесков всякого интеллисенса. Почившим недавно в бозе Atom'ом вообще нельзя было пользоваться из-за этого. При этом его многие хвалили.

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

Здравствуйте, Pauel, Вы писали:

P>Весь десктоп целиком плавно перетекает в веб уже много лет.

Бредятина из мира веб-мартышек. Сижу на десктопе, все приложения — адекватный нэйтив. Идиотизмом типа Электрона не пользуюсь в принципе. В моём мире "никто никуда не идёт". Более того — идёт инженерная борьба за скорость, чтобы юзер в Винде с 16 гигами не чувствовал себя владельцем домофона.

Здравствуйте, Aquilaware, Вы писали:

A>UI с поддержкой горячих клавиш, правильной табуляцией, правильным автофокусом и прочим делается на HTML'e относительно легко

Зачем расхваливать это "разметочное позорище", будто оно хоть как-то заменяет настоящий интерфейс?! Ерунду порете, будто UI — это кнопочки и текстовые поля! Давай, покажи мне настоящий docking на HTML! (как в VisualStudio) Или адекватный обмен данными с диалоговыми окнами. Да чё там, ты даже файл не сохранишь толком, если будешь сидеть в гипертекстовом ушлёпищще! И при всех этих недостатках находятся клоуны, которые утверждают, что HTML заменяет вендодесктоп! Студенты, ваши калькуляторы — это ещё не весь десктоп! Напишите хотя бы что-то близкое по удобству и скорости а-ля VideoPad — там посмотрим.

Здравствуйте, ins-omnia, Вы писали:

IO>По факту такие вещи могут работать намного лучше теплых ламповых изделий на нативном C.
У них ж под капотом таки С или С++ код, который и делает всю основную работу.