форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
Сообщение от opennews (ok) on 23-Апр-15, 09:18
Начиная с версии 5.4, в составе широко распространённого тулкита Qt поставляется QtWebEngine (http://www.opennet.dev/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.dev/opennews/art.shtml?num=42091
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+6 +/–
Сообщение от annualslayer (ok) on 23-Апр-15, 09:18
пусть netsurf допиливают :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+2 +/–
	Сообщение от Аноним (??) on 23-Апр-15, 09:29
	Ну не обязательно NetSurf Можно перефразировать так: нужен высококачественный рендер HTML-а (с поддержкой всех версий) с гибкими возможностями доступа к DOM и стилям. JS не нужен для самого приложения. Решение данной задачи позволит создать "новый подход" к построению интерфейсов пользователя. Но этого не будет - потому что разрабатывать решение без гвоздей никто не станет.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	24. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+12 +/–
	Сообщение от kravich (ok) on 23-Апр-15, 11:59
	>нужен высококачественный рендер HTML Gecko?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	25. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+7 +/–
	Сообщение от Аноним (??) on 23-Апр-15, 12:04
	> Ну не обязательно NetSurf > Можно перефразировать так: нужен высококачественный рендер HTML-а (с поддержкой всех версий) > с гибкими возможностями доступа к DOM и стилям. > JS не нужен для самого приложения. > Решение данной задачи позволит создать "новый подход" к построению интерфейсов пользователя. > Но этого не будет - потому что разрабатывать решение без гвоздей > никто не станет. Более того, в Qt уже есть и вполне работоспособна поддержка JS через тот же JavaScriptCore. QtWebEngine (пока что), если смотреть исходники Qt 5.4, впилен весьма грубо и практически не интегрирован с остальными подсистемами Qt - в отличие от того, как расползся QtWebKit. Всё упирается в то, что пилить свой полноценный Web-движок разработчики Qt не в состоянии (и здесь их не за что винить, это действительно большой труд), а чужие разработки, все как одна, представляют собой вещи в себе, требующие подчинения собственным правилам. В Qt хотят иметь интегрированный веб-движок, а всё, что сейчас есть полноценное и актуально развивающееся (Blink, Gecko...), навязывает свои правила. Какая уж тут интеграция. Если вот так посмотреть, то единственный актуальный браузер, движок которого интегрируется с ОС, а не пытается всё тянуть на себе, это Internet Explorer. :-\ (для озабоченных: это всего лишь мрачная шутка)
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	29. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+1 +/–
	Сообщение от Анонимомус on 23-Апр-15, 12:39
	Webkit не умирал, единственный момент, возможно в Qt использовалась не 2-я его версия.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	47. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+2 +/–
	Сообщение от Аноним (??) on 24-Апр-15, 06:50
	> Webkit не умирал, единственный момент, возможно в Qt использовалась не 2-я его > версия. Его обновление каждый раз тоже дорогого стоит, со слов Qt-шников - и я им, почему-то, верю. А обновлять нужно часто, чтобы не поставлять в составе Qt дырявый софт, как минимум. Проблема в том, что собирать "абы как, лишь бы собиралось" (то есть вдали от принципа воспроизводимости сборки и прочих досадных, с точки зрения разработчика, мелочей) для Qt проще Chromium (в который, к тому же, охотнее принимают патчи - Apple в этом плане очень консервативна), но это оборачивается головной болью для мейнтейнеров ОС, по уже изложенным причинам. Как ни сделай - кто-то, делающий действительно полезное дело для мира open source, пострадает. У каждого здесь своя логика; взять тот же FFmpeg: разработчикам Chromium нужна его патченая под Chromium версия, разработчикам Qt на это пофиг, лишь бы FFmpeg не становился частью ABI, а мейнтейнерам ОС это дополнительная головная боль - потому что именно они отвечают перед пользователями за лицензионную чистоту, отсутствие уязвимостей и тому подобное; потому что даже если Chromium удаётся заставить использовать системный FFmpeg, это не гарантирует отсутствие сбоев в работе, причём разработчики Chromium после этого могут запросто отказаться помогать, ибо не поддерживаемая сборка; и так далее.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

2. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
Сообщение от Аноним (??) on 23-Апр-15, 09:19
> Chromium жёстко завязан на использование поставляемого в его составе JavaScript-движка V8, что автоматически ставит крест на архитектурах за пределами Intel x86. На arm, mips, powerpc работает, на других архитектурах и с ffmpeg будут проблемы
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	–1 +/–
	Сообщение от AlexYeCu_not_logged on 23-Апр-15, 09:53
	>На arm, mips, powerpc работает, на других архитектурах и с ffmpeg будут проблемы Какие? На arm вон вполне работает, производительность, правда, не замерял.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	23. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
	Сообщение от Аноним (??) on 23-Апр-15, 11:55
	>> Chromium жёстко завязан на использование поставляемого в его составе JavaScript-движка V8, что автоматически ставит крест на архитектурах за пределами Intel x86. > На arm, mips, powerpc работает, на других архитектурах и с ffmpeg будут > проблемы Насколько знаю, Chromium в обязательном порядке требует JIT. Который в случае V8, если верить обсуждаемой дискусии (бр-р-р), работоспособен только на i386/amd64.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	37. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+2 +/–
	Сообщение от Аноним (??) on 23-Апр-15, 15:02
	> если верить обсуждаемой дискусии (бр-р-р), работоспособен только на i386/amd64. Вот те раз. А как же у меня хромиум на армовской платке работал?
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	46. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
	Сообщение от Аноним (??) on 24-Апр-15, 06:34
	Значит, у меня (и кого-то в дискуссии... придётся опять в неё лезть) сведения неверные. Спасибо за уточнение. :)
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

4. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+3 +/–
Сообщение от анн on 23-Апр-15, 09:32
заголовок к содержанию не имеет абсолютно никакого отношение.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	26. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
	Сообщение от Аноним (??) on 23-Апр-15, 12:05
	> заголовок к содержанию не имеет абсолютно никакого отношение. Почему?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

7. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+2 +/–
Сообщение от arzeth (ok) on 23-Апр-15, 09:43
> Сборка 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
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	22. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+2 +/–
	Сообщение от Аноним (??) on 23-Апр-15, 11:54
	>> Сборка 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).
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	59. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
	Сообщение от freehck (ok) on 27-Апр-15, 01:17
	> Даже если заставить таки собираться с системной версией (что потребует периодического допиливания кода chromium из-за разницы API FFmpeg разных версий) Не говоря уже о том, что в Debian уже 2 релиза нету ffmpeg, а вместо него libav.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	61. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	–1 +/–
	Сообщение от wWolf on 30-Апр-15, 13:30
	Не правда ваша, в свежерелизнутой 8-ке (Jessie) исправили это недоразумение мантейнера-фанатика от libav, и теперь ffmpeg этот действительно ffmpeg, ну и libav тоже пока выкидывать не стали. А для тех кто был на тестинге это случилось еще год-полтора назад.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	62. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
	Сообщение от Andrey Mitrofanov on 30-Апр-15, 15:59
	> Не правда ваша, в свежерелизнутой 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.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	63. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
	Сообщение от Andrey Mitrofanov on 30-Апр-15, 16:04
	>> тоже пока выкидывать не стали. А для тех кто был на >> тестинге это случилось еще год-полтора назад. > --А что, отец, тестинги в городе есть? > --Кому и unstable - тестинХ. > В sid-е - есть, а в jessie b stretch-е https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763148#msg159 > *нет*. Хотя, да. Если "давно", то, возможно, до заморозки и прореживания jessie это было по-другому. ++Что ж Вы, свои тестинги не чистите, что ли? > //На p.d.o сам как-нибудь.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

8. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	–1 +/–
Сообщение от nc (ok) on 23-Апр-15, 09:47
Пускай выкупят у оперы исходники Presto и включат в Qt (а заодно и исходники откроют)!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
	Сообщение от Аноним (??) on 23-Апр-15, 09:50
	Отличная идея, денег подкинешь?
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	16. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	–1 +/–
	Сообщение от Аноним (??) on 23-Апр-15, 10:50
	Краудсорсинг
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	33. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	–1 +/–
	Сообщение от nc (ok) on 23-Апр-15, 13:19
	При чем тут деньги? Если продукт хороший, то компания, открывающая его, получает бесплатную разработку и поддержку продукта сторонними разработчиками в обмен на предоставление исходников всему миру.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	36. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
	Сообщение от Аноним (??) on 23-Апр-15, 13:48
	Учитывая, что Opera забила на Presto и переехала на Chromium, им эта бесплатная разработка и поддержка не нужна.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

12. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+1 +/–
Сообщение от AKR (ok) on 23-Апр-15, 10:01
Тут (https://github.com/OtterBrowser/otter-browser/wiki/QtWebEngi...) Emdek ведёт вики по нехватающим в QtWebEngine вещам Источник, и связная тема тут: http://forum.ru-board.com/topic.cgi?forum=5&topic=46573&star...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+1 +/–
Сообщение от Собака on 23-Апр-15, 10:25
XULRunner же!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	18. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
	Сообщение от Аноним (??) on 23-Апр-15, 10:56
	Уже было примерно 5 попыток портирования XUL на Qt (Firefox на Qt). Пока неуспешно. Получается, что этот XUL не отличается переносимостью.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	54. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+3 +/–
	Сообщение от Slowpoke on 24-Апр-15, 16:18
	ЗулРаннер не нужно, хватило бы движка для рендера страниц - Геко(или что там у Мозиллы свежее)
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

17. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+2 +/–
Сообщение от Михрютка (ok) on 23-Апр-15, 10:51
некоторые цитаты прекрасны некто@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. "чума на оба ваших чума!"(с)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	27. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
	Сообщение от Аноним (??) on 23-Апр-15, 12:08
	>[оверквотинг удален] > 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 - есть там же, в дискуссии. :)
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	30. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+3 +/–
	Сообщение от Михрютка (ok) on 23-Апр-15, 12:40
	> Что самое смешное, уже известно, что если 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 ШТОА а хотя чего я удивляюсь, после мускля-то. "тут уже не исправишь ничего господь жги"
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	43. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
	Сообщение от GotF (ok) on 23-Апр-15, 19:02
	> The only part so far, that depends on QtWebEngine in kdepim is KSieveUi::SieveEditorWebView Чистая победа.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

19. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+3 +/–
Сообщение от Аноним (??) on 23-Апр-15, 11:45
Вообще с браузерами беда ... Кривые они все...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	38. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+1 +/–
	Сообщение от Аноним (??) on 23-Апр-15, 15:09
	> Вообще с браузерами беда ... Кривые они все... В данном случае злобство в том что ЛИБА которая будет рендеря пагу ФОРКАТЬ ПРОЦЕССЫ, городить песочницы и делать over 9000 незапрошенных в общем то действий - это ЖЕСТЬ.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

28. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	–2 +/–
Сообщение от Аноним (??) on 23-Апр-15, 12:26
Да включайте в LSB - вместе с Dbus - а не договаривайтесь с каждым комьюнити отдельно. Только пульсу не берите, пожалуйста, в стандарт, описывающий либы, которые обязаны быть в любом линуксе.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	31. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
	Сообщение от Andrey Mitrofanov on 23-Апр-15, 12:53
	> Да включайте в LSB - вместе с Dbus - а не договаривайтесь > с каждым комьюнити отдельно. Только пульсу не берите, В zewstemdie же. Он уже "в каждой затычке". А LSW не молодёжен. </>
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

32. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+1 +/–
Сообщение от правдоруб on 23-Апр-15, 13:13
>в составе широко распространённого тулкита Qt поставляется QtWebEngine Ну и комбайн... Кто-нибудь уже предлагал переписать Emacs на Qt?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	34. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
	Сообщение от Аноним (??) on 23-Апр-15, 13:26
	А что, было бы интересно.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	35. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
	Сообщение от Andrey Mitrofanov on 23-Апр-15, 13:47
	> А что, было бы интересно. $ konsole -e emacs -nw_
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	60. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
	Сообщение от freehck (ok) on 27-Апр-15, 01:24
	>>в составе широко распространённого тулкита Qt поставляется QtWebEngine > Ну и комбайн... Кто-нибудь уже предлагал переписать Emacs на Qt? А почему не Qt на Elisp? А то я чувствую, что мсьё знает толк в извращениях.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

39. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+4 +/–
Сообщение от Aceler (ok) on 23-Апр-15, 18:27
Гм. Был KHTML — делали на KHTML. Потом пришёл QtWebKit — форк KHTML, начали переезжать на QtWebKit. Теперь вот QtWebKit собираются заменить на QtWebEngine. Может, им просто откопать обратно KHTML?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	41. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	–1 +/–
	Сообщение от Andrey Mitrofanov on 23-Апр-15, 18:51
	> Может, им просто откопать обратно KHTML? 1. Им нужен веб-движок - для понтоваться перед пацанами. 2. Ментеёнить или девелопить они его не могут. Вывод: тащут всё, что недевелопят модные ребята с раёна с синдромом раздражённого релиза. Догонялки, навар, бульон. Всё так и было задумано. Теми модными ребятми.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	48. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
	Сообщение от Аноним (??) on 24-Апр-15, 07:03
	> Гм. Был KHTML — делали на KHTML. Потом пришёл QtWebKit — форк > KHTML, начали переезжать на QtWebKit. Теперь вот QtWebKit собираются заменить на > QtWebEngine. > Может, им просто откопать обратно KHTML? KHTML делали не в Qt. И, судя по проскакивающим заявлениям, от KHTML в KDE планируют отказываться, его банально практически никто не поддерживает.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	49. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
	Сообщение от nib on 24-Апр-15, 10:46
	> KHTML делали не в Qt Lars Knoll, Simon Hausmann.. ага;) бтв от khtml планируют отказаться уже много лет
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	50. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
	Сообщение от Аноним (??) on 24-Апр-15, 11:03
	Так они, вроде, тогда были лишь KDE-разработчиками, не?
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	52. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+1 +/–
	Сообщение от nib on 24-Апр-15, 11:48
	Судя по их linkedin`у lars уже в троллтехе работал, simon да только в kde участвовал
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	51. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
	Сообщение от Аноним (??) on 24-Апр-15, 11:06
	> бтв от khtml планируют отказаться уже много лет BTW, когда патчил KDE под OpenBSD :) , я не стал заморачиваться на тему "почему падает KJS" и сразу поставил kwebkitpart по умолчанию - жёсткая run-time зависимость и приоритет выше KHTML. Ни одной жалобы. Так что кое-где _уже_ отказались от KHTML. ;)
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

40. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	–1 +/–
Сообщение от Аноним (??) on 23-Апр-15, 18:41
Пусть лучше помогут Servo допилить. За одно и его используют)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	42. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
	Сообщение от Andrey Mitrofanov on 23-Апр-15, 18:53
	> Пусть лучше помогут Servo допилить. За одно и его используют) Ви-таки предлагаете им поработать на Вас? Не стесняйтесь, озвучьте бюджет.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

44. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	–1 +/–
Сообщение от Аноним (??) on 23-Апр-15, 22:55
Отставьте как есть. Зато в нем и флеш и html5 работают, в отличии от.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

45. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+2 +/–
Сообщение от nexfwall (ok) on 24-Апр-15, 00:39
Тут выбора всего 2. Либо перепиливать chromium как надо, чтобы к его пересборке не было никаких претензий. Либо посылать QtWebEngine куда подальше. > Мультипроцессная архитектура Chromium автоматически наследуется в QtWebEngine, усложняя контроль над работающими приложениями. Чот мне не очень охота, чтобы внезапно оказывалось, что софт использующий библиотеку, внезапно форкался, когда он не должен.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

53. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
Сообщение от Slowpoke on 24-Апр-15, 16:13
А почему бы не выкинуть Webkit и взамен использовать SpiderMonkey|GreaseMonkey от Мозиллы?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	55. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+2 +/–
	Сообщение от Andrey Mitrofanov on 24-Апр-15, 17:35
	> А почему бы не выкинуть 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
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	56. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	–2 +/–
	Сообщение от DFX (ok) on 25-Апр-15, 05:22
	Но ведь Вы, Товарищ Язвитель, поняли что речь автора выше о Gecko. Ну так, в чём проблема с ним ?
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

57. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	+/–
Сообщение от бедный буратино (ok) on 25-Апр-15, 15:43
от вебкита до вебкита сто километров езды но дистрибу дебиана это дело до ... звезды
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	58. "Дискуссия о возможности включения QtWebEngine в дистрибутивы..."	–1 +/–
	Сообщение от Andrey Mitrofanov on 26-Апр-15, 09:59
	> но дистрибу дебиана > это дело до ... звезды Мимо тёщина забора я без шутки не хожу, то s-d туда засуну, то бородатого ветерана покажу.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема