KDE ждёт быстрая смерть?

>прочие "черти в ступе" появится где? Не "в твоей личной версии gtk" случайно? ;)

зачем. они появятся в плагине к гтк.

>VoIP на Qt? жжоте ребята.

Ага, и в кодеках классы наследуем от QObject =)

>я понял. Qt - оно для разработчиков с низким уровнем IQ. Этакая кросплатформенная дельфя.

А бинарные дистры - они для линуксоидов с низким IQ? Этакая Винда на Linux-ядре, ага?

Где тот анонимус, который писал баян про "Windows для настоящих мужчин, настоящие мужчины не боятся трудностей, а героически их преодолевают"....

>Qt - вещь в себе. Всё. Шаг влево/вправа и попытка улететь караются немедленно.

Бред. Хочешь STL --- юзай STL. Хочешь ACE --- юзай ACE. Хочешь всё тот же libxml2 --- да на здоровье! Какие ещё тебе "шаги в сторону" нужны? Я и libmpd юзал, и libgloox, и какого только чёрта в ступе не юзал --- до сих пор никто не покарал почему-то :)

>А бинарные дистры - они для линуксоидов с низким IQ? Этакая Винда на Linux-ядре, ага?

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

>Какие ещё тебе "шаги в сторону" нужны?

я же написал =)

>Я и libmpd юзал, и libgloox, и какого только чёрта в ступе не юзал --- до сих пор никто не покарал почему-то :)

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

> http://lorquotes.ru/view-quote.php?id=3354

> P.S.: лопата %)

Т.е. всё-таки никак? :)

>кривая аналогия. Тебе же не приходится пересобирать линупс для того, чтобы он поддерживал нужные девайсы. В крайнем случае - собираешь модуль и всё.

К чему была твоя фраза про "низкий IQ"? Что кто-то "асиливает" трах с полудесятком либ, а кто-то вроде как "ниасиливает" и поэтому выбирает Qt? Аналогия была в том, что кто-то банально _не_хочет_ постороннего траха (как в случае с бинарными дистрами).

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

Я-то не путаю, я таким образом обращаю твоё внимание, что если ты хочешь нормально дискутировать, то конкретизируй претензии и не используй общие фразы типа "вещь в себе", "монолитный нерасширяемый комбайн" и так далее.

Кстати о комбайнах.... Комбайны (которые машины :)), знаешь ли, в определённых случаях бывают очень полезны ;)

Хотя по-твоему это наверно получится агрегат для лузеров с низким IQ, которые не осилили связку "косилка-молотилка-веялка-соломопресс".... %)

>К чему была твоя фраза про "низкий IQ"? Что кто-то "асиливает" трах с полудесятком либ, а кто-то вроде как "ниасиливает" и поэтому выбирает Qt?

в том что кто-то предпочитает универсальность эффективности. То что универсальный инструмент практически всегда менее эффективен специализированного - надо рассказывать?

за универсальность всегда приходится платить

>Я-то не путаю, я таким образом обращаю твоё внимание, что если ты хочешь нормально дискутировать, то конкретизируй претензии и не используй общие фразы типа "вещь в себе", "монолитный нерасширяемый комбайн" и так далее.

так я конкретизировал. Меня стали убеждать, что это не нужно и поэтому в Qt этого нет. И при этом продолжили верещать про "самый лучший тулкит". Причем кричат в основном программисты почему-то =)

Про вещь в себе я уже много раз говорил. Вообще, родовые травмы Qt растут из плюсов =) В смысле взаимодействия с другими платформами почти ничем не лучше жабы. Это видно на примере той же жабы и Jambi - оболочки для классов, врапперы для сигналов - чтобы это всё работало через JNI. Хотя этот вариант лучше смешных биндингов KDE<->Java через "скрытое окно" =)

>Кстати о комбайнах.... Комбайны (которые машины :)), знаешь ли, в определённых случаях бывают очень полезны ;)

ну это да. Правда в очень узкоспециализированных случаях

>Хотя по-твоему это наверно получится агрегат для лузеров с низким IQ, которые не осилили связку "косилка-молотилка-веялка-соломопресс".... %)

комбайны для лузеров, работать должны роботы.

>>find-as-you-type

что, опять ?

>что, опять ?

ага. файловый диалог qtconfig-qt3 - никакого find-as-you-type

надо qt2 ставить, там есть? =)

>> То что универсальный инструмент практически всегда менее эффективен специализированного

такой как Qt - практически всегда более эффективен

>такой как Qt - практически всегда более эффективен

только "этого нельзя, этого нельзя, и этого тоже нельзя"

область покажешь, в какой Qt более эффективен? =)

> Кстати о комбайнах.... Комбайны (которые машины :)), знаешь ли, в определённых случаях бывают очень полезны ;)

> Хотя по-твоему это наверно получится агрегат для лузеров с низким IQ, которые не осилили связку "косилка-молотилка-веялка-соломопресс".... %)

http://mx.esc.ru/~assur/ocr/mushole/mushole.htm

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

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

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

>в gtk-виджетах типа TreeView есть find-as-you-type.

Открываешь диалог qt4/kde, начинаешь набирать имя в поле ввода и появляется выпадающий список с вариантами завершения. Find-as-you-type не нужен.

Кстати, как там в гткашных диалогах с multicolumn view?

>в том что кто-то предпочитает универсальность эффективности. То что универсальный инструмент практически всегда менее эффективен специализированного - надо рассказывать?

Связка "косилка-молотилка-веялка" эффективнее комбайна? :)

>Меня стали убеждать, что это не нужно и поэтому в Qt этого нет. И при этом продолжили верещать про "самый лучший тулкит". Причем кричат в основном программисты почему-то =)

Логично вообще-то. Программист смотрит со своей стороны. Со стороны _своей_ программы. А "заменить стандартный диалог чтобы везде поменялся" --- это точка зрения не программиста ;)

>Открываешь диалог qt4/kde, начинаешь набирать имя в поле ввода и появляется выпадающий список с вариантами завершения.

лишний клик после перехода в нужную диру, иначе фокуса в поле ввода нет

>Find-as-you-type не нужен.

как я мог забыть. Не нужен

>Кстати, как там в гткашных диалогах с multicolumn view?

никак. Но ты волен написать плагинчег, если жить без этого не можешь :)

>Связка "косилка-молотилка-веялка" эффективнее комбайна? :)

ога. из нескольких комплектов можно организовать высоконадежный кластер. А комбайн если сдохнет - то весь :)

>Логично вообще-то.

ясен пень логично. Но только с точки зрения автора какой-либо поделки. Ессно, хочется чтобы попроще и мозг не перенапрячь - тут Qt и вылезает. А ещё риальные поцаны во дворе сказали, что сиплусплус - это круто!

бгг

>А "заменить стандартный диалог чтобы везде поменялся" --- это точка зрения не программиста ;)

немного не так. "чтобы файловый диалог везде был одинаковый" - это чья точка зрения? ;)

>немного не так. "чтобы файловый диалог везде был одинаковый" - это чья точка зрения? ;)

Везде --- это где? В моей программе он и так будет везде одинаковый :)

А "везде во всех программах у меня на кампутере" --- точка зрения юзера, кого же ешё? У кого ещё на компутере программы всякие разные? Не у программиста же. У программиста гуёвая программа должна быть одна --- текстовый редактор. Или вообще ни одной. А в одной программе диалог всегда одинаковый :)

>из нескольких комплектов можно организовать высоконадежный кластер. А комбайн если сдохнет - то весь :)

Что-то не видел я высоконадёжнык кластеров из косилок.... Даже не смотря на то, что сдохшие комбайны --- приходилось. Вод ведь какая штука: комбайны ломаются --- но их всё равно продолжают юзать, глупыши неразумные :)

>Везде --- это где? В моей программе он и так будет везде одинаковый :)

в DE, разумеется

>А "везде во всех программах у меня на кампутере" --- точка зрения юзера, кого же ешё?

ты феноменально догадлив. Наконец-то портировал libastral.so на плюсы? =)

сделай ещё один шаг - угадай, _для_ _кого_ пишутся программы

>Что-то не видел я высоконадёжнык кластеров из косилок...

а я видел =) При выходе из строя шести косилок из десяти - четыре всё-таки продолжают работать, а сломанные идут на зопчасти =)

>од ведь какая штука: комбайны ломаются --- но их всё равно продолжают юзать, глупыши неразумные :)

на гужевой тяге шоле?

пока ты свой кластер соберёшь, я уже всю пшеницу сожну и пойду водку пьянствовать =)

>пока ты свой кластер соберёшь, я уже всю пшеницу сожну и пойду водку пьянствовать =)

вот. Qt и алкоголизм идут рука об руку!

>лишний клик после перехода в нужную диру, иначе фокуса в поле ввода нет

Только при юзании закладок или хроническом "мышевозильстве".

>в DE, разумеется

В КДЕ у всех кде-шных программ диалог одинаковый ;) У сторонних программ --- другой. У Qt-программ, запущенных в Гноме (как и у Gtk-программ, запущенных в КДЕ), диалог отличается от стандартного ДЕ-шного.

Возвращаясь к уже сказанному: да, КДЕшный отличается от Qt-ного, а в Гноме юзается стандартный Gtk-шный. Но уж лучше бы они его переписали, ей-Б-гу :)

P.S.: да, я согласен, что filedialog в отдельной либе --- это правильно и удобно ;)

>сделай ещё один шаг - угадай, _для_ _кого_ пишутся программы

Вот именно _для_него_самого_ и был заменён Qt-шный диалог на КДЕшный ещё в лохматые времена ;) И именно _для_него_же_ давно стоило бы переписать Gtk-шный, но низя, панимаишь, юзер испугается что у него так много всего и фрустрирует :)

>а я видел =) При выходе из строя шести косилок из десяти - четыре всё-таки продолжают работать, а сломанные идут на зопчасти =)

Ты вообще неправильно аналогию проводишь. Косилки умеют только косить, а комбайн на выходе выдаёт готовое зерно. Соберёшь связку "косилка-молотилка-веялка" --- будет работать, на выходе будет всё то же зерно. Но при выходе из строя хотя бы одного звена у тебя всё так же стопорится ВСЯ работа, как и при выходе из строя комбайна. Плюс гемор с заправкой и обслуживанием ТРЁХ агрегатова вместо одного ;)

>вот. Qt и алкоголизм идут рука об руку!

Во!!! Тут не могу не согласица, по себе знаю ;-)

>В КДЕ у всех кде-шных программ диалог одинаковый ;) У сторонних программ --- другой. У Qt-программ, запущенных в Гноме (как и у Gtk-программ, запущенных в КДЕ), диалог отличается от стандартного ДЕ-шного.

В гноме у всех гномовских и гткшных программ диалог одинаковый. Разницу видишь? Вот тебе архитектурное преимущество gtk, позволяющее сделать более консистентный десктоп, не требуя привязки программ к GNOME.

В отличие от

>Вот именно _для_него_самого_ и был заменён Qt-шный диалог на КДЕшный ещё в лохматые времена ;)

да ну? Заменен? звездишь. Смотрю qtconfig -нифига не кдешный. Опера - нифига не кдешный. Хотя базовый тулкит вроде тот же, что и в kde

или надо все переписать под кде, чтобы? Окуенное решение. Очень по кдешному.

>Но при выходе из строя хотя бы одного звена у тебя всё так же стопорится ВСЯ работа

да нихрена. Оставшиеся продолжают работать, и их всегда можно перекинуть на другой фронт работ =)

>Только при юзании закладок или хроническом "мышевозильстве".

ты уверен, что все файлы должны лежать исключительно в ~?

>> А мне нужен _полный_ уровень интеграции.

> полный - это какой? Чем xembed не устраивает?

Полный: это когда я юниксвейно могу запустить из скрипта "file-open-dialog --dir=/media/porn --extlist=jpg,gif,png --title 'Open porn' " и получить в stdout имена картинок. Но это не совсем относится к embed.

Для ембеддинга: потом я вызываю "image-viewer --embed my-window-id" и получаю imagemagick, kuickshow или ещё что-то, встроенное в указанное окошко.

>> Ой, а что, а гноме и гтк диалоги тоже разные? ;)

> вообще-то да. Если гтк-приложения пускать вне гнома - будут родные гткшные. В гноме - будут гномовскими. Ы?

Ааа, понятно.

>> Ну ты ж сам уже ответил: как минимум QSignalMapper. Ну или шаблонами навесить в стиле STL какой угодно объект с функцией operator().

> это не замыкания будут. =)

Это будет стандартный метод реализации чего-то, похожего на замыкание(на уровне языка ни в C, ни в C++ их нет). Такой, как это делается в STL.(см. std::foreach)

> а с функцией operator() ты вообще прогнал - это может быть и прокатит, если замыкание делать на этапе компиляции (и то меня терзают сомнения). А если оно динамически вешаться будет?

Нет, гика, ты просто не знаешь C++.

> fuse,libcurl

Они никоим образом к glib не привязаны(слава Патрику :)). А то, что они не использованы ни в kio, ни в gnomevfs/gio -- это действительно проблема обоих велосипедов.

> В случае с Qt мы имеем _унифицированный_ тулкит, все средства которого можно использовать хоть в гуе, хоть в сетевой части, хоть в БД-логике.

Кстати, вся унифицированность -- наличие велосипедов. Например, QString, QList и QMap в то время, когда есть std::list и std::map. В справке читал, что это сделано для тех платформ(компиляторов), где нет STL. Но покажите мне компилятор без stl!

А вот со строками вообще плохо. Я ещё не видел _ни одного_ тулкита, где с ними хорошо(т.е. используется std::(w)string вместо QString/Glib::ustring/чего-то ещё).

> при том, что если тебе нужна кросплатформенность - то тут жабе альтернатив собсно и нет.

Tcl.

>> Ага, а libxml2 ещё лучше чем Qt, потому что просто библиотека для XML

> для работы с xml - лучше, да. Именно поэтому в KDE её и используют, потому что в Qt недоложили =)

Кстати, xml-парсер в qt реализован высокоуровненно и, следовательно, удобно. Я вот не осилил libxml2 для простенького парсинга.

>> P.S.: Да, кстати, мне правда интересно: приведи пример, когда реально нужно повесить замыкание на сигнал.

> когда программу хочется сделать скриптуемой. И когда скрипт должен иметь доступ к объектам/виджетам.

Тут просто не надо использовать компилируемые языки. В tcl/tk всё это есть искаропки :)

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

Хороший костыль привёл в пример, кошерный :) Dbus -- начнём с того, что он нарушает правило "универсальный формат данных -- текстовый поток". Ну а в остальном описанное реализуется легче всего на интерпретируемом языке.

> зы: и "реальный пример" - это такая жалкая попытка перефразириовать "это не нужно" ? =)

Повторяю: тут не нужен компилируемый язык.

> find-as-you-type. замыкания. нельзя.

4.2 + 4.2 == 8.4 :)

> В гноме у всех гномовских и гткшных программ диалог одинаковый. Разницу видишь? Вот тебе архитектурное преимущество gtk, позволяющее сделать более консистентный десктоп, не требуя привязки программ к GNOME.

Архитектурно правильное решение -- не использовать программы не написанные на gtk? Вещь в себе.

>ты уверен, что все файлы должны лежать исключительно в ~?

Открываю диалог кде3, ввожу "/e<down>fs<down><enter>" и у меня открывается /etc/fstab, в qt4 почти тоже самое. Сюрприз?

>Полный: это когда я юниксвейно могу запустить из скрипта "file-open-dialog --dir=/media/porn --extlist=jpg,gif,png --title 'Open porn' " и получить в stdout имена картинок. Но это не совсем относится к embed.

zenity --file-selection

>Для ембеддинга: потом я вызываю "image-viewer --embed my-window-id" и получаю imagemagick, kuickshow или ещё что-то, встроенное в указанное окошко.

вариант А (через жопу): Xnest --parent && опция --display= в гтк-приложениях.

вариант Б (идеологически верный) Можно написать модуль гтк, который будет обрабатывать твой --embed (некоторые гтк-аппликухи имеют подобный ключик, например --socketid в gvim

вариант В:

http://www.cixar.com/~segphault/blog/res/programming/ruby/xembed/xembed.png

расписано тут:

http://cixar.com/~segphault/blog/entry/programming/ruby/xembed.blog

к сожалению, похоже что либа для руби недоступна (404). Он говорит, что писал, глядя на wmctrl, так что не думаю, что будет сложно

>Это будет стандартный метод реализации чего-то, похожего на замыкание(на уровне языка ни в C, ни в C++ их нет)

"чегото похоже" - это суксь. В qt получается, что передать можно только sender, а если сигнал получает не только один этот объект? Замыкание зависит от контекста, если нет контекста - это не замыкание. sender - это не контекст

>Нет, гика, ты просто не знаешь C++.

да? ЕМНИП, на сигнал в Qt вешается только функция. Не объект.

>4.2 + 4.2 == 8.4 :)

ну добавь. А я посмотрю.

>Открываю диалог кде3, ввожу "/e<down>fs<down><enter>" и у меня открывается /etc/fstab, в qt4 почти тоже самое. Сюрприз?

сюрприз. Не работает. Или ты врёшь, или нужен секретный ключик в реестре =)

>Архитектурно правильное решение -- не использовать программы не написанные на gtk? Вещь в себе.

gtk? нет. Ибо и вне DE неплохо живут. и в DE интегрируются. В отличие от.

>Тут просто не надо использовать компилируемые языки.

напиши на tcl/tk blender и inkscape

>Dbus -- начнём с того, что он нарушает правило "универсальный формат данных -- текстовый поток".

почти любой IPC нарушает это правило. Кроме того это правило относится только к текстовым данным. Сюрприз?

>Ну а в остальном описанное реализуется легче всего на интерпретируемом языке.

дооо

>Повторяю: тут не нужен компилируемый язык.

повторяю, напиши абиворд на tcl/tk. А потом ужаснись скорости его работы

>Они никоим образом к glib не привязаны(слава Патрику :)).

GObject - это Qt и всё внутрь себя не тащит

>А то, что они не использованы ни в kio, ни в gnomevfs/gio -- это действительно проблема обоих велосипедов.

почему же, в gio используется. Как сервис-редиректор. =)

>zenity --file-selection

Там можно задать дефолтный каталог? Список расширений?

Вообще по сравнению с kdialog оно выглядит очень убого..

>сюрприз. Не работает.

Ты пробовал в кде или qt4? Если второе, то там при дополнении имени каталога слеш автоматом не ставится.

>Там можно задать дефолтный каталог? Список расширений?

в gtkdialog можно. Для ещё более навороченного можно юзать gtkserver - и писать gtk-приложения на баше

>Вообще по сравнению с kdialog оно выглядит очень убого..

ы? kdialog довольно примитивен. И прибит гвоздями к KDE.

>Ты пробовал в кде или qt4? Если второе, то там при дополнении имени каталога слеш автоматом не ставится.

в qt3 и в qt4 и в kde4

> zenity --file-selection

Отлично! Только вот это окошко должно быть общим для всех программ на десктопе. А это не используется в широкораспространённых DE :(

> вариант А (через жопу): Xnest --parent && опция --display= в гтк-приложениях.

Ну тут и комментировать нечего, раз через жопу.

> вариант Б (идеологически верный) Можно написать модуль гтк, который будет обрабатывать твой --embed (некоторые гтк-аппликухи имеют подобный ключик, например --socketid в gvim

Да. Но это должны быть не только модули gtk. Так должно выглядеть любое иксовое приложение(ну не считая быдлопроприетарщиков, у которых всегда проги выглядят обособлено). Простейшие виджеты и частоиспользуемые диалоги, будь то отображалка картинки, файловый диалог или toolbar, должны быть общими и легкоподменяемыми. Причём подмена эта должна заключаться в замене одной симлинки и не быть привязанной к тулкиту.