Корнелиус Шумахер (Cornelius Schumacher), президент организации KDE e.V., опубликовал (http://lists.kde.org/?l=kde-core-devel&m=128842761708404&w=2) в списке рассылки разработчиков KDE предложение о слиянии в одно целое библиотек проекта KDE и Qt. По мнению Корнелиуса интеграция стандартных и вспомогательных библиотек KDE (kdelibs, kdepim и kdesupport) в Qt позволит сформировать целостный и более полный API, избавиться от избыточных функций, обеспечить хорошую интеграцию с KDE, упростить поддержку и увеличить переносимость платформы. Интеграция в Qt библиотек KDE также позволит избавить разработчиков прикладных приложений от дилеммы: использовать дополнительные классы, но привязать свое приложений к библиотекам KDE, или ограничить функциональность, но оставить в зависимостях только Qt.
Для проекта KDE выгода также состоит в увеличении числа вовлеченных в развитие библиотек разработчиков. Не секрет, что сотни разработчиков на Qt практически не знакомы с проектом KDE, но, интегрирова...URL: http://www.phoronix.com/scan.php?page=news_item&px=ODczOQ
Новость: http://www.opennet.me/opennews/art.shtml?num=28480
то есть, разработчики, по сути, хотят (предполагают) создать болото, в котором другие разработчики будут увязать по самое горло (если не макушку)
> то есть, разработчики, по сути, хотят (предполагают) создать болото, в котором другие
> разработчики будут увязать по самое горло (если не макушку)Без комментариев, бредятина.
Не помню где, слышал одно высказывание, общий смысл которого такой: "Что бы ты не делал, как бы не старался, всегда будет небольшая горстка людей, которая будет вечно чем-то недовольна. Так вот, насри на их мнение."
Бредятина началась в тот момент, когда из графического тулкита стали делать "платформу". Причём сделали свою реализацию строк, сигналов/слотов, а теперь, когда это реализуемо на стандартных плюсах, отнюдь не хотят расставаться. Идиотская идей КДЕшников - всего лишь очередной шаг в этом направлении. Ладно, эту глупость Nokia вряд ли допустит - ей на MeeGo KDE как-то ни к чему.
Кстати, поделитесь, как qt-шные сигналослоты реализуемы в рамках стандартных плюсов?
Есть кнопка, вызывающая при активации функцию void TButton::press(void); есть объект с функцией void OperationalDlg::Abort(void). Можно ли, не переписывая код кнопки и не наследуясь от него, связать при помощи boost::signal эти две функции: вызывать по нажатию кнопки функцию Abort?
Вариации на тему паттерна Command, из буки Gof.Boost::signal -- одна из реализаций.
Лично мне очень понравилась реализация сего в виде "обобщенных функторов" от Александреску. Просто, элегантно и со вкусом!Но все это реализуется, в конечном итоге, через наследование и, соотв., вызов виртуальных методов.
В C++0x ввел понятие auto переменных, тип которых определяется в момент компиляции, а также, лямбда ф-ции. Кто мешает Вам дергать из кода Баттона, "автоматическую" переменную, которая указывает на определенную Вами лямбду, в которой, в свою очередь, Вы дергаете ф-ции необходимых объектов?
PS: пока это размышления на тему. Не пробывал, поскольку небыло необходимости.
> Но все это реализуется, в конечном итоге, через наследование и, соотв., вызов виртуальных методов.Java-ист в треде по плюсам? Нет пути.
Гы, а ничего, что в самой Qt часть методов того же QWidget тоже виртуальные?
class Q_GUI_EXPORT QWidget : public QObject, public QPaintDevice
{
....
virtual QSize sizeHint() const;
virtual QSize minimumSizeHint() const;
....
virtual void mousePressEvent(QMouseEvent *);
virtual void mouseReleaseEvent(QMouseEvent *);
virtual void mouseDoubleClickEvent(QMouseEvent *);
virtual void mouseMoveEvent(QMouseEvent *);
....
};Тем неменее, pure C++... ;-)
ИМХО, стоит иногда читать умные книжки, типа:
* Александреску А. Современное проектирование на C++. Обобщенное программирование и прикладные шаблоны проектирования
* Вандевурд Д, Джосаттис Н. Шаблоны C++
* Джосьютис Н. Стандартная библиотека C++
* Ezust A, Ezust P. An Introduction to Design Patterns in C++ with Qt 4
* Summerfield M. Advanced Qt Programming: Creating Great Software with C++ and Qt 4И т.д., а не только серию "ХХХХХ для чайников"!
Угу, спасибо.cat books>>todo.list...
зачем Qt завязывать на boost? это две разные библиотеки..
Речь, как я понимаю, не о завязывании одной библиотеки на другую ( я уж молчу, что некоторые куски boost уже вошли в стандарт, а другие вполне могут там оказаться ), а об отказе от обработки исходников moc перед, непосредственно, компиляцией. В принципе, отдельные библиотеки boost показывают, что moc является лишней сущностью.
когда оно создавалось, C++0x еще не было, как и сигналов слотов в бусте, сейчас я согласен, додумать стандарт плюсов, чтобы уже не использовать moc, с другой стороны - чем и кому оно мешает?
> когда оно создавалось, C++0x еще не было, как и сигналов слотов в бусте...Не спорю. :-)
> ...не использовать moc, с другой стороны - чем и кому оно мешает?
Да может и ничем, кроме того, что вспомогательный класс я не могу объявить там же, где и использую (в *.cpp). Пришлось в хидер выносить, чтоб его moc обработал, в принципе не страшно, но глаза мозолит...
Да и зачем плодить сущности сверх необходимого?
подключайте в конце файла #include<name_file.moc> ;) Я думал что такую хорошую доку как у Qt читают все ;)
> подключайте в конце файла #include<name_file.moc>Эм-м-м... Спасибо, учту на будущее :-).
Только, подключение хидера в середине или конце файла, ИМХО, моветон. Дурным вкусом отдает, ИМХО.
Тем, что это лишняя сущность, да еще и вне плюсов, ограничивающая, к примеру, возможность создания шаблонов.
> Причём сделали свою реализацию строк, сигналов/слотов, а теперь, когда это реализуемо на стандартных плюсах, отнюдь не хотят расставаться.Ну сколько можно! Неужели ты считаешь себя умнее тех кто работает в Тролльтек? Учи матчасть, они уже тысячу раз это объясняли: http://doc.trolltech.com/4.7/templates.html
>> Причём сделали свою реализацию строк, сигналов/слотов, а теперь, когда это реализуемо на стандартных плюсах, отнюдь не хотят расставаться.
> Ну сколько можно! Неужели ты считаешь себя умнее тех кто работает в
> Тролльтек? Учи матчасть, они уже тысячу раз это объясняли: http://doc.trolltech.com/4.7/templates.htmlПотому что на сегодняшний день это неправда. Синтаксис можно в максросы обернуть (как они сейчас и делают), будет примерно так же. Не верите - гляньте "под капот" boost::for_each. Динамика тоже реализуема в рамках хоть того же буста. И RTTI самопальный куча народу делала без препроцессоров.
Насколько я понимаю, это было в своё время правдой, и им пришлось изобретать moc, так как не было компиляторов, которые поддерживали бы стандарт в части шаблонов достаточно хорошо. А теперь никто не чешется это выкинуть - ибо просто бибилиотеки не в моде, в моде платформы. В результате в Qt напихано всё - от своего типа строки и коллекций до доступа к базам данных.
Я не знаю какой самопальный RTTI кто придумывает, но мне нужно вылизанное, рабочее решение - такое как в Qt. Приведите пример нормальных фреймворков, обсудим, самопальное не в счет. moc меня лично напрягает не больше чем программирование на самом С++. qmake/cmake автоматизируют работу, так что волноваться не приходится. Если же ты настаиваешь на том, что moc - это некрасиво, то надо начинать с самого С++. С++ - это то еще уродство, и существование moc - это следствие и подтверждение этого.
Достаточно вылизанная платформа С++ без «костылей» называется Ultimate++. Всё красиво, шустро, на шаблонах и макросах. Но к великому огорчению тех кто ратует за «стандартный С++» братья-славяне, которые всё это пишут, «забили» на STL и написали свой «велосипедный» NTL. То ли «в консерватории» у C++ что то не то, то ли «мы все сошли с ума», но никак не вытанцовывается в рамках С++ единый «мир без границ» с бесшовной интеграцией стандартных и не очень библиотек.
контейнеры - это не просто дубляж кода(писал уже http://www.opennet.me/openforum/vsluhforumID3/71929.html#78); про строки написал @Толстый; Я не вижу никакого неудобства в том, что из коробки могу работать сразу с кучей баз данных (http://doc.trolltech.com/4.7/qsqldatabase.html#QSqlDatabase-3)
Далее по строкам, QString намного более функциональна чем std::string, я уже не говорю о том, что std::string не ref-counted тип. Как там с юникодом в стандартных строках? Тоже непонятно.И платформа как-раз таки нужна. Да, можно сделовать подходу unix-way, то чего гном придерживается. Но в итоге получается зоопарк библиотек, каждая имеет свой стиль и свои особенности. Qt имеет единообразный API во всех своих частях, не нужно трахаться настраивать все(не забываем также, что есть другие платформы). Qt дает полный набор инструментов, которыми удобно пользоваться.
>> Да, можно сделовать подходу unix-way, то чего гном придерживается.Вы пишите, но забываете что они изобрели Vala - (дальше читайте про гтк контейнеры и етс - всё за что пинают Qt) http://ru.wikipedia.org/wiki/Vala
Странно да?:)
самый лучший функционал в Qstring - это toStdString()гуи-тулкит должен быть гуём, хорошей библиотекой для строительства интерфейсов, а не помойкой дублированного кода.
в таком случае не они дублируют, а их код дублируют; претензии явно не к тролтеху
Если вы, как и товарищ Толстый, тоже не в курсе, что стандартный std:string способен хранить не только ansi но и уникод - да и даже бинарные данные, то вы не владеете основами, базовым функционалом! И мотивируя собственное невежество мифическими скиллами в Qt вы тем самым опускаете уровень людей, периодически использующих данную библиотеку (я вхожу в это подмножество). То есть, ответьте для себя на вопрос: вы знаете, что c какой-то версии г++ периодически жалуется, что строковые константы больше не чар со звездой? Что std::string способен хранить нули? Если не знали, то не дописывайтесь полгода. Нам не нужно ваше мнение.Теперь про строки. Исторически Qt это повтор Xt для C++, люди копировали функционал Мотифа, типа: в мотифе свои строки? и у нас свои будут. Дело в том, что мотиф, как базовая библиотека на базе Xt, создавался во времена, когда С++ вообще не было, Xt реализовывало ООП на сях, передачей указателей на структуры (объекты гуи). Думаю, что потом ни у кого в тролтехе духу не хватило сказать, что труд сегодняшних тимлидеров необходимо объявить устаревшим, такое вполне возможно, так бывает. Уверен, что в курилках у них эта тема не раз обсуждалась, с характерными улыбками и адресным юморком.
>> то есть, разработчики, по сути, хотят (предполагают) создать болото, в котором другие
>> разработчики будут увязать по самое горло (если не макушку)
> Без комментариев, бредятина.
> Не помню где, слышал одно высказывание, общий смысл которого такой: "Что бы
> ты не делал, как бы не старался, всегда будет небольшая горстка
> людей, которая будет вечно чем-то недовольна. Так вот, насри на их
> мнение."это были мои мысли вслух, я ни на что не претендовал
P.S. накакайте на мое мнение - докажите мне лично мою правоту
> P.S. накакайте на мое мнение - докажите мне лично мою правотуРожа не треснет? Сиди дальше и думай что прав.
Если требуешь доказательств правоты, для начала потрудись написать что-то внятное, а не расплывчатые формулировки про болото.
>"Что бы ты не делал, как бы не старался, всегда будет небольшая горстка людей, которая будет вечно чем-то недовольна. Так вот, насри на их мнение."Это про разработчиков KDE скорее. Им не нравится, как устроена Qt. Наваяли в KDE, значит, какого-то неподъемного монстра, а теперь еще хотят, чтобы другие его пилили. Кто такий вообще этот KDE? Почему он такой особенный, что его библиотеки надо включать в Qt? Делаете свою DE так и делайте тихо и никого не трогайте.
Если они и будут это делать, то главное чтобы не воткнули в QtGui. Пусть будет себе в QtGuiExtended каком-нибудь.
Думаю что разработчики Qt и Nokia будут не в восторге от перспектив разбирать чужие глюки :)
не, ну с такой логикой проще уж в QT интегрировать ядро, иксы и чего-нить ещё.
а что? пусть увеличивается число вовлечённых в разработку :)
Более идиотского высказывания я еще не слышал. Речь идет о совместной работе.
оу, я вижу, с Вами без тэгов [шутка][/шутка] общаться нельзя. печально, печально :)
просто ужос! если Qt еще терпимо держать в системе, то тянуть over 400Mb дерма как-то уж слишком. Лично мне будет проще отказаться от smplayer чем иметь этого монстра в системе.
> просто ужос! если Qt еще терпимо держать в системе, то тянуть over
> 400Mb дерма как-то уж слишком. Лично мне будет проще отказаться от
> smplayer чем иметь этого монстра в системе.Кто вас заставляет что-то тянуть? Ясно же написано: "В настоящее время библиотеки KDE уже содержат необходимый набор дополнительных классов и их интеграция с Qt позволила бы компании Nokia избавить себя от дублирования уже выполненной работы."
Это просто обмен наработками. Уже думаете о том, как вас пытают паяльником, заставляя, выкачивая qt, качать и KDE? Паранойя.
Как я понимаю речь идет об объединении кодовой базы, результирующий размер, я думаю будет намного больше текущего Qt и возможно меньше текущего kdelibs
да:)
>то тянуть over 400Mb дерма как-то уж слишком.и это "объединение кодовой базы" даст те самые лишние 400мб? Замечательно ...
вы вообще представляете, что речь идёт о KDElibs, а не о KDE?
У меня kdelibs занимает 14 мегабайтов.
Если Qt будет модульный как заявлено в http://www.opennet.me/opennews/art.shtml?num=28425 то нет ничего плохого, чтобы те же kdelibs, kdepim были под крылом нокии
Псих... KDE4 уже умер по факту, а он хочет теперь уничтожить Qt...
По какому "факту"? Где этот "факт" зафиксирован? :)))
На моем десктопе зафиксирована смерть KDE4, пульса нет.
ммм. значит, судя по Вашему десктопу и так называемый "вЕндекапец" наступил уже, наверное? :)
> ммм. значит, судя по Вашему десктопу и так называемый "вЕндекапец" наступил уже, наверное? :)Фактически да. Почему меня должно волновать что у Васи из 3-го "Б" стоит windows 7? У меня Ubuntu и все вопросы / программы / задачи крутятся вокруг этой ОС.
ваш десктоп все-таки оказался пупком земли?
Думаю для него его десктоп как-раз пуп земли.
И это правильно.
ПС. А КДЕ-девелоперов собственно считаю полудурками, которые слишком фривольно к ресурсам машины относятся и счтитаеют, что это норма...
у меня ArchLinux + KDE.
на моём скромном конфиге всё летает. последний раз когда смотрел - запущенная ОС с KDE + Ktorrent+ KSysguard + Dropbox занимала 180-200 мб памяти.
функционально и быстро.
конечно, не быстрее LXDE, но ждать не приходится :)ах да, половину пакетов KDE с всякими органайзерами, мэйлом и т.д. удалил. ещё б побольше удалил - да зависимости (странные). но я не всё знаю, не всё понимаю - так что не берусь судить. на скорости работы не сказывается, места много не ест.
Угу, в свое время кторент у меня хавал 20-30% ядра CPU отгружая какие-то жалкие 500 кб/сек, вызывая раскрутку вентиля на проце почем зря, чем и не понравился. В итоге поюзал мелкий transmission. Он в той же ситуации жрет ажно ~1-2% все того же проца. Такая вот разница.
Да пусть себе летает.
У нас видимо задачи разные и количество софта работающего единомоментно не сопоставимо.
Так что ресурсы критичная статья..
А я считаю полудурками людей которые ставят кубунту в виртуалку, а потом оруг что КДЕ - УГ.
ну это для него, а не для других. или другие обязаны по кому-то там равняться? или ныть, как это делают другие?
> ваш десктоп все-таки оказался пупком земли?он, конечно же, ошибся, пуп земли это моя гента.
По теме: неистово плюсую всем, кого забавляет велосипедизм qt/kde, начиная от строк, заканчивая контейнерами.
почитайте офф документацию тролей: там описано, почему они написали свои версии контейнеров, чего полезного туда добавили, что интересного реализовали, на сколько это было лучше чем стл.. что так же относится к строкам и остальным Q* классам, но пожалуйста, не осуждайте, не разобравшись
вот именно. в конце концов, никто не запрещает использовать наработки из stl
да, конечно можно использовать, но давайте немного детальнее: stl предоставляет обычный сишный потход к итераторам, а Qt предлагает как его, так и ява стиль итераторов, какой использовать - вам выбирать. Если я не ошибаюсь, первоначально эти _наработки_ из стл были медленнее, что и послужило одим из поводов к написанию Qt'шных.
> почитайте офф документацию тролей: там описано, почему они написали свои версии контейнеров,
> чего полезного туда добавили, что интересного реализовали, на сколько это было
> лучше чем стл.. что так же относится к строкам и остальным
> Q* классам, но пожалуйста, не осуждайте, не разобравшисьНу да - но это справеливо по отношению к тогдашним плюсам. Сейчас многое из этого смотрится как откровенные велосипеды.
смотрите http://www.opennet.me/openforum/vsluhforumID3/71929.html#78
"Явашный интерфейс" - повод повелосипедить?
ну вы можете пользоваться стандартными контейнерами, никто вам не запрешает; а так же, можно сказать, что "велосипедят" не тролтеховцы, а те кто, вместо использования наработок из Qt писали свои классы; почитайте вот это http://doc.qt.nokia.com/4.7/containers.html
Так-же перешел c KDE на XFCE.
Слишком жадная и тормозная софтина получилась...
>пульса нетэто была смерть PulseAudio, а не KDE
Правильно! Загубили в 4-й версии KDE, за 5 релизов не починили, и хотят спихнуть это другому проекту, как спихнули Phonon в версии 4.3! Или Phonon отдали как раз после того как он стал стабилен? Не следил...
хватит извращать, какое спихнули? тролтеховцам понравилась библиотека и они её включили в Qt
По-моему отличная идея, если KDE программы будут зависеть только от Qt то можно будет пользоваться любимыми программами на любой ОС без установки всяких вечно недоделанных костылей. Если идею примут буду с нетерпением ждать Qt5 и KDE5.
Вообще-то проблема KDE-зависимых программ в том, что они слишком много тащат и слишком нагружают систему. И будут зависимости называться kdelibs, или войдут в Qt, неважно. Впрочем, Нокия на такую чушь вряд ли пойдёт - ей на смартфонах нужна платформа вменяемого размера, да и, кажется, там понимают, что общая база - это одно, а окружения на десктопе, нетбуке и коммуникаторе должны быть принципиально разными.
> ей на смартфонах нужна платформа вменяемого размераА что у вас там за "вменяемый размер"??? 20см.? :)))
После того как мы не смогли купить на рынке нужную нам флэш меньше 2G, мы забили на ембедет сборку, и переходим на обычный linux. а было время, когда и в 512 впихивались, чтоб сэкономить баксы.
>> ей на смартфонах нужна платформа вменяемого размера
> А что у вас там за "вменяемый размер"??? 20см.? :)))
> После того как мы не смогли купить на рынке нужную нам флэш
> меньше 2G, мы забили на ембедет сборку, и переходим на обычный
> linux. а было время, когда и в 512 впихивались, чтоб сэкономить
> баксы.Сами с большим трудом находим гигабайтные CF - но таки находим хотя линукс - да, почти обычный. Но у нас девайс не мобильный :-)
А вот насчёт "вменяемого размера" - напоминаю, что всё это должно уместиться не только на диске, но и в памяти, которая имеет привычку потреблять электроэнергию. О cache locality, опять же, могу напомнить, как и о том, что на большее количество кода будет больше накладных расходов - от relocations до затрат энергии/времени на подгрузку с карты. Так что здесь увеличение размера напрямую ведёт к удорожанию конструкции. Ну и для Nokia не проблема заказать хоть на 16M флешки, и им это будет таки дешевле, чем большего размера.
Использую Qt на Windows.
Мне нафиг там не нужны кделибз.
И на маке тоже не нужны. И на фрибзде тоже...
>может привести к гибели KDE как десктопа.громкие слова - не более.
>>может привести к гибели KDE как десктопа.
> громкие слова - не более.Скорее к гибели Qt
падающие кедолибы будут в qt и он рипнется.
Интересный поворот событий.
А что, туда добавят akonadi и полную зависимость от mysql? Тогда точно придётся искать что-то другое иди валить на gtk.
> А что, туда добавят akonadi и полную зависимость от mysql? Тогда точно
> придётся искать что-то другое иди валить на gtk.akonadi и иже с ним суть отдельные проекты. Хоть вопрос поизучайте сначала....
Почему бы разработчикам KDE не следить за всеми новыми функциями, класами из Qt. И если эти классы дублируют классы KDE тогда использовать классы Qt. Не плодить, без оглядки, дублирующие сущности в своем проекте, а заменить на Qt-шные с аналогичным, похожим функционалом, и поддерживать все это в актуальном состоянии. Проблема из-за чего возникла? Как избыточные функции появились? Кто добавил? Qt первична. KDE - вторично. Глядиш и не нужен будет мегапроект (Титаник) KDE-QT.
Это вопрос курицы и яйца. Самый-то первый код, сто раз переписанный, безусловно Qt. Но в KDE потом столько подописывали (чего не было в тогдашнем Qt)... И немало вернулось обратно в Qt. От всяких мелочей (вроде бы даже панель инструментов в Qt не было), до фонона и вебкита. Из KDE как раз потом то, чему появилась замена в Qt, постепенно выкидывалось.Поэтому дублируют как раз в Qt -- те вещи, которые появились в KDE потому, что в Qt их не было. И это понятно, иначе на голом Qt никто бы не писал, все бы пользовались плюшками KDE.
Вот пусть теперь в кде и выкидывают свои дублирующие функции/классы и юзают стандартные qt'шные. "Переписывание с нуля" - это и так их стандартный метод разработки.
Так и делают. С первой версии много чего выкинули. Но ведь и Qt не стоит на месте, постоянно добавляют новые фичи, уже реализованные в KDE.
Существует принцып разумной достаточности.
Qt кросс-платформенный фраймверк.
А не костыль к КДЕ...
Вообще понятно почему линь колышется в 1% на десктопах - потому что некоторые разрабы учитывают только свое мнение...
Наоборот, kdelibs -- костыль к Qt (где тому не хватает ног). Но со временем Qt обзаводится собственными костылями и часть kdelibs оказывается лишней.
>в конечном итоге приведет по сути к возникновению Qt 5 и KDE 5.А потом будет очередной виток KDE 5.x != KDE 5. Заодно в это глюкалово вовлекут и Qt.
Выгода для KDE понятна: не надо будет подключать дополнительные библиотеки, всё необходимое будет в Qt. А вот какая выгода будет для Qt? Насколько KDE сможет расширить Qt? насколько всё это будет стабильным и производительным?
Извините что влажу, сам я пользуюсь гномом (который уже похоронили и уже надгробный памятник которому обосрали все кдеешники, но тем не менее я его менять не буду пока его будут поддерживать) - раз кде стали закапывать туда-же - какой же оконный менеджер сейчас самый модный и подающий нам надежды?
а причем здесь оконные менеджеры, а?
> а причем здесь оконные менеджеры, а?Притом что KDE и GNOME
> и падающийfixed
Только не это! GNOME-окружение, KDE-окружение вместе соржут все ресурсы компа.
И так приходитсься смиритсься , что постоянно в оп. памяти торчат
две ,дублирующие друг-друга библиотеки. Так теперь будут торчтать два ненужных
окружения( не дай бог "тесную интеграцию" GNOMEа с GTK).
Тeперь надежда только на Freedesktop.
Так в чём проблема? GNOME тоже перевести на тот новый Qt5. И не надо будет в памяти держать _два_ окружения.
>Тeперь надежда только на Freedesktop.Уха-ха-ха-ха... Надежда на Freedesktop?!! Вы это серьёзно? Это же главный центр подрывной деятельности идей Unix'а.
Собственно поясните что такого полезного в кделибз для мира?
Хм... Т.е. сейчас KDE'либы используют ещё не все, а надо, чтобы все?
Новость выглядит настолько провокационной и бредовой, что стало ясно, придётся смотреть первоисточники, чтобы понять, об чём вообще речь.Один новичок (китаец или индус) спрашивает -- а нафига вообще kdelibs? Почему бы не писать на чистом Qt?
Ему отвечают -- Qt хорошо, но нам не хватает в нём многих полезных и удобных вещей, прежде всего связанных с интеграцией. Вот kdelibs и содержит эти плюшки. Например:
* Хорошо локализированный календарь.
* Куча новых опций форматирования.
* Хорошая работа с часовыми поясами.
* Лучший в мире диалог выбора файлов.
* Дополнительные фичи к диалогу печати.
* Библиотека для преобразования единиц измерения (мили в километры).
* Прозрачные сетевые файловые операции с KIO.
* Куча всего связанного с семантикой.
* Виджеты для интеграции всего этого
* Беспрецедентная библиотека для работы с национальными праздниками.
И многое, многое другое.Но есть и ложка дёгтя. Появляются дубликаты. KHTML/KJS <-> QtWebKit, Phonon <-> QtMultimedia, Solid + Akonadi + kdepimlibs <-> QtMobility (замечу, что аналоги в KDE появились раньше, чем в Qt, иначе незачем было бы в KDE что-то своё придумывать). Плохо то, что они несовместимы. Приложению приходится выбирать, использовать один инструмент, или другой, или оба, разбухая при этом.
И вопрос -- что же делать, чтобы kdelibs оставался набором дополнительных удобных примочек, и не отягощал разработчиков лишним кодом?
Вот на этот вопрос и отвечает Корнелиус Шумахер. Я бы понял его ответ так -- ничего сделать нельзя, если не рассматривать совершенно безумный вариант, что в Qt включат kdelibs (а не какие-то несовместимые велосипеды) и станут развивать совместно.
> QtMultimedia, Solid + Akonadi + kdepimlibs <-> QtMobility (замечу, что аналоги
> в KDE появились раньше, чем в Qt,Если все эти аконади, kdepimlibs и прочую бнопню впихать в МОБИЛЬНЫЙ ДЕВАЙС, там вообще ресурсов ни на что другое не останется, и батарейка за 2 часа убьется нафиг. Нокия по крайней мере в силу своих целей старается кодить свои фичи с оглядкой на потребление ресурсов. Т.е. компактно, аккуратно, не хавая проц и память лишний раз и фича добавляется только если ей видно какое-то реальное применение. А не "чтоб было". А вот KDE этим ни разу не страдает - наворачивают что попало, с поводом и без. Чем изрядно подзадолбали.
>> QtMultimedia, Solid + Akonadi + kdepimlibs <-> QtMobility (замечу, что аналоги
>> в KDE появились раньше, чем в Qt,
> Если все эти аконади, kdepimlibs и прочую бнопню впихать в МОБИЛЬНЫЙ ДЕВАЙС,
> там вообще ресурсов ни на что другое не останется, и батарейка
> за 2 часа убьется нафиг. Нокия по крайней мере в силу
> своих целей старается кодить свои фичи с оглядкой на потребление ресурсов.
> Т.е. компактно, аккуратно, не хавая проц и память лишний раз и
> фича добавляется только если ей видно какое-то реальное применение. А не
> "чтоб было". А вот KDE этим ни разу не страдает -
> наворачивают что попало, с поводом и без. Чем изрядно подзадолбали.Ага. То есть Nokia лично для тебя — авторитет в последней инстанции, а на всех остальных производителей девайсов (буде такие найдутся) с MeeGo наплевать? А где комитет по стандартизации фич? Нету и только Nokia решает, что нужно, а что не нужно на мобильном девайсе. Уныло.
Помнится, ты против Java ME в том виде, в котором оно существует. Но, к примеру, стандартная фича, а не какая-то там "своя фича" от какой-то Nokia, в Java ME определяется чётким JSR-<номер такой-то>. Фича либо реализуется, либо не реализуется — в зависимости от аппаратного обеспечения и маркетинговых взглядов производителей девайсов. Система JSR — это СТАНДАРТ, независимая от поставщика декларация публичного API. Если производитель взялся реализовать (имплементировать) конкретный JSR, то должен исходить из принципов полной совместимости своей реализации API с опубликованным JSR.
Подытожу. Нет, не видать независомости MeeGo и Qt4 от "чьего-то" хотения левой пятки ноги.
>> QtMultimedia, Solid + Akonadi + kdepimlibs <-> QtMobility (замечу, что аналоги
>> в KDE появились раньше, чем в Qt,
> Если все эти аконади, kdepimlibs и прочую бнопню впихать в МОБИЛЬНЫЙ ДЕВАЙС,
> там вообще ресурсов ни на что другое не останетсяБудет Qt просто собираться без этих фич, вот и всё. Или вы знатный специалист по Qt, чтобы так авторитетно говорить об этом?
>[оверквотинг удален]
> в KDE появились раньше, чем в Qt, иначе незачем было бы
> в KDE что-то своё придумывать). Плохо то, что они несовместимы. Приложению
> приходится выбирать, использовать один инструмент, или другой, или оба, разбухая при
> этом.
> И вопрос -- что же делать, чтобы kdelibs оставался набором дополнительных удобных
> примочек, и не отягощал разработчиков лишним кодом?
> Вот на этот вопрос и отвечает Корнелиус Шумахер. Я бы понял его
> ответ так -- ничего сделать нельзя, если не рассматривать совершенно безумный
> вариант, что в Qt включат kdelibs (а не какие-то несовместимые велосипеды)
> и станут развивать совместно.Ну так по уму - надо понемного депрекейтить свои фичи в пользу Qt-шных, интересное вроде работы с часовыми поясами и календаря тянуть в апстрим, часть выделять в отдельные библиотеки, не привязынне ни к Qt, ни к KDE (как KIO то же)... Хотя, понятно, ни у кого руки до этого не дойдут.
Ну они так и делают. Но работы так много, что чтобы довести аналоги в Qt до ума и заменить ими в KDE -- как раз и получится Qt 5 и KDE 5.
Хоть я и гномосек, идея мне нравится. Но не думаю, что Nokia одобрит это, ибо ей сначала нужно телефоны до ума доводить, а уж потом брать на душу такой геморрой. Это же лишние расходы. И очень крупные, раз фирма скандинавская.
Наоборот идея имхо отличная. Тогда можно будет проги из пакета kde использовать в винде не таща весь kde за собой. Когда код объединят - все велосипеды уберут и код имхо и полегче и получше будет. Я только за, жду с нетерпением qt5 и kde5 (и не надо про стабильность, 4я ветка уже вполне стабильна, так что если что и на 4й можно будет посидеть подождать)
> Наоборот идея имхо отличная. Тогда можно будет проги из пакета kde использовать
> в винде не таща весь kde за собой. Когда код объединят
> - все велосипеды уберут и код имхо и полегче и получше
> будет. Я только за, жду с нетерпением qt5 и kde5 (и
> не надо про стабильность, 4я ветка уже вполне стабильна, так что
> если что и на 4й можно будет посидеть подождать)Как вы уже надоели со своей виндой.
Slackware-юзеры, возможно, это оценят...
Нехватало ещё это дурацкий akonadi туда всунуть с их тупейшей схемой хранения данных. Хватит того что kde им споганили, не хватало ещё споганить последний оствшийся нормальный тулкит.
Ничего плохого в объединении не вижу... Только плюсы от этого начинания. Уже объявили что Qt будет модульной, поэтому ничего не должно мешать не использовать дополнительные kde-ные либы тем кто не хочет этого делать.
Главное что бы координатор проекта оказался грамотным в этом вопросе.p.s. Новость кажется прощупыванием Нокией почвы для привлечения большего количества разработчиков для своих проектов.
Гениальная идея, я полностью согласен с разработчиком Амарок!
Надеюсь Nokia этого не сделает, КДЕшникам веры нет...
Потом они очередной велик придумают, и будут пытаться опять в Qt её ввести?
Или опять начнут переписывать её в 10 раз?
на labs.qt.nokia.com тролли уже разъясняли чем плох Phonon, и что они его бы заменили своим чем-нибудь, но пока нечем, и зачем придумали QtMultimedia.Но для Nokia итак времена тяжёлые, играть в доброго дядю она вряд ли будет, а тянуть левый для неё проект (теперь им реклама Qt не нужна) не станет, так как десктоп для неё побочная ветвь эволюции :).
За Qt я спокоен, думаю Nokia сейчас по маркетинговски ответит, "как бы это было замечательно, и круто, но пока нет возможности, приходите послезавтра, а лучше через месяц"...и продинамят КДЕ разгильдяев.
Этот просто перец хочет себе тёплое местечко получить в Nokia.
Сейго тоже тролли 2 года кормили, а он нихера там не делал, когда только выгнали его, начал свою плазму активнее пилить...
>пульса нетПульс есть и работает: openSUSE 11.2, kde 4.4. Firewire-интерфейс ECHO Audiofire 4->ffado->jack->pulseaudio, phonon для системных звуков. Что я делаю не так?