Начиная с версии 5.4, в составе широко распространённого тулкита Qt поставляется QtWebEngine (http://www.opennet.me/opennews/art.shtml?num=38916) — встраиваемый Web-компонент на основе Blink/Chromium. Изначально планировалось, что в будущем QtWebEngine заменит основанный на Webkit компонент QtWebkit, так как его поддержка в Qt, со слов разработчиков Qt, требует (http://marc.info/?l=kde-core-devel&m=142963641106471&w=2) в разы меньших усилий. Однако мейнтейнеры ряда основных дистрибутивов Linux (Debian/Ubuntu и Fedora, как минимум), а также других ОС, пришли к выводу, что использование кодовой базы Chromium приводит к слишком большим проблемам в сопровождении:
- Chromium содержит вшитый FFmpeg вместо использования, например, GStreamer. Как результат, невозможно добавить, удалить или заменить кодеки способом иным, нежели перекомпиляция Chromium.- Chromium жёстко завязан на использование поставляемого в его составе JavaScript-движка V8, что автоматически ставит крест на архитектурах за пределами Intel x86.
- Сборка Chromium с использованием внешних компонентов вместо поставляемых в комплекте с исходными текстами изначально затруднена и требует большой работы со стороны мейнтейнеров, зачастую повторяющейся при каждом обновлении Chromium (а обновления выходят довольно часто).
- Сборка Chromium отнимает довольно много ресурсов; сборка QtWebEngine означает ещё одну сборку Chromium, причём с использованием альтернативного сборочного инструментария (qmake), что означает ещё больше усилий, чем требуется на оригинальный Chromium - и это получается лишь один из компонентов Qt.
- Мультипроцессная архитектура Chromium автоматически наследуется в QtWebEngine, усложняя контроль над работающими приложениями.
В связи с этим возникли такие вопросы как:
- Насколько оправдано применение QtWebkit/QtWebEngine в KDE и других приложениях;- Какие существуют альтернативы (например, QTextView имеет базовые возможности по интерпретации HTML).
Пока что выработать универсальное решение не удаётся. Возможно, привлечение большего числа специалистов поможет найти таковое (список рассылки kde-core-devel модерируется, поэтому угрозы замусоривания обсуждения нет).URL: http://marc.info/?l=kde-core-devel&m=142954900813235&w=2
Новость: http://www.opennet.me/opennews/art.shtml?num=42091
пусть netsurf допиливают :)
Ну не обязательно NetSurf
Можно перефразировать так: нужен высококачественный рендер HTML-а (с поддержкой всех версий) с гибкими возможностями доступа к DOM и стилям.
JS не нужен для самого приложения.
Решение данной задачи позволит создать "новый подход" к построению интерфейсов пользователя. Но этого не будет - потому что разрабатывать решение без гвоздей никто не станет.
>нужен высококачественный рендер HTMLGecko?
> Ну не обязательно NetSurf
> Можно перефразировать так: нужен высококачественный рендер HTML-а (с поддержкой всех версий)
> с гибкими возможностями доступа к DOM и стилям.
> JS не нужен для самого приложения.
> Решение данной задачи позволит создать "новый подход" к построению интерфейсов пользователя.
> Но этого не будет - потому что разрабатывать решение без гвоздей
> никто не станет.Более того, в Qt уже есть и вполне работоспособна поддержка JS через тот же JavaScriptCore. QtWebEngine (пока что), если смотреть исходники Qt 5.4, впилен весьма грубо и практически не интегрирован с остальными подсистемами Qt - в отличие от того, как расползся QtWebKit.
Всё упирается в то, что пилить свой полноценный Web-движок разработчики Qt не в состоянии (и здесь их не за что винить, это действительно большой труд), а чужие разработки, все как одна, представляют собой вещи в себе, требующие подчинения собственным правилам. В Qt хотят иметь интегрированный веб-движок, а всё, что сейчас есть полноценное и актуально развивающееся (Blink, Gecko...), навязывает свои правила. Какая уж тут интеграция.
Если вот так посмотреть, то единственный актуальный браузер, движок которого интегрируется с ОС, а не пытается всё тянуть на себе, это Internet Explorer. :-\
(для озабоченных: это всего лишь мрачная шутка)
Webkit не умирал, единственный момент, возможно в Qt использовалась не 2-я его версия.
> Webkit не умирал, единственный момент, возможно в Qt использовалась не 2-я его
> версия.Его обновление каждый раз тоже дорогого стоит, со слов Qt-шников - и я им, почему-то, верю. А обновлять нужно часто, чтобы не поставлять в составе Qt дырявый софт, как минимум.
Проблема в том, что собирать "абы как, лишь бы собиралось" (то есть вдали от принципа воспроизводимости сборки и прочих досадных, с точки зрения разработчика, мелочей) для Qt проще Chromium (в который, к тому же, охотнее принимают патчи - Apple в этом плане очень консервативна), но это оборачивается головной болью для мейнтейнеров ОС, по уже изложенным причинам. Как ни сделай - кто-то, делающий действительно полезное дело для мира open source, пострадает. У каждого здесь своя логика; взять тот же FFmpeg: разработчикам Chromium нужна его патченая под Chromium версия, разработчикам Qt на это пофиг, лишь бы FFmpeg не становился частью ABI, а мейнтейнерам ОС это дополнительная головная боль - потому что именно они отвечают перед пользователями за лицензионную чистоту, отсутствие уязвимостей и тому подобное; потому что даже если Chromium удаётся заставить использовать системный FFmpeg, это не гарантирует отсутствие сбоев в работе, причём разработчики Chromium после этого могут запросто отказаться помогать, ибо не поддерживаемая сборка; и так далее.
> Chromium жёстко завязан на использование поставляемого в его составе JavaScript-движка V8, что автоматически ставит крест на архитектурах за пределами Intel x86.На arm, mips, powerpc работает, на других архитектурах и с ffmpeg будут проблемы
>На arm, mips, powerpc работает, на других архитектурах и с ffmpeg будут проблемыКакие? На arm вон вполне работает, производительность, правда, не замерял.
>> Chromium жёстко завязан на использование поставляемого в его составе JavaScript-движка V8, что автоматически ставит крест на архитектурах за пределами Intel x86.
> На arm, mips, powerpc работает, на других архитектурах и с ffmpeg будут
> проблемыНасколько знаю, Chromium в обязательном порядке требует JIT. Который в случае V8, если верить обсуждаемой дискусии (бр-р-р), работоспособен только на i386/amd64.
> если верить обсуждаемой дискусии (бр-р-р), работоспособен только на i386/amd64.Вот те раз. А как же у меня хромиум на армовской платке работал?
Значит, у меня (и кого-то в дискуссии... придётся опять в неё лезть) сведения неверные. Спасибо за уточнение. :)
заголовок к содержанию не имеет абсолютно никакого отношение.
> заголовок к содержанию не имеет абсолютно никакого отношение.Почему?
> Сборка Chromium отнимает довольно много ресурсов;Разве у собиральщиков не по >=12 ГБ оперативки с Core i5/Xeon?
> Chromium содержит вшитый FFmpegЕсть же флаг -Duse_system_ffmpeg=0 для использования системного.
В 2012 году сделали, чтобы нормально с ним собиралось: https://code.google.com/p/chromium/issues/detail?id=118986
А в 2014 дебианщик патчи предложил, чтобы опять собиралось: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763632
>> Сборка Chromium отнимает довольно много ресурсов;
> Разве у собиральщиков не по >=12 ГБ оперативки с Core i5/Xeon?
>> Chromium содержит вшитый FFmpeg
> Есть же флаг -Duse_system_ffmpeg=0 для использования системного.
> В 2012 году сделали, чтобы нормально с ним собиралось: https://code.google.com/p/chromium/issues/detail?id=118986
> А в 2014 дебианщик патчи предложил, чтобы опять собиралось: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763632Даже если заставить таки собираться с системной версией (что потребует периодического допиливания кода chromium из-за разницы API FFmpeg разных версий), остаётся проблема мёртвого прикручивания кодеков. То есть нельзя добавить недостающие, обновить устаревшие или убрать неподходящие (например, из-за лицензионных соображений) без перекомпиляции всего Chromium (и, соответственно, QtWebEngine).
> Даже если заставить таки собираться с системной версией (что потребует периодического допиливания кода chromium из-за разницы API FFmpeg разных версий)Не говоря уже о том, что в Debian уже 2 релиза нету ffmpeg, а вместо него libav.
Не правда ваша, в свежерелизнутой 8-ке (Jessie) исправили это недоразумение мантейнера-фанатика от libav, и теперь ffmpeg этот действительно ffmpeg, ну и libav тоже пока выкидывать не стали. А для тех кто был на тестинге это случилось еще год-полтора назад.
> Не правда ваша, в свежерелизнутой 8-ке (Jessie) исправили это недоразумение мантейнера-фанатика
> от libav, и теперь ffmpeg этот действительно ffmpeg, ну и libavвсё абсолютно не так.
> тоже пока выкидывать не стали. А для тех кто был на
> тестинге это случилось еще год-полтора назад.--А что, отец, тестинги в городе есть?
--Кому и unstable - тестинХ.В sid-е - есть, а в jessie b stretch-е https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763148#msg159 *нет*. //На p.d.o сам как-нибудь.
В jessie они убрали "transitional package" ffmpeg, собранный из src:libav.
>> тоже пока выкидывать не стали. А для тех кто был на
>> тестинге это случилось еще год-полтора назад.
> --А что, отец, тестинги в городе есть?
> --Кому и unstable - тестинХ.
> В sid-е - есть, а в jessie b stretch-е https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763148#msg159
> *нет*.Хотя, да. Если "давно", то, возможно, до заморозки и прореживания jessie это было по-другому.
++Что ж Вы, свои тестинги не чистите, что ли?
> //На p.d.o сам как-нибудь.
Пускай выкупят у оперы исходники Presto и включат в Qt (а заодно и исходники откроют)!
Отличная идея, денег подкинешь?
Краудсорсинг
При чем тут деньги? Если продукт хороший, то компания, открывающая его, получает бесплатную разработку и поддержку продукта сторонними разработчиками в обмен на предоставление исходников всему миру.
Учитывая, что Opera забила на Presto и переехала на Chromium, им эта бесплатная разработка и поддержка не нужна.
Тут (https://github.com/OtterBrowser/otter-browser/wiki/QtWebEngi...) Emdek ведёт вики по нехватающим в QtWebEngine вещам
Источник, и связная тема тут: http://forum.ru-board.com/topic.cgi?forum=5&topic=46573&star...
XULRunner же!
Уже было примерно 5 попыток портирования XUL на Qt (Firefox на Qt). Пока неуспешно. Получается, что этот XUL не отличается переносимостью.
ЗулРаннер не нужно, хватило бы движка для рендера страниц - Геко(или что там у Мозиллы свежее)
некоторые цитаты прекраснынекто@kde.org:
IMHO the duty of a distro is providing software to their users to use, if the
rules of the distro make providing software hard/impossible they need to be
updated or these distros need to understand they will lose users to more
flexible distros.это, на минутку, кдешник пугает дебианщика уменьшением userbase. видимо, все кде юзеры (все восемь) ломанутся на кубунту. ну по крайней мере те, кто еще не сбежали с четвертых кед обратно на второй гном или еще куда.
потому что кластерфак, который они устроили с четвертой веткой, судя по всему, только крепчает:
>I know that kdepim seems to depend on it (QtWebEngine) now.над кдешником, предложившим "а чо-чо, если вам так тяжело <s>собирать</s> мейнтейнить наши кедочки, просто TRUST US и берите нашу сборку", откровенно глумятся:
> Just state that there's no such long maintaince time for that package o> r just
> install the newer version of Qt. And yes again that probably goes again> st your
> rules, but it's your rules, so you can just improve them for everyone's>
> benefit :)Let's just try to follow that thru.
A new QtWebEngine pulls in a new Qt. The newer Qt breaks somehow Plasma,
because relying on internals. Then a newer Plasma is pulled in. THat
requires a newer KDE Frameworks, and a newer Wayland and a newer Mesa.
Those two components requires a newer kernel. The newer KDE frameworks
also has a couple of extra requirements. Some of those extra
requirements happens to break parts of the Gnome stack. So a update of
that is needed too. That requires a newer systemd, that discovers issues
with apache. The newest apache has a changed plugin api that requires
changes to all the apache extensions. Including php, ruby and python.You can likely continue the story yourself from here.
Unfortunately, I haven't really used my imagination here.
"чума на оба ваших чума!"(с)
>[оверквотинг удален]
> IMHO the duty of a distro is providing software to their users
> to use, if the
> rules of the distro make providing software hard/impossible they need to be
> updated or these distros need to understand they will lose users to
> more
> flexible distros.
> это, на минутку, кдешник пугает дебианщика уменьшением userbase. видимо, все кде юзеры
> (все восемь) ломанутся на кубунту. ну по крайней мере те, кто
> еще не сбежали с четвертых кед обратно на второй гном или
> еще куда.Что самое смешное, уже известно, что если Debian откажется мейнтейнить (то есть, в том числе, паковать) QtWebEngine, то Ubuntu сделает то же самое. А поскольку у Ubuntu и Kubuntu общая пакетная база... ;)
Хотя нет, самое смешное, это то, для чего QtWebEngine используется в KDE PIM - есть там же, в дискуссии. :)
> Что самое смешное, уже известно, что если Debian откажется мейнтейнить (то есть,
> в том числе, паковать) QtWebEngine, то Ubuntu сделает то же самое.
> А поскольку у Ubuntu и Kubuntu общая пакетная база... ;)my point exactly
> Хотя нет, самое смешное, это то, для чего QtWebEngine используется в KDE
> PIM - есть там же, в дискуссии. :)The only part so far, that depends on QtWebEngine in kdepim is
KSieveUi::SieveEditorWebViewШТОА
а хотя чего я удивляюсь, после мускля-то.
"тут уже не исправишь ничего господь жги"
> The only part so far, that depends on QtWebEngine in kdepim isKSieveUi::SieveEditorWebView
Чистая победа.
Вообще с браузерами беда ... Кривые они все...
> Вообще с браузерами беда ... Кривые они все...В данном случае злобство в том что ЛИБА которая будет рендеря пагу ФОРКАТЬ ПРОЦЕССЫ, городить песочницы и делать over 9000 незапрошенных в общем то действий - это ЖЕСТЬ.
Да включайте в LSB - вместе с Dbus - а не договаривайтесь с каждым комьюнити отдельно. Только пульсу не берите, пожалуйста, в стандарт, описывающий либы, которые обязаны быть в любом линуксе.
> Да включайте в LSB - вместе с Dbus - а не договаривайтесь
> с каждым комьюнити отдельно. Только пульсу не берите,В zewstemdie же. Он уже "в каждой затычке". А LSW не молодёжен. </>
>в составе широко распространённого тулкита Qt поставляется QtWebEngineНу и комбайн... Кто-нибудь уже предлагал переписать Emacs на Qt?
А что, было бы интересно.
> А что, было бы интересно.$ konsole -e emacs -nw_
>>в составе широко распространённого тулкита Qt поставляется QtWebEngine
> Ну и комбайн... Кто-нибудь уже предлагал переписать Emacs на Qt?А почему не Qt на Elisp? А то я чувствую, что мсьё знает толк в извращениях.
Гм. Был KHTML — делали на KHTML. Потом пришёл QtWebKit — форк KHTML, начали переезжать на QtWebKit. Теперь вот QtWebKit собираются заменить на QtWebEngine.Может, им просто откопать обратно KHTML?
> Может, им просто откопать обратно KHTML?1. Им нужен веб-движок - для понтоваться перед пацанами.
2. Ментеёнить или девелопить они его не могут.Вывод: тащут всё, что недевелопят модные ребята с раёна с синдромом раздражённого релиза. Догонялки, навар, бульон. Всё так и было задумано. Теми модными ребятми.
> Гм. Был KHTML — делали на KHTML. Потом пришёл QtWebKit — форк
> KHTML, начали переезжать на QtWebKit. Теперь вот QtWebKit собираются заменить на
> QtWebEngine.
> Может, им просто откопать обратно KHTML?KHTML делали не в Qt. И, судя по проскакивающим заявлениям, от KHTML в KDE планируют отказываться, его банально практически никто не поддерживает.
> KHTML делали не в QtLars Knoll, Simon Hausmann.. ага;) бтв от khtml планируют отказаться уже много лет
Так они, вроде, тогда были лишь KDE-разработчиками, не?
Судя по их linkedin`у lars уже в троллтехе работал, simon да только в kde участвовал
> бтв от khtml планируют отказаться уже много летBTW, когда патчил KDE под OpenBSD :) , я не стал заморачиваться на тему "почему падает KJS" и сразу поставил kwebkitpart по умолчанию - жёсткая run-time зависимость и приоритет выше KHTML. Ни одной жалобы. Так что кое-где _уже_ отказались от KHTML. ;)
Пусть лучше помогут Servo допилить. За одно и его используют)
> Пусть лучше помогут Servo допилить. За одно и его используют)Ви-таки предлагаете им поработать на Вас? Не стесняйтесь, озвучьте бюджет.
Отставьте как есть. Зато в нем и флеш и html5 работают, в отличии от.
Тут выбора всего 2. Либо перепиливать chromium как надо, чтобы к его пересборке не было никаких претензий. Либо посылать QtWebEngine куда подальше.> Мультипроцессная архитектура Chromium автоматически наследуется в QtWebEngine, усложняя контроль над работающими приложениями.
Чот мне не очень охота, чтобы внезапно оказывалось, что софт использующий библиотеку, внезапно форкался, когда он не должен.
А почему бы не выкинуть Webkit и взамен использовать SpiderMonkey|GreaseMonkey от Мозиллы?
> А почему бы не выкинуть Webkit и взамен использовать SpiderMonkey|GreaseMonkey от Мозиллы?Может быть потому, что это не web-движки?
""SpiderMonkey is the code name for the first-ever JavaScript engine, written by Brendan Eich at Netscape Communications
""Greasemonkey — расширение Mozilla Firefox, позволяющее добавить на любую страницу пользовательский JavaSc
Но ведь Вы, Товарищ Язвитель, поняли что речь автора выше о Gecko. Ну так, в чём проблема с ним ?
от вебкита до вебкита
сто километров езды
но дистрибу дебиана
это дело до ... звезды
> но дистрибу дебиана
> это дело до ... звездыМимо тёщина забора я без шутки не хожу,
то s-d туда засуну, то бородатого ветерана покажу.