> Фигурный квотинг рулит. Я про d-bus писал

d-bus пришёл в qt из мира gtk. Будете утверждать обратное?

>Чего-нибудь на gstreamer'е и avcodec/avformat писали и можете сравнивать, что и как там сделано?

Кичитесь поеданием кактусов? Gstreamer интегрированная система и тут она уже перестает быть юниксвеем.

> Кромы корбы в гноме ещё есть и d-bus, который даже в qt прижился.

CORBA - это уходящая технология, в Гноме она сейчас активно вытесняется D-BUS. Кажется, в Gnome 2.24 корбы уже не будет совсем. Ну разве что её оставят ещё на релиз для совместимости со старыми прогами, которые не успеют переписать под D-BUS.

> Эта штука - система управления графом, ориентированным на обработку аудио- и видеоинформации. Своих элементов у него ажно 14 штук (gst-inspect | grep core | wc -l). Всё остальное написано разными девелоперами.

Идея замечательная. Реализация - говно.

>d-bus пришёл в qt из мира gtk. Будете утверждать обратное?

Эх гномеры гномеры, когда нечего сказать вы начинаете превозносить гном.

Интересно, на сколько страниц раздуют флейм "аналитики" ЛОРа?

> Эта штука - система управления графом, ориентированным на обработку аудио- и видеоинформации. Своих элементов у него ажно 14 штук (gst-inspect | grep core | wc -l). Всё остальное написано разными девелоперами.

Идея замечательная. Реализация - говно.

Общество потребления, чего ты хотел.

> Ага только его разработали не мигеля поруги а редхат, и есесно протолкнуть ему все это проще,

Я не знаю, кто такие поруги мигеля, и почему редхату должно чесаться проталкивать d-bus в стандарт.

Потому что они его разработали? Только не спрашивайте зачем они его разработали, видимо чесалось.

>> Как всегда в том, что связано с одной изветсной десктопной средой(не кде) :)

> Поподробнее, как gstreamer связан с gnome кроме того, что это тоже программа?

gobject-ом. Для любителей попридираться: я считаю, что проблемы гтк/гнома растут как раз из gobject.

> Кичитесь поеданием кактусов?

Хотя бы и так. Опыт - вещь бесценная, позволяет оперировать фактами.

> Gstreamer интегрированная система и тут она уже перестает быть юниксвеем.

По-вашему, юниксвей тоже интегрированная система, потому что всё завязано на пайпах. Если можно, то по пунктам распишите, почему, по вашему мнению, обмен между программами через пайпы в юниксе - это юниксвей, а обмен между элементами через линки в gstreamer'е - это уже не юниксвей.

> Эх гномеры гномеры, когда нечего сказать вы начинаете превозносить гном.

У меня stumpwm

mv> d-bus пришёл в qt из мира gtk. Будете утверждать обратное?

А что, feedesktop.org учредил GNOME Project? В вики об этом ничего не сказано: http://ru.wikipedia.org/wiki/D-Bus

>По-вашему, юниксвей тоже интегрированная система, потому что всё завязано на пайпах.

Не путайте интегрированость и легкость интегрирования.

>а обмен между элементами через линки в gstreamer'е - это уже не юниксвей.

А это текстовый пайп?

>> Фигурный квотинг рулит. Я про d-bus писал

> d-bus пришёл в qt из мира gtk. Будете утверждать обратное?

Ну и? С этим никто не спорит, как и с тем, что человек произошёл от обезьяны. Только обезьяны так и остались сидеть на пальмах.

А вот то, что есть реализации dbus-протокола, не завязанные на gobject -- мне несомненно нравится.

>gobject

Идея замечательная. Реализация - говно.

Ну латентные гномеры.

> gobject-ом. Для любителей попридираться: я считаю, что проблемы гтк/гнома растут как раз из gobject.

Вы ООП на голом Си кардинально лучше можете реализовать? Реализуйте, предложите им. Или вы за ООП на C++ радеете? Ну так оно там не самого лучшего качества.

> CORBA - это уходящая технология, в Гноме она сейчас активно вытесняется D-BUS.

Это вообще-то разные вещи - DBUS - локальный IPC, CORBA - распределённый.

>Вы ООП на голом Си кардинально лучше можете реализовать? Реализуйте, предложите им.

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

>Или вы за ООП на C++ радеете? Ну так оно там не самого лучшего качества.

Чем вам в С++ именно ООП не нравиться?

> Не путайте интегрированость и легкость интегрирования.

OMFG, как это понимать?

> А это текстовый пайп?

Т.е вот она, главная черта юниксвея?

> Ну и? С этим никто не спорит,

Спорят, ё-моё, спорят! ;)

> gobject-ом. Для любителей попридираться: я считаю, что проблемы гтк/гнома растут как раз из gobject.

> Вы ООП на голом Си кардинально лучше можете реализовать?

А нахрена это делать? Вон в tk целую графическую либу на голом C без ООП сделали.

> Или вы за ООП на C++ радеете? Ну так оно там не самого лучшего качества.

ООП -- это серебряная пуля? Зачем его тащить туда, где оно не нужно(в C)?

> Это вообще-то разные вещи - DBUS - локальный IPC, CORBA - распределённый.

CORBA может и в пределах одного хоста жить, чем гном пример. А tcp/ip вон и к d-bus'у хотят прикрутить.

> Т.е вот она, главная черта юниксвея?

Повторюсь:«Философия UNIX гласит: Пишите программы, которые делают одну вещь и делают её хорошо. Пишите программы, которые бы работали вместе. Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс».

>OMFG, как это понимать?

Если разбить приложение на ActiveX то оно будет интегрированным, но если попытаться его интегрировать с посторонним приложением то будет облом.

> Ну латентные гномеры.

Мне одинаково фиолетово и на гном, и на кде.

>> CORBA - это уходящая технология, в Гноме она сейчас активно вытесняется D-BUS.

> Это вообще-то разные вещи - DBUS - локальный IPC, CORBA - распределённый.

К d-bus-у можно прикрутить любой транспорт, в т.ч. сетевой. И вроде бы это уже реализовано.

> Чем вам в С++ именно ООП не нравиться?

А вы какое-нибудь другое ООП видели? Или опять из пустое в порожнее переливать будем, типа gstreamer - комбайн неюниксвейный?

>Оно необходимо также при, например, прокрутке.

С прокруткой вроде не было (заметных) проблем?

>> А это текстовый пайп?

> Т.е вот она, главная черта юниксвея?

Одна из наиболее удобных. Потому что текстовыми потоками умеет оперировать _любая_ программа.

Да, сторонники gstreamer-а закричат, что там достаточно подключить одну либу и всё станет пучком.

Но там _надо_ подключать внешнюю либу -- и это большой недостаток. Потому что не во всех языках её так же удобно можно подключить как и в C. Следовательно, я лишён возможности написать фильтр для gstreamer-а, например, на bash. А на perl или tcl мне придётся писать некоторую обвязку, которая -- лишний, багоопасный и никому не нужный код.

>Или опять из пустое в порожнее переливать будем, типа gstreamer - комбайн неюниксвейный?

Так что там с пайпами текстовыми, вы не ответили 8)

>А вы какое-нибудь другое ООП видели?

Значит не переходя на личности дискутировать вы не в силах?

> А нахрена это делать?

Ну как же, слой абстракции, и всё такое.

> Вон в tk целую графическую либу на голом C без ООП сделали.

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

> ООП -- это серебряная пуля? Зачем его тащить туда, где оно не нужно(в C)?

Можете гранату поганцам в офис кинуть :) Ну хочется людям ООП на Си писать, пусть пишут. Opensource, всё-таки.

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

А это точно бага, а не концепция?

Вот кроме этого пункта

> Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфей

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

> Значит не переходя на личности дискутировать вы не в силах?

Это сто раз уже обсасывалось. Если вам так интересно, заведите в development тред: "Почему ООП в C++ не самого лучшего качества".

> Значит не переходя на личности дискутировать вы не в силах?

Общество потребления, чего ты хотел.

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

Идея чудесная, реализация - говно

А чем конкретно плоха реализация ж-стримера?

Почему в DirectShow те же самые идеи работают прекрасно? У мелкомягких иднусов руки прямее оказались, чем у опенсорц хакеров?

Надёргал фраз из контекста, чтоб почётче выразить смысл

> Писать на gtk нудно и неудобно... Ну хочется людям ООП на Си писать

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

> На gtkmm с плюсатым сахаром уже веселее. На cells-gtk, наверное, ещё интереснее, а появился этот cells-gtk потому, что обвязку вокруг голых сишных библиотек писать просто.

Просто, но зачем? Уже есть Xlib, который можно обвязать чем угодно. Что в qt и сделано. Или в motif. Или в tk.

> Почему ООП в C++ не самого лучшего качества

Идея хорошая, реализация - говно.

> Почему в DirectShow те же самые идеи работают прекрасно?

Да та же самая история там. Достаточно одного говнючного элемента, чтобы работа всего pipeline'а нагнулась.

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

Я могу через dd пересылать данные какой-нибудь проприетарной штуковине, которую никто под gstreamer переписывать не собирается. Но не суть. Важна сама _возможность_ это делать.

>и как теперь с этим если надо программу портировать под винду? кеды тащить?

скорее наоборот, кеды будут использовать либы из куте, просто фонон нужен был в кедах еще когда куте4.4 не было, вот у них и была параллельная реализацияю

Displacer> Это вообще-то разные вещи - DBUS - локальный IPC, CORBA - распределённый.

Но здесь подразумевается использование CORBA (в Гноме его реализация называется Bonobo) для внутрисистемного взаимодействия между приложениями, т.е. локальное (внутрисистемное) применение CORBA.

Хотя, всё равно, существа дела это не меняет. Всё одно: CORBA эта уходящая технология. Внутри системы её заменят D-Bus.

> Вот собственно из этого и растут проблемы гномоприближенных софтин. И именно поэтому туда тянут то питон, то моно -- потому что писать на голом C неудобно, особенно гуйки.

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

> Просто, но зачем? Уже есть Xlib, который можно обвязать чем угодно. Что в qt и сделано. Или в motif. Или в tk.

А какая разница? :) Ну будет cells-qt, cells-motif, cells-tk, что изменится? Фишка в том, что использоваться будет cells, а не xlib, gtk или qt, или ещё что.

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

>Emacs - такое же bloatware, как и Qt. UNIX-way - это одна задача - один инструмент.

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

>Это сто раз уже обсасывалось.

И всетаки?

>Вот кроме этого пункта ... gstreamer - полный юниксвей.

Немножко беременна ©

> Ну будет cells-qt, cells-motif, cells-tk, что изменится? Фишка в том, что использоваться будет cells, а не xlib, gtk или qt, или ещё что.

Ущербность такого подхода легко видеть на примере wxWidgets.