Тогда весь браузер окажется в песочнице и риск того, что злоумышленник получит доступ к данным из других вкладок сохраняется. Необходимо полностью изолировать каждый ресурс друг от друга.
Веротяно вы правы. Возможно имеет смысл делать не QmlBrowser, но WebAssembler браузер! ) Однако, одно другого не исключает. Запуск WebAssembler под DOM/HTML, имеет огромные накладные расходы. Традиционный браузер тяжеловесен и потребляет уйму ресурсов. И тут также необходим язык описания интерфейсов, так как многие языки их просто не имеют. С другой стороны, ничто не мешает интегрировать WebAssembler в QmlBrouser, расширив при этом, возможности исполняемых в нем языков и сделав инструмент гораздо более легким и быстрым, оставив больше ресурсов пользовательским приложениям. Обязательно обдумаю эту идею, спасибо.
Область применения, скорее, такая же, как и у толстых клиентов, да. По крайне мере я сам его именно так и применяю. Мне это экономит массу времени и сил, чтобы не делать SPA на React, например. Пока десктоп, однако технически ничто не мешает портировать это и под мобильники. Qt уже отлично с этим может справиться. Но для меня это цель из будущего. На счет нескольких окон, то нет, это не обязательно. В QML можно открыть окно прямо из одного инстанса QMLEngine, в рамках одного процесса. В QmlBrowser это реализованно. Ровно как и открытие изолированных по контексту вкладок.
Верно говорите, в основе обвязка на C++. Кросплатформенность, при этом, обеспечена фреймворком Qt и на сегодняшний день она достаточно проработана. Методы Браузерного API я реализую уже на C++ своими руками. Не совсем понял на счет сторонних библиотек JS - их просто нельзя загружать с других доменов, но кто мешает положить к себе и загружать со своего хоста? Ошибки на старницах, да, перехватываются и выводятся в консоль пользователя. Она пока не такая продвинутая, как у Chromium конечно, но вполне позволяет работать. В целом конечно, работы еще много и, как я и написал в статье, пока это только начало, пока можно использовать этот инструмент лишь в ограниченных проектах. Ну, по моей собственной практике, в рамках таких проектов это отлично показавший себя инструмент!
Да, ограничил модели безопасными. В перспективе либо кастомизирую их, либо реализую механизм управления правами пользователем. Да, есть WebAssembly, более того, есть Qt под WebAssembly. Но это решение очень тяжеловесное и весьма ограниченное. У меня есть решения аля TradingView для собственных нужд. Под WebAssembly оно работает ровно также, как TradingView - медленно и не надежно. Меня, как пользователя это не устроило от слова совсем. Это, кстати, и послужило толчком к реализации QmlBrowser. Это тот инструмент, который я в первую очередь использую сам для своей работы. И могу сказать, что запуск QML из OS совершенно нельзя сравнить с WebAssembly. Думаю, что по перспективам WebAssembly - это как Java Applets или Flash )
Ну вообще это я хотел оставить "на сладкое" ) Да, я не вижу причин, почему современный браузер должен поддерживать только один язык. И конечно планирую добавить и другие. Но это не быстрая история. Например, уже сейчас есть QML модуль с поддержкой Python. Добавляй и работай. Но его пока нельзя включить в дистрибутив, так как с помощью этого модуля можно уже делать все, что угодно в операционной системе. А это не безопасно. По этому кратко - да, планы добавить другие языки есть. По приоритетности, и когда именно, пока не могу ничего сказать.
Разумеется за LocalStorage нужно следить. Но как это сделано, например, на Android: Пользователь ставит программу, не ограничивая ее никак в потреблении ресурсов. Но есть "менеджер приложений", в котором можно посмотреть, кто сколько жрет ресурсов. Вот такой "менеджер приложения" я и планирую реализовать в браузере. А также и управления правами приложения, где, например, можно давать доступ к записи на диск - сейчас такой возможности просто нет из за угрозы безопасности.
По исключению "иньекция" - можно загружать страницы и скрипты только с текущего хоста, более того, все доступные файлы должны быть прописаны в qmldir.
Без кук - формируя токен самостоятельно и храня в базе (LocalStorage). Защищенные картинки можно загружать через JS, передавая все то, что необходимо для авторизации. Клас XMLHttpRequest в QML режиме также работает. Хотя, возможно в будущем, я его и заменю чем-то более удобным.
Фокус QML, который меня до сих пор приводит в восторго: пишешь один раз компонент, а, замет, вставляешь его в любое место "сайта" буквально одной строкой: MyComponent{} как говоиться "вжух и готово". В QML встроена таже JsEngine, что и в обычном браузере, возможно чуть более старой версии. Писать, соответственно, можно на JavaScript. Сейчас я также допиливаю API так, чтобы основные JS фреймворки могли также работать с QML, как и с HTML.
Да, про пользователей и разработчиков именно так. И встройка через wasm уже есть, это Canonic - https://docs.page/canonic/canonic Можете попробовать. Но тот, кто его писал, забросил проект и занялся другим - оптимизацией Chromium. Я же решил пойти другим путем - создать инструмент для тех задач, которые нельзя сделать хорошо при помощи обычного браузера. Сам его использую для ERP решений и это вполне эффективно. В статье я попытался описать перечень задач, где именно он будет незаменим. Это конечно не вытеснит HTML бразуеры сейчас, но, как говорится "курочка по зернышку клюёт" )
Вообще хром в данном браузере здесь лишь "для обратной совместимости". Жаль, что вы не уловили основной смысл. Донаты, наверное, это хорошо, но я пока даже об этом не задумывался. Лично в моем плану - сначала сделать инстурмент действительно конкурентноспособный по функционалу, а уже только затем думать о монетизации. С ошибкой dxgi конечно предстоит еще разбираться. Определенно она зависит от установленных именно у вас графических драйверов. Сейчас под Windows принудительно устанавливается Direct3D. Возможно, это не правильно. Я не специалист в Windows. Разработка велась под Linux и только потом докручивалась к Windows.
Да, мое упущение. Вот коллекция примеров, адаптированных именно под браузер. https://github.com/Toorion/qml-browser-demo Также ссылка на страницу с опубликованными примерами есть на странице в репе.
Про «Возможность удаления любых предустановленных программ» не совсем верно.
«за исключением сервисных, обеспечивающих функционирование оборудования».
При этом к «сервисным» относится Браузер Яндекса, Антивирус Касперского, карты от Яндекса (навигационные) и еще пачка того, что скорее всего вы не захотите видеть на своих смартфонах.
Все очень просто (даже не вдаваясь в приведенные вами примеры, хотя и они весьма спорны). Если есть решение, которое можно воспроизвести легко, без затрат (в нашем случае на разработку), то в скором времени его воспроизведут все. Значит, чтобы быть конкурентными потребуются новые решения. Если это не технологический продукт (кустомизация), то рано или поздно ее объемы потребуют автоматизации ))
UI, действительно хороший пример — один дизайнер делает кастомизацию, десятки — сотни сайтов ее повторяют. Когда одно и тоже на сотнях сайтах — новому сайту нужно чемто отличаться — а возможностей «готовых модулей» уже не хватает.
Что касается «флеш-сайтов», типа озвученного вами wix.com, то таких «конструкторов сайтов» было уже вагон и маленькая тележка.
Как показывает практика — ни одна серьезная компания такими не пользуется. Почему? Недостаточные возможности кастомизации.
Когда создается сайт серьезной компании — вначале создается идея и концепт. Если инструмент (конструктор) не позволяет выполнить хотябы 2% от идеи, он отбрасывается. Компании, которые выбирают «конструктор» идейно — очень быстро отбрасываются с рынка сами — естественный отбор.
Как я уже писал чуть ниже — megamozg.ru/post/22650/#comment_684062
Не может быть никакого тренда «на избавление». Конкурентные условия бизнеса не позволяют компаниям сидеть на попе ровно на базе «типовых» решений. Какждой компании, чтобы выделиться на рынке нужно «индивидуальное» решение. А для «индивидуального» решения нужен квалифицированный разработчик.
Есть ньюанс, который касается специфики профессии программиста, которая, в свою очередь, с трудом укладывается в головах «не разработчиков». Программист после института — это ноль с бамажкой. Он чемуто обучен, но к практической работе это никакого отношения не имеет. И первое, что он должен уметь сделать — это освоить, практически с нуля, свою первую специальность — куда все же возьмут (например, биллинг). Если он с этим справился — он молодец. Но это не значит, что он может жить этим всю оставшуюся жизнь. Технологии меняются каждый год и ему приходится осваивать все новые и новые области, языки. Хороший разработчик — это тот, кто умеет делать это быстро, плохой — тот, кто делает медленно.
Отсюда два вывода — совсем не важно, чем занимаются учебные организации (тем более, что сейчас они в ужасающем состоянии и кроме бумажки ничего не дают). Все упирается в то, какой % населения способен и хочет думать как программист! А он мал, весьма мал. И из за равномерного распределения психотипов — он никогда не увеличится!
Выражу свое несогласие с автором относительно перспектив. Конечно сегодняшний дефицит кадров вынуждает бизнес двигаться в область «Облаков», как он когдато вынуждал его двигаться от «нативного когда» к CMS, например. Но, особенность бизнеса заключается в том, что однотипные дешевые решения быстро заполняют рынок и лишают бизнес конкурентных приемуществ. И вот в погоне за этими «кинкурентными приемуществами» и требуются программисты. И не важно что это — «нативный код», CMS или «Облачные решения» — чтобы выделится из общей массы бизенсу нужно генерировать все более и более сложные решения — а для этого уже «Шаблонных решений» не достаточно, надо делать что-то свое. А свое — это уже более сложная логика — а сложная логика — это уже код и навыки разработки. А людей, пусть даже обученных, которые умеют писать код, умеют мыслить как разработчик — ограниченный %. По этому дефицит кадров будет лишь увеличиваться и увеличиваться и стоимость только рости еще долгое время!
А вы, очевидно, представляете здесь в конец оборзвешего КИВИ? Вчера, буквально, пришлось воспользоваться их банкоматом чтобы положить денег на МТС. Как увидел комиссию в 10% — сразу захотелось взять деньги назад. Но ведь их банкомат денег не отдает! — Чисто развод на бабки.
Так что лично я за, чтобы у этого поганого киви появился бы наконец хоть один серьезный конкурент!
И уж не знаю, как у РУРУ с Альфой, но пополнение мобильника (МТС) и интернет (qwerty) проходит на ура, и на фоне тогоже урода киви комиссия менее 5% на МТС — просто подарок!
Тогда весь браузер окажется в песочнице и риск того, что злоумышленник получит доступ к данным из других вкладок сохраняется. Необходимо полностью изолировать каждый ресурс друг от друга.
Веротяно вы правы. Возможно имеет смысл делать не QmlBrowser, но WebAssembler браузер! ) Однако, одно другого не исключает. Запуск WebAssembler под DOM/HTML, имеет огромные накладные расходы. Традиционный браузер тяжеловесен и потребляет уйму ресурсов. И тут также необходим язык описания интерфейсов, так как многие языки их просто не имеют. С другой стороны, ничто не мешает интегрировать WebAssembler в QmlBrouser, расширив при этом, возможности исполняемых в нем языков и сделав инструмент гораздо более легким и быстрым, оставив больше ресурсов пользовательским приложениям.
Обязательно обдумаю эту идею, спасибо.
Область применения, скорее, такая же, как и у толстых клиентов, да. По крайне мере я сам его именно так и применяю. Мне это экономит массу времени и сил, чтобы не делать SPA на React, например.
Пока десктоп, однако технически ничто не мешает портировать это и под мобильники. Qt уже отлично с этим может справиться. Но для меня это цель из будущего.
На счет нескольких окон, то нет, это не обязательно. В QML можно открыть окно прямо из одного инстанса QMLEngine, в рамках одного процесса. В QmlBrowser это реализованно. Ровно как и открытие изолированных по контексту вкладок.
Верно говорите, в основе обвязка на C++. Кросплатформенность, при этом, обеспечена фреймворком Qt и на сегодняшний день она достаточно проработана. Методы Браузерного API я реализую уже на C++ своими руками.
Не совсем понял на счет сторонних библиотек JS - их просто нельзя загружать с других доменов, но кто мешает положить к себе и загружать со своего хоста?
Ошибки на старницах, да, перехватываются и выводятся в консоль пользователя. Она пока не такая продвинутая, как у Chromium конечно, но вполне позволяет работать.
В целом конечно, работы еще много и, как я и написал в статье, пока это только начало, пока можно использовать этот инструмент лишь в ограниченных проектах. Ну, по моей собственной практике, в рамках таких проектов это отлично показавший себя инструмент!
Да, ограничил модели безопасными. В перспективе либо кастомизирую их, либо реализую механизм управления правами пользователем.
Да, есть WebAssembly, более того, есть Qt под WebAssembly. Но это решение очень тяжеловесное и весьма ограниченное. У меня есть решения аля TradingView для собственных нужд. Под WebAssembly оно работает ровно также, как TradingView - медленно и не надежно. Меня, как пользователя это не устроило от слова совсем. Это, кстати, и послужило толчком к реализации QmlBrowser. Это тот инструмент, который я в первую очередь использую сам для своей работы. И могу сказать, что запуск QML из OS совершенно нельзя сравнить с WebAssembly. Думаю, что по перспективам WebAssembly - это как Java Applets или Flash )
Ну вообще это я хотел оставить "на сладкое" ) Да, я не вижу причин, почему современный браузер должен поддерживать только один язык. И конечно планирую добавить и другие. Но это не быстрая история. Например, уже сейчас есть QML модуль с поддержкой Python. Добавляй и работай. Но его пока нельзя включить в дистрибутив, так как с помощью этого модуля можно уже делать все, что угодно в операционной системе. А это не безопасно.
По этому кратко - да, планы добавить другие языки есть. По приоритетности, и когда именно, пока не могу ничего сказать.
Разумеется за LocalStorage нужно следить. Но как это сделано, например, на Android: Пользователь ставит программу, не ограничивая ее никак в потреблении ресурсов. Но есть "менеджер приложений", в котором можно посмотреть, кто сколько жрет ресурсов. Вот такой "менеджер приложения" я и планирую реализовать в браузере. А также и управления правами приложения, где, например, можно давать доступ к записи на диск - сейчас такой возможности просто нет из за угрозы безопасности.
По исключению "иньекция" - можно загружать страницы и скрипты только с текущего хоста, более того, все доступные файлы должны быть прописаны в qmldir.
Без кук - формируя токен самостоятельно и храня в базе (LocalStorage). Защищенные картинки можно загружать через JS, передавая все то, что необходимо для авторизации. Клас XMLHttpRequest в QML режиме также работает. Хотя, возможно в будущем, я его и заменю чем-то более удобным.
Фокус QML, который меня до сих пор приводит в восторго: пишешь один раз компонент, а, замет, вставляешь его в любое место "сайта" буквально одной строкой:
MyComponent{}как говоиться "вжух и готово".
В QML встроена таже JsEngine, что и в обычном браузере, возможно чуть более старой версии.
Писать, соответственно, можно на JavaScript. Сейчас я также допиливаю API так, чтобы основные JS фреймворки могли также работать с QML, как и с HTML.
Да, про пользователей и разработчиков именно так. И встройка через wasm уже есть, это Canonic - https://docs.page/canonic/canonic
Можете попробовать. Но тот, кто его писал, забросил проект и занялся другим - оптимизацией Chromium.
Я же решил пойти другим путем - создать инструмент для тех задач, которые нельзя сделать хорошо при помощи обычного браузера. Сам его использую для ERP решений и это вполне эффективно. В статье я попытался описать перечень задач, где именно он будет незаменим. Это конечно не вытеснит HTML бразуеры сейчас, но, как говорится "курочка по зернышку клюёт" )
Да, именно по этому пришлось в QmlBrowser встроить также и Chromium, благо для Qt это было не архисложно.
Да, такое уже есть. Но смысл как раз не в том, чтобы создавть монстра поверх DOM+HTML, а в том, чтобы вообще уйти от всего этого.
Вообще хром в данном браузере здесь лишь "для обратной совместимости". Жаль, что вы не уловили основной смысл.
Донаты, наверное, это хорошо, но я пока даже об этом не задумывался. Лично в моем плану - сначала сделать инстурмент действительно конкурентноспособный по функционалу, а уже только затем думать о монетизации.
С ошибкой dxgi конечно предстоит еще разбираться. Определенно она зависит от установленных именно у вас графических драйверов. Сейчас под Windows принудительно устанавливается Direct3D. Возможно, это не правильно. Я не специалист в Windows. Разработка велась под Linux и только потом докручивалась к Windows.
Да, мое упущение. Вот коллекция примеров, адаптированных именно под браузер.
https://github.com/Toorion/qml-browser-demo
Также ссылка на страницу с опубликованными примерами есть на странице в репе.
«за исключением сервисных, обеспечивающих функционирование оборудования».
При этом к «сервисным» относится Браузер Яндекса, Антивирус Касперского, карты от Яндекса (навигационные) и еще пачка того, что скорее всего вы не захотите видеть на своих смартфонах.
UI, действительно хороший пример — один дизайнер делает кастомизацию, десятки — сотни сайтов ее повторяют. Когда одно и тоже на сотнях сайтах — новому сайту нужно чемто отличаться — а возможностей «готовых модулей» уже не хватает.
Что касается «флеш-сайтов», типа озвученного вами wix.com, то таких «конструкторов сайтов» было уже вагон и маленькая тележка.
Как показывает практика — ни одна серьезная компания такими не пользуется. Почему? Недостаточные возможности кастомизации.
Когда создается сайт серьезной компании — вначале создается идея и концепт. Если инструмент (конструктор) не позволяет выполнить хотябы 2% от идеи, он отбрасывается. Компании, которые выбирают «конструктор» идейно — очень быстро отбрасываются с рынка сами — естественный отбор.
Не может быть никакого тренда «на избавление». Конкурентные условия бизнеса не позволяют компаниям сидеть на попе ровно на базе «типовых» решений. Какждой компании, чтобы выделиться на рынке нужно «индивидуальное» решение. А для «индивидуального» решения нужен квалифицированный разработчик.
Отсюда два вывода — совсем не важно, чем занимаются учебные организации (тем более, что сейчас они в ужасающем состоянии и кроме бумажки ничего не дают). Все упирается в то, какой % населения способен и хочет думать как программист! А он мал, весьма мал. И из за равномерного распределения психотипов — он никогда не увеличится!
Так что лично я за, чтобы у этого поганого киви появился бы наконец хоть один серьезный конкурент!
И уж не знаю, как у РУРУ с Альфой, но пополнение мобильника (МТС) и интернет (qwerty) проходит на ура, и на фоне тогоже урода киви комиссия менее 5% на МТС — просто подарок!