Разработчики KDE предложили включить свои библиотеки в состав Qt

По-моему, идея неплохая. Это должно упростить разработку приложений на qt, более интегрированных в linux-окружение. Правда, запихивать целиком весь kdelibs в qt, вероятно, будет избыточно, но, думаю, они там ребяты толковые, разберутся, что можно выкинуть или держать в отдельной библиотеке, а что действительно необходимо.

а они разработчиков Qt еще не спрашивали? просто решили показать миру, какой у них ДТ?

> и в чем троллинг?

в том, что при уровне кода KDE, он не когда не попадет в Qt

Настанет день и нокия придет к KDE`шникам и будут просить включить все qt библиотеки к себе.

И откажутся KDE`шники и скажут нокии ваш код убогий и злой, приходите на следующей неделе.

GNU is not Unix

>>если включат в состав Qt, то КДЕшникам придется стабилизировать и API/ABI, степень свободы будет меньше по изменению кода.

это будет конец QT.

Судя по вашему написанию названия

С другой стороны, так как Qt идет к модуляризации и раздельным релизам своих компонентов, то KDE вполне может и вписаться в новый Qt

Ну вот, пилили-пилили куте и получили... гном.

ваше мнение становится никому не интересным, ибо вы не знаете что такое Qt.

Хотел бы я увидеть результат такого слияния кода.

Cначала понаклепали своих кривых велосипедов, а теперь, когда поняли, что не в состоянии привести эту кучу дерьма в пристойный вид, решили скинуть эту работу на ноклу. КДЕ такое КДЕ.

Фееричненько

Лоровские эксперты как всегда на высоте

~$ aptitude install klipper -s
Следующие НОВЫЕ пакеты будут установлены:        
  kdebase-runtime{a} kdebase-runtime-data{a} kdelibs-bin{a} kdelibs5-data{a} kdelibs5-plugins{a} kdoctools{a} klipper libattica0{a} libclucene0ldbl{a} libeggdbus-1-0{a} libgraphicsmagick3{a} libiodbc2{a} libkde3support4{a} libkdecore5{a} libkdesu5{a} libkdeui5{a} libkdnssd4{a} libkfile4{a} libkhtml5{a} libkio5{a} libkjsapi4{a} libkjsembed4{a} libkmediaplayer4{a} libknewstuff2-4{a} libknewstuff3-4{a} libknotifyconfig4{a} libkntlm4{a} libkparts4{a} libkpty4{a} libkrosscore4{a} libktexteditor4{a} libkutils4{a} libnepomuk4{a} libnepomukquery4a{a} libphonon4{a} libplasma3{a} libpolkit-agent-1-0{a} libpolkit-gobject-1-0{a} libpolkit-qt-1-0{a} libsolid4{a} libsoprano4{a} libssh-4{a} libstreamanalyzer0{a} libstreams0{a} libthreadweaver4{a} libutempter0{a} libxine1{a} libxine1-bin{a} libxine1-console{a} libxine1-ffmpeg{a} libxine1-misc-plugins{a} libxine1-plugins{a} libxine1-x{a} oxygen-icon-theme{a} phonon-backend-xine{a} plasma-scriptengine-javascript{a} shared-desktop-ontologies{a} soprano-daemon{a}
Необходимо получить 55,4 MB архивов. После распаковки 140 MB будет занято.

Теперь почти все это будет в Qt? o_O

нет детка это будет в Qt += KDE.

Это предложение не пройдёт. Для Nokia важны только мобильные платформы. А внедрение библиотек KDE окончательно разделит Qt на мобильную и PC части.

С другой стороны идея конечно интересная. Получится что-то вроде .net framework-а на С++. Но как же кросплатформенность? С Unix-like всё понятно, а вот кто будет пилить библиотеки KDE для Mac и Win? Со временем эти части захиреют, а с ними и кросплатформенность.

Давно пора. Сейчас kdelibs по сути — это свой тулкит, который зависит от ещё одного тулкита. (Qt) Люди, которые просят для вон той проги сделать зависимость от KDE опциональной, просто не понимают, что в кедах те же классы кнопок, полей ввода и прочего свои, и просто так переключаться между QLineEdit и KLineEdit не получится.

Объединение решило бы эту задачу, плюс Qt получило бы нормальную поддержку кдешных тем и многие другие (куда более полезные) вещи.

P.S. А откуда взялось 6.0? Если Qt будет 5.0, то и KDE должно быть 5.0. На опеннете так и написано…

Люди, которые просят для вон той проги сделать зависимость от KDE опциональной, просто не понимают, что в кедах те же классы кнопок, полей ввода и прочего свои

Вот этим людям и не понятно: на..я это было делать?

2любители орать про 30Гб

% pacman -Si qt | grep установленного
Размер установленного : 106808,00 K
% pacman -Si kdelibs | grep установленного
Размер установленного : 66640,00 K

Плюс после слияния суммарный размер будет меньше, за счёт выкидывания врапперов. А всё лишние модули (kded, libplasma) можно вообще вынести в отдельные пакеты и ставить их только при необходиомсти.

>KDE 6.0 будет написано на D2?

Ах эти прекрасные мечты… :)

> не раннее выхода KDE 6.0

Здесь правильно «не ранее».

>Вот этим людям и не понятно: на..я это было делать?

Затем, что в Qt нет даже такой элементарщины, как настройка «текст под значками/справа/только иконки».

пусть делают отдельную ветку, мне не нужны кдешные либы в моем дистрибутиве

Почитай исходный пост Шумахера. Там написано, что это было нужно потому, что на тот момент, как это появилось, в Qt этого еще не было. Или было не то и не так. Очень много новшеств, появившихся в Qt есть переосмысленные старые фичи из kdelibs.

>Корнелиус Шумахер, старожил среди разработчиков KDE и текущий и.о. руководителя проекта

4.2. Шумахер не руководитель - он президент KDE e.V. Идейный предводитель - все тот же Aaron Seigo.

Отлично, если реализуют. Наконец-то прекратится нытьё гномосеков, желающих поставить какое-нибудь приложение из kde :)

Вообще давно пора избавиться от лишних сущностей в виде kdelibs и прочей фигни и включить необходимые вещи в Qt. Идея отличная, надеюсь реализуют.

> Затем, что в Qt нет даже такой элементарщины, как настройка «текст под значками/справа/только иконки».

Разве?

button = QtGui.QToolButton()
button.setToolButtonStyle(QtCore.Qt.ToolButtonTextUnderIcon)

>Корнелиус Шумахер ... предложил объединить KDE и Qt в единую платформу разработки

Прочь свои грязные быдлокодерские ручонки от кьюти!

У этого подхода есть как плюсы, так и минусы. С одной стороны, резко уменьшится кол-во сущностей, если кеды интегрируют свои либы на QT, с другой стороны, всё перейдёт под контроль одной фирмы (впрочем, итак уже от неё всё зависит) и придётся стабилизировать API и развивать его эволюционно (но это скорее плюс).

Короче, кеды готовы перенять модель Гнома, у которого и десктоп и GTK+ развиваются синхронно в рамках одного проекта.

>Разве?

Я говорю о Trolltech.conf и qtconfig.

*Мечтательно* если это грамотно сделают, связка kdelib+qtlib похудеет раза в полтора, а может и больше.
Да и Qt хоть и потолстеет, по функционалу выиграет заметно. А толстеть оно итак собирается.

> Люди, которые просят для вон той проги сделать зависимость от KDE опциональной, просто не понимают, что в кедах те же классы кнопок, полей ввода и прочего свои, и просто так переключаться между QLineEdit и KLineEdit не получится.

Честно говоря, не думал, что дела именно так обстоят. В таком случае, объединение наверное нужно.

Непонятно только, при чем здесь разработчики Qt. Они, наверное, уже взяли от KDE всё, что считали нужным - тотже KHtml. Получается, что авторы KDE напридумывали кучу своих велосипедов, а теперь просят помочь с ними разобраться, признаваясь, что они сам задолбались их докручивать?

2любители орать про 30Гб

толсто ведь :)

А всё лишние модули (kded, libplasma) можно вообще вынести в отдельные пакеты и ставить их только при необходиомсти.

Я тут глянул ftp://ftp.kde.org/pub/kde/stable/latest/Mandriva/2010.1/x86_64/ и сразу подумал что KDEрасты по дроблению пакетов хотят переплюнуть Gnome с GTK+. Что-то вы поздновато задумались о том кто был прав когда пришёл к такой организации библиотек как у Gnome.

Qt берут и переосмысливают. Получается лучше

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

И да, я давно искал DE на Qt, не завязанное на kdelibs, теперь его предлагают сделать! Очень надеюсь на успех этой идеи.

О, может после этого совокупления в экстазе они станут единым жирным целым и станут никому не нужными :}

>button.setToolButtonStyle(QtCore.Qt.ToolButtonTextUnderIcon)
Вот, поскольку такие вещи наконец-то появились в Qt, kdelibs предлагается ликвидировать. А немногие оставшиеся фичи портировать в Qt.
Хотя я, отчасти, не понимаю, почему нельзя просто выкинуть повторения из kdelibs — для уменьшения размеров.

а не легче приложения в кде переписать на чистом qt ?? плодить лишние сущности ведь не имеет смысла.

>Что-то вы поздновато задумались о том кто был прав когда пришёл к такой организации библиотек как у Gnome.

Прав в чём? В том, что не всем счастливится быть одновременно разрабами и тулкита, и DE?

Хитрый план.

Не легче.

Не уж то у тулбаров теперь в контекстном меню появится lock? :}

А вообще, если с умом подойти и выбрать только нужное, то идея неплохая.

в ходе обсуждения было установлено: Qt и KDE не нужны, ибо едва набрали 1,5 страницы вместе взятые.

> а не легче приложения в кде переписать на чистом qt ??

некоторые пишутся в стиле - ядро на Qt, гуй на kdelibs

но даже в этом случае портирование представляет головную боль

> И последующая реорганизация библиотек последнего уже сможет привести к переносу кода в Qt, что снова приведёт к несовместимости и созданию KDE 6.0 на базе гипотетического Qt 5.0.

На самом деле это просто гномеры подкупили главных действующих лиц, чтобы шумом вокруг KDE 5.0 != KDE 5 скрыть готовящийся неудачный релиз GNOME3.

> Забористый план.

о.ф.

> Qt берут и переосмысливают. Получается лучше

примерчик не приведешь?

SSD-лох детектед

В Qt уже полно всего полезного (и не очень) а теперь хотят еще туда напихать всякой дряни от кдешных быдлокодеров (все помнят их первые релизы 4 версии кед). Qt все же интересна как платформа для мобильного софта и пихать в него непойми что, да при том раздувать размеры самого тулкита это перебор.

Если разрабы кед такие умные, так пилили бы основной тулкит, отправляли патчи, вместо того чтобы свои либы городить, а теперь они захотели чтобы их велосипеды приняли в апстрим, в Нокии не совсем дураки сидят, они такое просто не пропустят(имхо).

Снова колбасит без мутаций этот kde-призрак чего-то лучшего ?))