LINUX.ORG.RU

KHTML возможно будет заброшен.


0

0

Разработчики KDE подумывают сменить движок отрисовки HTML с KHTML на WebKit от Safari. Среди причин больший интерес к WebKit со стороны коммерческих производителей, в том числе Adobe, то, что Konqueror показывал бы сайты так же, как Safari и так называемый "bug-for-bug compatibility". Напомним, что WebKit является движком KHTML + патчи Аpple. По ссылке можно посмотреть интервью на 26 минут с KDE-разработчиками Lars Knoll и George Staikos.

>>> Подробности

★★★★★

Проверено: Shaman007 ()

Re: KHTML возможно будет заброшен.

Примерно такая же история приключилась во время войны в авиации... вроде как с двигателями для спитфайров. Англичане продали лицензию на движок американцам, те его доработали и продали обратно англичанам :)

h8 ★★★ ()

KHTML возможно будет бэкпорчен.

А как у KHTML и WebKit с лицензиями? Как у них с совместимостью? В чём отличия WebKit от KHTML?

Camel ★★★★★ ()

Re: KHTML возможно будет заброшен.

Сначала Apple'овцы старательно вычищали из KHTML следы Qt и KDE (и так до конца не вычистили), теперь KDEшнеги будут запихивать всё это обратно :)

AsphyX ★★★ ()

Re: KHTML возможно будет заброшен.

Это было бы хорошим делом. Проще и выгоднее иметь один общий движок.

dave ★★★★★ ()

Re: KHTML возможно будет заброшен.

Блин, я только ЗА!

Casus ★★★★★ ()
Ответ на: Re: KHTML возможно будет заброшен. от dave

Re: KHTML возможно будет заброшен.

>Это было бы хорошим делом. Проще и выгоднее иметь один общий движок.

кому, эппловцам? Им видимо не сильно хочется постоянно отрывать khtml от kde и qt. А кдешнеги по-другому (без прибивания гвоздями к кде), видимо писать просто не умеют

geek ★★★ ()
Ответ на: Re: KHTML возможно будет заброшен. от anonymous

Re: KHTML возможно будет заброшен.

Хуже гекона только OOo, но он, слава богу, для просмотра сайтов не используется.

anonymous ()

Re: KHTML возможно будет заброшен.

ахренеть. и что они говорят по-поводу лицензирования? а разработка такая же закрытая будет? бред в общем какой-то.

aim1159 ★★★★★ ()

Re: KHTML возможно будет заброшен.

Imho правильно, с эплами дружить весьма полезно.

YesSSS ★★★ ()

Re: KHTML возможно будет заброшен.

В общем и целом в этой идее ничего плохого я не вижу. С лицензиями, правда, пока не понял тоже...

leenooks ()
Ответ на: Re: KHTML возможно будет заброшен. от aim1159

Re: KHTML возможно будет заброшен.

webkit.org

WebKit is open source software with portions licensed under the LGPL and BSD licenses. Complete license and copyright information can be found within the code.

YesSSS ★★★ ()
Ответ на: Re: KHTML возможно будет заброшен. от geek

Re: KHTML возможно будет заброшен.

> А кдешнеги по-другому (без прибивания гвоздями к кде), видимо писать просто не умеют

... а не-"кдешнеги" видят смыслом своего существования пихать glib/gtk/gtk+/cairo/glibmm/gtkmm/cairomm и кучи одного и того же в разных позах куда попало, абсолютно не задумываясь о конечных пользователях... я практически весь день убил на выкачивание и компиляцию всего этого хлама только ради посмотреть что такое inkscape... пока так и не увидел... вот думаю, а стоит ли оно того?

arsi ★★★★★ ()

Re: KHTML возможно будет заброшен.

Это же надо было так переврать новость: в оригинале шла речь о том, что WebKit возможно включат в KDE4 наряду с уже существующим KHTML, а вовсе не о том, что последний будет заброшен.

birdie ★★★★★ ()
Ответ на: Re: KHTML возможно будет заброшен. от birdie

Re: KHTML возможно будет заброшен.

За что на Golem.de купили, за то и продаём :) Кстати, что-то с форматированием новости случилось, блын.

ptarh ★★★★★ ()
Ответ на: Re: KHTML возможно будет заброшен. от arsi

Re: KHTML возможно будет заброшен.

>а не-"кдешнеги" видят смыслом своего существования пихать glib/gtk/gtk+/cairo/glibmm/gtkmm/cairomm и кучи одного и того же в разных позах куда попало, абсолютно не задумываясь о конечных пользователях...

>я практически весь день убил на выкачивание и компиляцию всего этого хлама только ради посмотреть что такое inkscape...

объясни мне как соотносится "конечный пользователь" с "компиляцией". И чем подход "одна большая библиотека" лучше подхода "много маленьких библиотек".

geek ★★★ ()
Ответ на: Re: KHTML возможно будет заброшен. от birdie

Re: KHTML возможно будет заброшен.

>а вовсе не о том, что последний будет заброшен.

зачем им два html-движка? или это в комплект к трем текстовым редакторам? :)

geek ★★★ ()
Ответ на: Re: KHTML возможно будет заброшен. от geek

Re: KHTML возможно будет заброшен.

> зачем им два html-движка? или это в комплект к трем текстовым редакторам? :)

Kedit - это опция, а основных только два - Kate и KWrite.

Учитывая, что и KHTML и WebKit до сих пор не так гладко всё отображают, как Gecko, то хуже от того, что движков будет больше, не будет.

birdie ★★★★★ ()
Ответ на: Re: KHTML возможно будет заброшен. от birdie

Re: KHTML возможно будет заброшен.

>Учитывая, что и KHTML и WebKit до сих пор не так гладко всё отображают, как Gecko, то хуже от того, что движков будет больше, не будет.

Два редактора + два html-движка. Я понял что такое kde-way =)

PS: а почему бы им в таком случае не взять gecko? если уж он отображает _лучше_ ?

geek ★★★ ()
Ответ на: Re: KHTML возможно будет заброшен. от anonymous

Re: KHTML возможно будет заброшен.

> Ага gecko:)

Если мегагерцов да памяти не жалко, то да. Я лично Firefox-ом пользоваться не могу из-за тормозов на машине, на которой Safari просто летает.

anonymous ()

Re: KHTML возможно будет заброшен.

если это их же движок с некоторыми правками, с которыми они согласны, то почему бы и нет, лицензия-то у него GPL

лишь бы далее опять разделений не было и не потеряли того, что есть у них и не делала apple -- большими силами один движок легче развивать

vadiml ★★★★★ ()
Ответ на: Re: KHTML возможно будет заброшен. от birdie

Re: KHTML возможно будет заброшен.

Там речь о том, как я понимаю, что подумывают также о том, чтобы оставить KHTML "на выбор", но это тоже только размышления и не факт, что его не выкинут полностью, если перейдут на эппловский. Если вообще перейдут. В принципе, оно было бы логично, учитывая больший "вес" эппловского движка у разработчиков сайтов и тот факт, что дублировать очень похожие движки слегка маразматично.

ptarh ★★★★★ ()
Ответ на: Re: KHTML возможно будет заброшен. от arsi

Re: KHTML возможно будет заброшен.

> ... а не-"кдешнеги" видят смыслом своего существования пихать glib/gtk/gtk+/cairo/glibmm/gtkmm/cairomm и кучи одного и того же в разных позах куда попало, абсолютно не задумываясь о конечных пользователях... я практически весь день убил на выкачивание и компиляцию всего этого хлама только ради посмотреть что такое inkscape... пока так и не увидел... вот думаю, а стоит ли оно того?

ЖЖОШ! Где такую траву добыл?

anonymous ()
Ответ на: Re: KHTML возможно будет заброшен. от geek

Re: KHTML возможно будет заброшен.

> объясни мне как соотносится "конечный пользователь" с "компиляцией".

обясняю: "конечный пользователь" -- это тот, кто получил "конечный продукт", пусть даже в виде сырца, тем более что для слакварщика это часто единственный вариант, и пытается его поставить. опять же, для случая слаки (или генту, наверное) инсталяция == компиляция. вот если б я его качал ради поправить, прокачать поверху несколько патчей в эксперементальных целях, посмотреть "а что если вот так..", то тогда действительно такого человека врят ли можно назвать "конечный пользователь".

> И чем подход "одна большая библиотека" лучше подхода "много маленьких библиотек".

если прога зависит от одной из набора "много маленьких библиотек", причем у меня установлена более позняя версия, чем требуется, то мне придется обновлять не только ее, а еще и весь этот зоопарк, и если я не являюсь разработчиком, причем разработчиком glib*/gtk*, то в начале процесса я даже не представляю себе, сколько всего мне придется обновить...

если это qt, например, то я просто выкачаю последнюю версию тулкита, скомпилю, проинсталю... если мне чего нибудь будет там мешать, мне не в лом будет набрать ./configure -no-sql -no-xml ... и так далее по порядку... вот только не нужно мне говорить о бОльших размерах -- qt3.3.7 15M, qt4.2.2 37M, все то, что мне пришлось выкачать для обновления glib*/gtk*/cairo* переваливает за 50 мег...

arsi ★★★★★ ()

Re: KHTML возможно будет заброшен.

дествительно, еще бы до кучи добавили возможность юзать gecko в КДЕ, было бы замечательно.

isden ★★★★★ ()

Re: KHTML возможно будет заброшен.

Это круто ! В Symbian на Nokia тоже стоит движок WebKit ;-)

an ()
Ответ на: Re: KHTML возможно будет заброшен. от anonymous

Re: KHTML возможно будет заброшен.

> ЖЖОШ! Где такую траву добыл?

ftp.gnome.org/pub/GNOME/sources

там ее много, и как вставляет!!! до сих пор отойти не могу... только после нее голова болит сильнее чем 1-го января...

arsi ★★★★★ ()
Ответ на: Re: KHTML возможно будет заброшен. от arsi

Re: KHTML возможно будет заброшен.

>> ЖЖОШ! Где такую траву добыл? >ftp.gnome.org/pub/GNOME/sources

> там ее много, и как вставляет!!! до сих пор отойти не могу... только после нее голова болит сильнее чем 1-го января...

Я про то, что что в исходном посте имелось в виду что, "не KDE-шники" не делают поддержку 10 widget библиотек, они просто не пишут код привязанный жестко к одной из либ, как это делают KDE-шники.

anonymous ()
Ответ на: Re: KHTML возможно будет заброшен. от anonymous

Re: KHTML возможно будет заброшен.

>Ага gecko:)
gecko-hecko
wacko-jacko

your brain will be destroyed and firefox and openoffice ARE GOING TO DIE in the long term, with khtml and koffice replacin' 'em

shafff ()
Ответ на: Re: KHTML возможно будет заброшен. от arsi

Re: KHTML возможно будет заброшен.

> опять же, для случая слаки (или генту, наверное) инсталяция == компиляция.

Слака - обязательно условие?

В том-же gentoo ты-бы просто набрал emerge inkscape, а в бинарном дистре скачал-бы скорее всего меньше(хотя и не всегда) и не тратил-бы время на компиляцию.

YesSSS ★★★ ()
Ответ на: Re: KHTML возможно будет заброшен. от geek

Re: KHTML возможно будет заброшен.

> кому, эппловцам? Им видимо не сильно хочется постоянно отрывать khtml от kde и qt.

Пользователям KDE и Safari вестимо. Проигнорировать их вместе будет сложнее.

Не заглядывал в потроха KHTML, но думаю, что если зависимость от qt и есть, то не настолько большая, и в основном в области 2D-графики, что не так критично для переносимости.

dave ★★★★★ ()
Ответ на: Re: KHTML возможно будет заброшен. от birdie

Re: KHTML возможно будет заброшен.

> в оригинале шла речь о том, что WebKit возможно включат в KDE4 наряду с уже существующим KHTML, а вовсе не о том, что последний будет заброшен.

А как тогда перевести такое предложение?

"Konqueror developers are considering implementing WebKit as the rendering engine for the next version of Konqueror, replacing KHTML [...]"

dave ★★★★★ ()
Ответ на: Re: KHTML возможно будет заброшен. от anonymous

Re: KHTML возможно будет заброшен.

>Не в тему, конечно, но на "Спитфайрах" стоял движок Rolls-Royce.

Не в тем, конечно, но разве в Британии ещё кто-то, кроме Rolls-Royce авиадвижки (в смысле - нормальные, которые можно продать) в последние лет 70 делал?:)

Led ★★★☆☆ ()
Ответ на: Re: KHTML возможно будет заброшен. от ptarh

Re: KHTML возможно будет заброшен.

> За что на Golem.de купили, за то и продаём :)

Пора опрос вешать: не пора ли нам запретить "новости" с сайтов домена .de... ;-)

atrus ★★★★★ ()

Re: KHTML возможно будет заброшен.

Зачем КДЕ яблочные технологии? Потом жырная дядя стиф жобс начнет выпендриваца по поводу своих патчей и накроется все это и KHTML не будет развиваться.

LeeNoox ()
Ответ на: Re: KHTML возможно будет заброшен. от dave

Re: KHTML возможно будет заброшен.

Хотя, конечно, заголовок новости несколько надуманный :)

Было бы правильнее: "KHTML может быть заменен"

dave ★★★★★ ()

Re: KHTML возможно будет заброшен.

а как KHTML может быть заброшен если

[cut]

Напомним, что WebKit является движком KHTML + патчи Аpple

[endcut]

как говориться что раньше было заброшено курица или яйцо :)

alt0v14 ★★★ ()
Ответ на: Re: KHTML возможно будет заброшен. от geek

Re: KHTML возможно будет заброшен.

> Два редактора + два html-движка. Я понял что такое kde-way =)

не без того.

> а почему бы им в таком случае не взять gecko? если уж он отображает _лучше_ ?

а была же вроде привязка в каких-то konqueror-овских версиях -- юзать gecko в качестве движка. потом видимо отмерло. не в последнюю очередь думаю потому что отдельного gecko-движка как не было так и нет.

dmiceman ★★★★★ ()
Ответ на: Re: KHTML возможно будет заброшен. от birdie

Re: KHTML возможно будет заброшен.

Таки да, оба движка на выбор:

Anyway, George also talked about the future: and it looks like WebKit will be part of KDE 4, but possibly just as an option. Together with KPart there will be the option to set either KHTML or WebKit as the default engine. KDE just has to see which one fits the needs of the users and developers better.

GladAlex ★★★★★ ()
Ответ на: Re: KHTML возможно будет заброшен. от dave

Re: KHTML возможно будет заброшен.

> Не заглядывал в потроха KHTML, но думаю, что если зависимость от qt и есть, то не настолько большая, и в основном в области 2D-графики, что не так критично для переносимости.

QString? впрочем, тоже поленился и не посмотрел..

dmiceman ★★★★★ ()
Ответ на: Re: KHTML возможно будет заброшен. от Renso

Re: KHTML возможно будет заброшен.

Интересно, чем их gtkhtml не устроил?

P.S. Где-то слышал, что GtkHTML - тоже произошел от khtml, интересно, так это?

YesSSS ★★★ ()

Re: KHTML возможно будет заброшен.

На ЛОР запостили в доску перевранную новость => будет флейм.
Закон природы.

Deleted ()
Ответ на: Re: KHTML возможно будет заброшен. от YesSSS

Re: KHTML возможно будет заброшен.

> В том-же gentoo ты-бы просто набрал emerge inkscape, а в бинарном дистре скачал-бы скорее всего меньше(хотя и не всегда) и не тратил-бы время на компиляцию.

ставить было бы действительно намного проще, а вот скачивать пришлось бы одинаково, gentoo спасает только от опциональных зависмостей (это которые точно также вырезаются при ./configure, в сравнении с ручной сборкой, при установке из пакетов можно и об обновление всего вплоть до глибсов при установке крайней версии перделки лбом удариться), inkscape без gtk не соберешь

Syncro ★★★★★ ()
Ответ на: Re: KHTML возможно будет заброшен. от geek

Re: KHTML возможно будет заброшен.

>объясни мне как соотносится "конечный пользователь" с "компиляцией". И >чем подход "одна большая библиотека" лучше подхода "много маленьких >библиотек".

>geek ** (*) (13.12.2006 19:03:26)

Хрен его знает чем лучше.
Но я бы выбрал одну на 20 Мб чем 200 по 100 кб ;-)

kitov ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.