Комментарии 36
Вы бы фактических примеров использования накидали, с картинками, разбавив вводные
Да, мое упущение. Вот коллекция примеров, адаптированных именно под браузер.
https://github.com/Toorion/qml-browser-demo
Также ссылка на страницу с опубликованными примерами есть на странице в репе.
Очередная хромо-поделка, выдал ошибку dxgi прямо из коробки, за болтовнёй лишённой смысла стоит желание собрать донатов с адептов секты новых технологий.
Какое 3D в вебе? Сейчас не 2005-й год когда даже из вьювера можно было в один клик публиковать интерактивные сцены. Второе нашествие велосипедописателей.
Вообще хром в данном браузере здесь лишь "для обратной совместимости". Жаль, что вы не уловили основной смысл.
Донаты, наверное, это хорошо, но я пока даже об этом не задумывался. Лично в моем плану - сначала сделать инстурмент действительно конкурентноспособный по функционалу, а уже только затем думать о монетизации.
С ошибкой dxgi конечно предстоит еще разбираться. Определенно она зависит от установленных именно у вас графических драйверов. Сейчас под Windows принудительно устанавливается Direct3D. Возможно, это не правильно. Я не специалист в Windows. Разработка велась под Linux и только потом докручивалась к Windows.
Люди ищут легковесный бравзер под вин хп, востребованность такого функционала будет расти с каждым днём. Ещё можно флеш вернуть, ибо не нашёл ни одного рабочего способа публикации в вэбгл и хтмл5.
Поддержка вин хп отсутствует в современных инструментах разработки.
Там работает (не идеально, но старается) только http://kmeleonbrowser.org/
Люди ищут легковесный бравзер под вин хп, востребованность такого функционала будет расти с каждым днём
Стоит учесть, что число людей, у которых такая потребность есть, с каждым днём сокращается. В итоге, потребность у условных полутора человек высоченная, но аудитория слишком мала.
За это "что-то новое" принуждают платить тех кому это совершенно не нужно, ещё и на условиях отказа от ответственности. Что нового сделано айтишниками, 30 лет паразитируют на труде инженеров и клянчат финансирование, субсидии, инвестиции, преференции, льготы, а по факту даже нормальной экранной клавиатуры на ведроид создать не способны.
А еще можно сделать на js и wasm просмотр qml файлов и можно использовать обычный браузер, как запасной вариант...
Да, такое уже есть. Но смысл как раз не в том, чтобы создавть монстра поверх DOM+HTML, а в том, чтобы вообще уйти от всего этого.
Чтобы что-то заменить, надо сначала создать мостик для плавного перехода.
Да, именно по этому пришлось в QmlBrowser встроить также и Chromium, благо для Qt это было не архисложно.
Разработчики не смогут заставить обычных интернет пользователей установить qml браузер. А если не будет qml пользователей, то разработчики не будут делать qml сайты. Да возможны исключения для корпоративных пользователей, но это крохи на фоне интернета. Получается замкнутый круг...
Если вы хотите расширить популярность вашего qml браузера, сначала будет полезно встроить его в стандартные html браузеры. Имея такой браузер внутри стандартного, разработчики смогут создавать qml сайты не опасаясь потерять пользователей. А дальше обычные пользователи qml сайтов поймут, что для скорости работы с qml нужно использовать специализированный qml браузер и начнется постепенное внедрение технологии и плавный переход... Я так это вижу.
Да чистый qml браузер тоже необходим сразу, но для плавного внедрения технологии среди разработчиков, а затем в массы, желательно также создавать qml браузер внутри стандартных браузеров.
Да, про пользователей и разработчиков именно так. И встройка через wasm уже есть, это Canonic - https://docs.page/canonic/canonic
Можете попробовать. Но тот, кто его писал, забросил проект и занялся другим - оптимизацией Chromium.
Я же решил пойти другим путем - создать инструмент для тех задач, которые нельзя сделать хорошо при помощи обычного браузера. Сам его использую для ERP решений и это вполне эффективно. В статье я попытался описать перечень задач, где именно он будет незаменим. Это конечно не вытеснит HTML бразуеры сейчас, но, как говорится "курочка по зернышку клюёт" )
Как вы, простой смертный, посмели ввязаться в войну браузеров, где сражаются лишь мегакорпорации с их многомиллиардными оборотами (прямо или опосредованно)? Да не то что ввязаться - как могли даже помыслить об этом?
Касательно самой идеи... Мне приходилось верстать на XAML и тоже во многом там проще, чем HTML+CSS того времени. Т.е. на XAML после 1 месяца мне было проще и понятнее, чем на HTML+CSS после нескольких лет работы с ним.
Но современный HTML+CSS уже не так уж плох на самом деле. Многие детские проблемы давно решены. То что синтаксис XML-based а не JSON-based - в принципе не критично - да можно сделать простую преобразовался XML->JSON и обратно, кста? Как вам идея?
Возможно ваша идея подошла бы как плагин к существующему браузеру, но не как отдельный браузер.
Как у вас с исполняемым кодом - используется WebAssembly или что-то подобное? На каких языках писать вместо JS?
Фокус QML, который меня до сих пор приводит в восторго: пишешь один раз компонент, а, замет, вставляешь его в любое место "сайта" буквально одной строкой:MyComponent{}
как говоиться "вжух и готово".
В QML встроена таже JsEngine, что и в обычном браузере, возможно чуть более старой версии.
Писать, соответственно, можно на JavaScript. Сейчас я также допиливаю API так, чтобы основные JS фреймворки могли также работать с QML, как и с HTML.
Писать, соответственно, можно на JavaScript.
А кроме JavaScript? Ведь это еще большая проблема, чем HTML+CSS.
Ну вообще это я хотел оставить "на сладкое" ) Да, я не вижу причин, почему современный браузер должен поддерживать только один язык. И конечно планирую добавить и другие. Но это не быстрая история. Например, уже сейчас есть QML модуль с поддержкой Python. Добавляй и работай. Но его пока нельзя включить в дистрибутив, так как с помощью этого модуля можно уже делать все, что угодно в операционной системе. А это не безопасно.
По этому кратко - да, планы добавить другие языки есть. По приоритетности, и когда именно, пока не могу ничего сказать.
Но его пока нельзя включить в дистрибутив, так как с помощью этого модуля можно уже делать все, что угодно в операционной системе.
То есть вы просто ограничили модули, которые можно использовать?
По этому кратко - да, планы добавить другие языки есть.
А зачем усложнять - есть же WebAssembly?
Да, ограничил модели безопасными. В перспективе либо кастомизирую их, либо реализую механизм управления правами пользователем.
Да, есть WebAssembly, более того, есть Qt под WebAssembly. Но это решение очень тяжеловесное и весьма ограниченное. У меня есть решения аля TradingView для собственных нужд. Под WebAssembly оно работает ровно также, как TradingView - медленно и не надежно. Меня, как пользователя это не устроило от слова совсем. Это, кстати, и послужило толчком к реализации QmlBrowser. Это тот инструмент, который я в первую очередь использую сам для своей работы. И могу сказать, что запуск QML из OS совершенно нельзя сравнить с WebAssembly. Думаю, что по перспективам WebAssembly - это как Java Applets или Flash )
Думаю, что по перспективам WebAssembly - это как Java Applets или Flash )
Зря вы так. WebAssembly - это не продукт жизнедеятельности конкретной корпорации - это W3C стандарт. Уже сейчас множество ЯП, тот же C, Rust, C++, C# - можно компилить в WebAssembly - все отлично работает во всех браузерах. Даже тот же QT поддерживает WebAssembly как один из вариантов.
Веротяно вы правы. Возможно имеет смысл делать не QmlBrowser, но WebAssembler браузер! ) Однако, одно другого не исключает. Запуск WebAssembler под DOM/HTML, имеет огромные накладные расходы. Традиционный браузер тяжеловесен и потребляет уйму ресурсов. И тут также необходим язык описания интерфейсов, так как многие языки их просто не имеют. С другой стороны, ничто не мешает интегрировать WebAssembler в QmlBrouser, расширив при этом, возможности исполняемых в нем языков и сделав инструмент гораздо более легким и быстрым, оставив больше ресурсов пользовательским приложениям.
Обязательно обдумаю эту идею, спасибо.
А если выделить "песочницу, изолированную область у пользователя под работу браузера?
Идея интересная. Немного смущает некая «радикальность» в вопросах безопасности.
Кажется, что без ограничений на занимаемое в localStorage место, это самое место очень быстро закончится. Сейчас эти ограничения не позволяют web приложениям пухнуть так же сильно, как нативным. Если их снять - быстро получим кучи сайтов весом десятки мегабайт.
В чём проявляется «невозможность» инъекций? Из сети загружается тот же самый текст, который так же как и html можно подменить или модифицировать.
И как без кук передавать токен в запросах, выполняемых не из кода? Например, картинки на странице тоже могут быть закрыты за авторизацией.
Разумеется за LocalStorage нужно следить. Но как это сделано, например, на Android: Пользователь ставит программу, не ограничивая ее никак в потреблении ресурсов. Но есть "менеджер приложений", в котором можно посмотреть, кто сколько жрет ресурсов. Вот такой "менеджер приложения" я и планирую реализовать в браузере. А также и управления правами приложения, где, например, можно давать доступ к записи на диск - сейчас такой возможности просто нет из за угрозы безопасности.
По исключению "иньекция" - можно загружать страницы и скрипты только с текущего хоста, более того, все доступные файлы должны быть прописаны в qmldir.
Без кук - формируя токен самостоятельно и храня в базе (LocalStorage). Защищенные картинки можно загружать через JS, передавая все то, что необходимо для авторизации. Клас XMLHttpRequest в QML режиме также работает. Хотя, возможно в будущем, я его и заменю чем-то более удобным.
Очередная попытка натянуть сову на глобус. Они столько лет пытаются и свой браузер сделать и UI Kit, что это уже просто смешно. Писал я на qml. Соглашусь, для десктопа вполне приемлемо, но это все поделки и не более. Нормальной поддержки сертификатов нет, сервис воркеры работают с ограничениями и очень медленно. Пресловутый JsEngine это обрезанный функционал нормального браузерного API Если нужно что-то новое придется обновлять кор версию QT. Если ТС использует компоненты, то понятно что под капотом тем плюсовая обвязка, которая ещё и кроссплатформенно зависимая. Далее, нет поддержки сторонних js библиотек. Все ошибки браузера вы должны обрабатывать ручками на тех же плюсах. А так да, вещь хорошая.
Верно говорите, в основе обвязка на C++. Кросплатформенность, при этом, обеспечена фреймворком Qt и на сегодняшний день она достаточно проработана. Методы Браузерного API я реализую уже на C++ своими руками.
Не совсем понял на счет сторонних библиотек JS - их просто нельзя загружать с других доменов, но кто мешает положить к себе и загружать со своего хоста?
Ошибки на старницах, да, перехватываются и выводятся в консоль пользователя. Она пока не такая продвинутая, как у Chromium конечно, но вполне позволяет работать.
В целом конечно, работы еще много и, как я и написал в статье, пока это только начало, пока можно использовать этот инструмент лишь в ограниченных проектах. Ну, по моей собственной практике, в рамках таких проектов это отлично показавший себя инструмент!
Ну так область-то применения этого браузера какая? Когда мы продукт разрабатывали, он нам нужен был чтобы в толстом клиенте веб страницы поднимать - так проще было функционал развивать. Но это только десктоп, для всего остального есть нативный хром. К чему я это говорю, что за ним сомнительное будущее, извините лично мое мнение. Мы уже наелись с ним, не говоря уже о том, что если надо открыть несколько окон, то это отдельные процессы, а не отдельные вкладки...
Область применения, скорее, такая же, как и у толстых клиентов, да. По крайне мере я сам его именно так и применяю. Мне это экономит массу времени и сил, чтобы не делать SPA на React, например.
Пока десктоп, однако технически ничто не мешает портировать это и под мобильники. Qt уже отлично с этим может справиться. Но для меня это цель из будущего.
На счет нескольких окон, то нет, это не обязательно. В QML можно открыть окно прямо из одного инстанса QMLEngine, в рамках одного процесса. В QmlBrowser это реализованно. Ровно как и открытие изолированных по контексту вкладок.
Встречайте QmlBrowser – маленький, но перспективный принц на балу старых пердунов