Разработчики фреймворка Qt сообщили (http://blog.qt.io/blog/2015/09/25/qt-for-native-client-and-e.../) о приведении к рабочему виду продукта Qt for Native Сlient (http://code.qt.io/cgit/qt/qtbase.git/tree/?h=wip/nacl), позволяющего организовать выполнение Qt-приложений (Qt Widgets и Qt Quick) в специальном изолированном окружении web-браузера Google Chrome с производительностью близкой к обычной скомпилированной версии программы. Организовать выполнение Qt-приложения других современных web-браузерах, не поддерживающих Native Client, можно скомпилировав программу в JavaScript-представление при помощи компилятора Emscripten (https://www.opennet.me/opennews/art.shtml?num=31155).URL: http://blog.qt.io/blog/2015/09/25/qt-for-native-client-and-e.../
Новость: http://www.opennet.me/opennews/art.shtml?num=43039
О, прикольно, натрий-хлор :-)(NaCl)
Хоть не HOH, а то б я сдох.
А H2O - это вебсервер такой.
Простите за оффтопик, но я тащусь от воды офигенный веб-сервак. Использую для статики.
Почему не пасажира или тонкого единорога?
А ещё производитель биосов (InsydeH2O)
А что, только заметил? В Native Client используется Pepper API. Salt (NaCl) and pepper.
Да придут же вирусы на линукс.
И да будут исполняться в изолированных окружениях ;)
О боже, как же я боялся этого. Теперь станет модно писать сайты на Qt и весить они будут по 50Мб каждый. И естественно все для надёжности будут грузить свою уникальную версию Qt. Мало ли какую "фичу" пофиксят в минорной версии, не переделывать же сайт из за этого.
> Теперь станет модно писать сайты на Qt и весить они будут по 50Мб каждый.И ходить на них будет 50 школьных друзей автора.
Обычно у таких авторов друзей гораздо меньше.
О боже, кути через эмскриптен давным-давно уже пашут, от этого ничего не изменится. Кути для NaCl (не)нужны для разработки приложений для хрома, которые ставятся через магазин. По умолчанию NaCl на обычных сайтах спрятан за флагом и сайты (и даже игры) на нём писаться не будут и не могут.
Вот мало тяжёлых окружений со свистелками и перделками. Давайте мы ещё веб-браухер вкрутим как прослойку между тобой и приложением. Зачем? Да чтоб жизнь мёдом не казалась!
Браузер — это средство быстрого доступа к приложению (которое не нужно инсталировать локально, на что у вас может просто не быть прав).
С одной стороны. С другой — это песочница, jail.
С третьей — это переизобретение X Window System с её протоколом.
Затем, что "легкий" веб занимает уже на порядок больше ресурсов, чем "тяжелые" клиенты.
Мда, тут школьник за несколько месяцев на RUST-е клон контр-страйка почти создал:
https://www.youtube.com/watch?v=_Qhg-uWQaHMБлагодаря llvm, всё что на нём работает можно через Emscripten в js перегнать, в том числе и код на RUST.
Вот весь код бэкенд-код и для фронтэнда написан целиком на Rust и кросскомпирирован через Emscripten в JS для браузера."Implementation of TodoMVC in Rust in the browser"
https://github.com/tcr/rust-todomvc
Ну всё, ждём кеды в хромоси на хромбуках
Мне кажется это будет использоваться для тонких клиентов уже созданных приложений для бизнеса, а не свистелок и перделках на обычных сайтах.
Тоже подумал об этом, потомучто лепить интерфейсы приложений на html/css это то еще удовольствие, а уж как оно потом "быстро" работает особенно с таблицами это просто сказка. Так что для всяких корпоративных порталов и интерфейсов для клиентуры самое то.
Как правило подобные (уже созданные приложения для бизнеса) хотят доступ к корпоративным ресурсам, субд, внутренней сети (диски, принтеры,…) ну и тд, и тп.Очевидно в данном случае приложение (с Qt оно или без) будет просто выплюнуто в броузер пользователя (через общедоступную сеть, интернет) и всё. И там у клиента будет работать вполне себе автономно.
В общем всё это как-то… натянуто.
Хромовые приложения во всё это могут через специальные апи (и костыли). Не знаю, как там с NaCl, но думаю, что подобная фигня с разрешениями там тоже есть.
Да придумать то можно всё что угодно. Хоть либссн и свой впн поверх хттп итд.
Но это так эти бизнес-приложения нужно перелопатить, что по себестоимости проще новое написать. По новой архитектуре и с новой логикой выполнения, которая будет правильной с точки зрения этой логики.
я думаю не только:
например сейчас разрабатывая от средне до больших приложений на JavaScript, большие команды стараются внедрять что-то проверяющее ошибки на этапе компиляции - это TypeScript (MS) или Flow (Facebook), которые вводят новые лексические и языковые понятия в JavaScript.А теперь можно доверяя компилятору единой платформы бэкэнд + фронтенд (писал тут в коментариях уже про RUST), написать, проверенное статически, приложение на одном языке без таких дополнительных средств, которое скомилируется в JS, с asm оптимизациями.
Но ведь насколько я понял, новость именно про компиляцию кутей в _нативный_ код, который будет исполняться в песочнице хрома, а эмскриптен предлагают только в качестве фолбека. В любом случае, кути на эмскриптене будет тормозить аццки, не важно, обычная версия кутей или эта (хотя эта версия, возможно, будет работать на 0,435% быстрей, чем существующие демки).
эта новость, да про натив Кути, но я слабо представляю необходимость Кути-виджетов в песочнице браузера, когда можно просто скомпилить их для работы без браузера вообще.А по поводу Emscripten, я написал то что сами сейчас сталкиваемся, смотрим в сторону TypeScript/Flow, для браузерного клиента, при том что все не в восторге от JS, его нюансов...
Вот демки: http://vps2.etotheipiplusone.com:30176/redmine/projects/emsc...На моём chromium 45, запущенном с флагом --enable-nacl, демки работают через этот emscripten. И загружают по несколько метров кода для простого текстового редактора. Тормозит адски. Задержка на выделение текста, например, чуть ли не секунда. И это на core i5.
Вот, как уже писал выше, пример сорцев на RUST скомпиленных в JS, тут ничего не тормозит и работает всё если не быстрее прямо написанного на js, то точно не медленнее, так же проверял на core-i5сорц:
https://github.com/tcr/rust-todomvc/blob/master/src/main.rs
само демо:
http://tcr.github.io/rust-todomvc/
Нужно! Для определенных ситуаций.
Ребят, а есть РАБОЧИЙ ман по сборке этого всего? Тот, что по ссылке, не работает нихера. Не работал nacl-configure (просто молча завершался configure), убрал -skip xmlpatterns - вроде ок стало. Делал по README.md, который в ветке wip/nacl, да и в этом мане есть слова об этом, например,
make module-qtbase
make module-qtdeclarative
make module-qtquickcontrols
вообще не работает, нет таких целей, пришлось просто make делать. В итоге всё собралось в статике, устанавливается (make install) в ту же директорию, где и изначально лежит, т.е. никуда, все либы статичны, при сборке приложений через nacl-sdk'овский компилятор либы Qt ругаются на undefined reference всего чего только можно. Кто-нибудь собрал это успешно?
Правильно ли я понимаю, что qooxdoo теперь может покоиться с миром?Где посмотреть демки этого Qt for Native Сlient? Хотелось бы увидеть что-нибудь типа http://demo.qooxdoo.org/current/showcase/#Form
Упс. Увидел ссылку от Q2W в комментариях.С такой скоростью загрузки и лагами во время работы эта штука пока не пригодна. Но что-то в этом есть. :) Проверял на последнем огнелисе 41.0 под бубунтой.