S> Нужно сравнить по памяти. Там есть срвнение с электроном
Скорее всего практически одинаково будет, обе же тонкие обертки с тупо созданием окна
и использованием доступного в данной системе веб движка, такая обертка памяти съест
близко к нулю.
Здравствуйте, wantus, Вы писали:
W>Кто-нибудь смотрел на вариант использования браузера для отрисовки UI полностью локального приложения?
W>В смысле, что UI доступен как web page через http://localhost:12345 и при этом обычного (GDI) UI нет в принципе.
W>На первый взгляд для приложений, которым UI нужен чисто для конфигурации и отображения статуса (а не для работы как, например, в CAD) — много плюсов.
W>Писать продвинутый гуй на html/css/js приятнее и быстрее, чем нативный.
W>Сильно упрощает портирование.
W>Бесплатно получается опция remote UI.
W>Народ в принципе уже привык к web apps, так что это не должно выглядеть странно.
W>У кого есть чего-то подобное?
если использовать обычный браузер то такие минусы:
— занимает весь экран
— хром чует подвох раз адрес без ssl, и скажет юзеру про небезопасность
— юзеры могут захотеть видеть два документа (например открыть карточки двух пациентов и сравнивать). в браузере
это либо табами либо же самому писать на js свою имитацию мульти-док интерфейса. короче гемор
гораздо проще сделать свой браузер (на основе WebView ) где этих проблем нет.
да ещё и подать можно как нечто специфичное (DentalBrowser например для стоматологов)...
Здравствуйте, c-smile, Вы писали:
CS>Вот эти приложения https://sciter.com/#customers используют Web UI фактически (HTML/CSS/scripts). CS>Просто вместо browser означенный sciter.
Здравствуйте, wantus, Вы писали:
W>Писать продвинутый гуй на html/css/js приятнее и быстрее, чем нативный.
Вот тут я бы поспорил.
Если бы это было приятнее и быстрее, то не выходил бы каждые полгода очередной js-framework с новыми возможностями, ибо разобраться в старых толком никто не может.
Здравствуйте, wantus, Вы писали:
W>В смысле, что UI доступен как web page через http://localhost:12345 и при этом обычного (GDI) UI нет в принципе. W>У кого есть чего-то подобное?
Бонусом получаешь ярлык для запуска, в том числе на мобилках.
Запуск с localhost по доступу к компьютеру пользователя преимуществ никаких не дает. Ты не можешь читать или писать файлы, не имеешь доступа к устройствам пользователя, типа принтера или сканера или чего там еще.
Да еще и встает вопрос как это пользователю устанавливать и обновлять.
В общем, не понятно, чем вебсайт на localhost лучше, чем просто вебсайт?!
Здравствуйте, wantus, Вы писали:
W>Здравствуйте, c-smile, Вы писали:
CS>>Вот эти приложения https://sciter.com/#customers используют Web UI фактически (HTML/CSS/scripts). CS>>Просто вместо browser означенный sciter.
W>Не, это не то.
Здравствуйте, c-smile, Вы писали:
CS>Посмотри Sciter Quark: https://quark.sciter.com/
CS>С ним ты можешь собрать приложение которое будет а) работать без броузера вообще и b) общаться с твоим localhost сервером по http.
Мне не интересно КАК это сделать (что в принципе достаточно тривиально и без всяких сторонних икебан).
Мне интересно где это используется в живых продуктах и чего про это думают юзеры.
Здравствуйте, wantus, Вы писали:
W>А писать в файлы будет headless native process, с котором UI как-то там общается — через REST, через Websockets, etc.
Вот видел я просто похожую конструкцию. Аццкий ад в плане администрация.
Если в пределах компании такое ещё как-то можно управиться, совершенно не представляю как это будут делать домашние пользователи.
Здравствуйте, wantus, Вы писали:
W>Мне интересно где это используется в живых продуктах и чего про это думают юзеры.
В "продуктах" не видел. И сомневаюсь что продукты такие есть, по многим причинам. Например у многих юзеров browser это новогдняя ёлка — табы, тулбары и еще туча всякой хрени. Где-то там в глубине твое приложение разгдядеть сложно будет. Да и привычка — если браузер, то это сайт какой — трудно объяснить домохозйяке почему посланная ссылка на localhost на мобильнике не открывается.
Здравствуйте, wantus, Вы писали:
W>У кого есть чего-то подобное?
У меня есть програмка, которая в принципе предполагается быть опенсорсной, но никак не доходят руки ее опубликовать. Програмка представляет собой HTTP-proxy, с выходом на заданные конфигурацией сайты через SSH-тунель, а на остальные — напрямую.
У нее есть незамысловатый пользовательский интерфейс, он реализован в виде нескольких страничек в веб-бровсере. Инсталляция програмки заключается в том, что она прописывает себя в autostart вместе с системным дектопом, и добавляет на дектопе иконку, которая, собственно, открывает ее (програмку) в веб-бровсере.
Все замечательно работает, в венде и линухе, собирается под обе системы практически из одних исходников. Сама програмка написана на Go, веб-страничка — на HTML и JS.
Здравствуйте, Michael, Вы писали:
M>- хром чует подвох раз адрес без ssl, и скажет юзеру про небезопасность
На localhost не говорит.
M>гораздо проще сделать свой браузер (на основе WebView ) где этих проблем нет. M>да ещё и подать можно как нечто специфичное (DentalBrowser например для стоматологов)...
Дистрибутив будет очень большой. Бровсеры, они толстенькие.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, wantus, Вы писали:
W>>Здравствуйте, c-smile, Вы писали:
CS>>>Вот эти приложения https://sciter.com/#customers используют Web UI фактически (HTML/CSS/scripts). CS>>>Просто вместо browser означенный sciter.
W>>Не, это не то.
CS>Посмотри Sciter Quark: https://quark.sciter.com/
CS>С ним ты можешь собрать приложение которое будет а) работать без броузера вообще и b) общаться с твоим localhost сервером по http.
Это же для UI-first приложении́(вся база фигачится в скрипте а все остальное дёргается из DLL), а для топикстартера UI как я понимаю второстепенная штука.
Здравствуйте, wantus, Вы писали:
w> Мне интересно где это используется в живых продуктах и чего про это думают юзеры.
Есть несколько браузерных remote UI для разных торрент-клиентов. Есть для трансмиссии, есть для мюторрента, есть для арии2. Я пользовался каждым из них (например, локальная консольная ария2 + веб-гуй для удобства). В принципе, за неимением лучшего варианта, пользоваться можно, но это не лучшее решение, как по мне. Например, для мюторрента работающего на отдельном компе я использовал десктопный ремоут гуй, вместо браузерного.
На мой взгляд такой вариант удобен для очень специфического софта, типа, сервисов, прокси-серверов и подобного (которые просто работают в фоне и не отсвечивают), где один раз в неделю/месяц что то настроил и все.
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, wantus, Вы писали:
w>> Мне интересно где это используется в живых продуктах и чего про это думают юзеры.
R>Есть несколько браузерных remote UI для разных торрент-клиентов. Есть для трансмиссии, есть для мюторрента, есть для арии2. Я пользовался каждым из них (например, локальная консольная ария2 + веб-гуй для удобства). В принципе, за неимением лучшего варианта, пользоваться можно, но это не лучшее решение, как по мне. Например, для мюторрента работающего на отдельном компе я использовал десктопный ремоут гуй, вместо браузерного.
R>На мой взгляд такой вариант удобен для очень специфического софта, типа, сервисов, прокси-серверов и подобного (которые просто работают в фоне и не отсвечивают), где один раз в неделю/месяц что то настроил и все.
Ну вот кстати вспомнил, я себе плейер на распберри пи сделал, так там весь интерфейс в браузере, использую постоянно с разных устройств (телефон, планшет, десктоп — то до чего ближе дотянутся в данный момент) и, как не странно, очень удобно.
Правда я везде ставлю, чтобы в отдельном окне открывался, а не во вкладке.
Но это опять же отдельное устройство, а не локалхост.
Здравствуйте, wantus, Вы писали:
W>Кто-нибудь смотрел на вариант использования браузера для отрисовки UI полностью локального приложения?
W>В смысле, что UI доступен как web page через http://localhost:12345 и при этом обычного (GDI) UI нет в принципе.
W>На первый взгляд для приложений, которым UI нужен чисто для конфигурации и отображения статуса (а не для работы как, например, в CAD) — много плюсов.
W>Писать продвинутый гуй на html/css/js приятнее и быстрее, чем нативный.
W>Сильно упрощает портирование.
W>Бесплатно получается опция remote UI.
W>Народ в принципе уже привык к web apps, так что это не должно выглядеть странно.
W>У кого есть чего-то подобное?
Resilio Sync. При установке как сервис подымает локалхост и тогда GUI через браузер. Очень удобно при установке на NAS.
Здравствуйте, C0x, Вы писали:
CS>>С ним ты можешь собрать приложение которое будет а) работать без броузера вообще и b) общаться с твоим localhost сервером по http.
C0x>Это же для UI-first приложении́(вся база фигачится в скрипте а все остальное дёргается из DLL), а для топикстартера UI как я понимаю второстепенная штука.
Ты не понял.
Есть html/css+script для той страницы что товарищ собирается показывать в browser. Эта страница общается на localhost c чем-то (AJAX я так пнимаю).
Ну так вот берем этот html/css+script и добавляем там Sciter.launch("server.exe")
Заворачиваем это всё в Quark и получается два exe — один UI (quark), а второй та самая console приблуда server.exe.
Запускаем UI exe, он стартует также server.exe — и все
Также можно общаться с тем "server.exe" через его stdin/stdout вместо сокетов что еще более надежнее.
Здравствуйте, wantus, Вы писали:
W>Кто-нибудь смотрел на вариант использования браузера для отрисовки UI полностью локального приложения?
W>В смысле, что UI доступен как web page через http://localhost:12345 и при этом обычного (GDI) UI нет в принципе.
W>На первый взгляд для приложений, которым UI нужен чисто для конфигурации и отображения статуса (а не для работы как, например, в CAD) — много плюсов.
W>Писать продвинутый гуй на html/css/js приятнее и быстрее, чем нативный.
W>Сильно упрощает портирование.
W>Бесплатно получается опция remote UI.
W>Народ в принципе уже привык к web apps, так что это не должно выглядеть странно.
W>У кого есть чего-то подобное?
Есть именно такое о чем ты говоришь — http://stunnix.com/prod/aws/ — Stunnix Advanced Web Server. Это инструмент для создания и упаковки таких приложений в нечто, что выглядит как десктопное, на винде, макоси и линуксе. Можешь качнуть демо — оно показывает wordpress, joomla, phpbb2 работающие как нативные десктопные приложения, запущенные локально.
При запуске такого приложения выбирается свободный порт TCP для веб сервера, и для mysql (если требуется), на этих портах запускаются веб-сервер и mysql, потом пускается системный или специальный браузер. Когда нужно завершить приложение (или юзер закрывает последнее окно специального браузера) — веб-сервер и mysqld останавливаются.
Все это портабельное, то есть работает из любой папки, даже сетевой, без инсталляции.
Серверная часть обфускаторов написана на перле (но можно писать и на php и на питоне, да хоть на C).
На винде общаются между собой не через TCP а через named pipes. Потому что многие корпоративные файрволы БЛОКИРУЮТ прослушку на localhost (из-за чего сервер не может стартануть), а браузеру (не являющемуся системным) — коннектится на localhost. Просто потому, что разные идиоты пишут файрволы..
На макоси и линуксе пускается системный браузер. Для макоси и винды у них есть специальный файрфокс, в котором можно заменить иконку, название процесса, название в заголовке окна, убрать все меню — будет только веб-страница видна.
Их обфускаторы для винды тащат с собой модифицированный файрфокс (модифицирован чтобы http over named pipes мочь).
Серверная часть — модифицированный апач (модифицирован чтобы http over named pipes мочь).
Конечно режим использования http over named pipes в винде можно отключить в конфиге, тогда будет работать и с системным браузером на винде.
Самая сложность при таком подходе — защита от копирования. Ведь кто угодно может выложить это на своем сервере и давать доступ к нему удаленно с почасовой тарификацией.
