Multimedia API в KDE4

>видишь ли в чем дело - программа на Pascal (не Gnu) не сможет работать вместе с C программой - разные конвенкции по вызовам

а ты не в курсе, что паскаль (не Gnu) может вызывать функцию и так и этак? Или ты забыл, что в паскале перед использованием функции - надо её объявить соответствующим образом (и это, как правило уже сделано правильным образом в подключаемых файлах) ?

>В чем фальшивость?

в существовании вин-юзероф ;)

> однажды мне вздумалось запустить что-то гномовское (вроде галеон, что ли...) под не-гномом (то ли виндовмейкером, то ли енлайтментом...) так оно мне открыло большое окошко с титлом "Десктоп" и в нем запустился галеон :)

Ох... Как говаривал Мягков в "Иронии Судьбы": надо меньше пить, надо меньше пить, надо меньше пить!

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

С запуском галеона - точно так же, я вас уверяю :-).

> Или C++ ABI уже не ломают регулярно при выходе новых версий gcc? Или c++ abi одного компилятора совместимо с abi другого компилятора?

Здра моя ра... Видимо, линуховое ядро полностью написано на C++ ? Иначе как объяснить, что модули нужно пересобирать при каждом чихе ядерщиков или писателей компилера ? Ведь в C всё должно быть пучком, если я правильно понял твою мысль :)

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

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

> В этом отношении мне более подуше GNOME чем твой KDE!!!

...и это говорит человек с никнеймом "мозгоёб"...

> гном всё-таки в сторону мака движется.

Расскажу я вам, в какую сторону он движется. Благо маков в этой комнате три, кажется, штуки. Одна - под столом. А потом расскажу, в какую сторону движутся маки...

>в существовании вин-юзероф ;)

"Ты видишь суслика? О он есть"...и куда это наши любимые вин юзвери делись? ;)

>легко ли заставить программу написанную на таком lisp работать совместно с программой написанной для такой java vm ?

через биндинги jvm к цамлю дергать интерпретатор лиспа из жабы. В чем проблема-то? Другое дело, что это через жопу, как и любые ООП-ные биндинги, впрочем

>...и это говорит человек с никнеймом "мозгоёб"...

А что, каждый день использования GNOME...тренерует и закалает моск :)

>При чем тут другие ЯП?

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

>> видишь ли в чем дело - программа на Pascal (не Gnu) не сможет работать вместе с C программой - разные конвенкции по вызовам

> а ты не в курсе, что паскаль (не Gnu) может вызывать функцию и так и этак? Или ты забыл, что в паскале перед использованием функции - надо её объявить соответствующим образом (и это, как правило уже сделано правильным образом в подключаемых файлах) ?

не убегай - проигрывать так хоть красиво
речь о том что у C и Pascal разные соглашения о вызовах
отсюда без дополнительных шагов в виде асемблера (в виде, например, поддержки со стороны производителя компилятора чужеродных вызовов) их не срастить,
но тогда если исходить из логики -
"давайте писать на языке который можно срастить с любым другим языком"
получается что лучше всего GNOME писать на асемблере ....

> Откуда у кдешников такое аццкое желание выкинуть все языки кроме С++?

Интересно, зачем вообще придумали DCOP ._o_O

И зачем к нему биндингов для всякиз языков понавешали, включая bash.... ._o_O

Интересно, а как в gtk библиотеках реализовать kgtk...

> Расскажу я вам, в какую сторону он движется. Благо маков в этой комнате три, кажется, штуки. Одна - под столом. А потом расскажу, в какую сторону движутся маки...

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

о чём ты?
pyKDE, rubyKDE - запросто

Вы тут всё что-то измеряете ? :) Имхо, сидим там где комфортнее. Мне для пользования достаточно связки Emacs+Yakuake+Konqueror+Kontact+amaroK+Sim+Kwallet .. В гноме как-то ничего похожего для моего комфорта не нашлось(именно для комфорта, на кде совсем недавно пересел, до этого долго сидел в гноме - там всё это было, но не так удобно), и мне без разницы как там и что устроено - ничего не тормозит, когда всё это запущено и нормально..

>Ты лучше расскажи, можно ли эту дебильную лампочку на кнопке открытия крышки в powerbook'ах выключить, а то я туда скоро гвоздь заколочу.

А что там за лампочка? :)

> P.S. всеравно МакОсь рулит :)

Куда она рулит? Пока, по всем признакам, она рулит в сторону OS/2.

>Откуда у кдешников такое аццкое желание выкинуть все языки кроме С++?

Откуда у гномеров такое аццкое желание выкинуть все языки кроме С? =)))

>Ведь в C всё должно быть пучком, если я правильно понял твою мысль :)

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

Подумай ещё

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

тут уже не проблема языка, а проблемы ООП в целом - отсутствие единого ABI

> А что там за лампочка? :)

Белая, яркая, светит в глаза, когда ноут на столе в сторонке.

>CORBA - Common Object Request Broker Arhitecture CCM - Corba omponent Model .... COM - Component Object Model

Не хочу спорить о терминах. http://en.wikipedia.org/wiki/CORBA

In computing, Common Object Request Broker Architecture (CORBA) is a standard for software componentry ...

CORBA Component Model (CCM) is an addition to the family of CORBA definitions. It was introduced with CORBA 3, and it describes standard application framework for CORBA components. It could be described as "language independent Enterprise Java Beans (EJB)".

>Компоненты не существуют без контейнеров - иначе это оксюморон

В корбе компоненты существуют в пределах серверов приложений.

>Implementation Repository не был стандартизирован OMG

Да, однако в он был включен в стандарт в качестве рекоммендации. И это было четко осмысленное решение.

>для поддержки компонентной модели нужно как минумум [Class|Object]Factory

Это ваше личное мнение, а вот здесь - другое http://en.wikipedia.org/wiki/Software_componentry

>и вы правы в целом, но быстрее прямого вызова быть ничего не может (наверное :) так что COM будет быстрее всех :)

Повторюсь - В Корбе - когда и клиент и сервер находятся в границах одного процесса маршаллинга нет. Все вызовы локальны. Также как и в MS COM.

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

>Откуда у гномеров такое аццкое желание выкинуть все языки кроме С? =)))

нет такого желания. И именно простота создания биндингов к C-библиотекам позволяет писать приложения под gtk даже на такой экзотике как clip ;)

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

>> легко ли заставить программу написанную на таком lisp работать совместно с программой написанной для такой java vm ?

> через биндинги jvm к цамлю дергать интерпретатор лиспа из жабы. В чем проблема-то? Другое дело, что это через жопу, как и любые ООП-ные биндинги, впрочем

причем тут ООП ? не хочешь Java VM ? - пожалуста - Haskell
станет легче ?

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

проблема в том что вы придумали проблему - совместнаяя работа двух языков вместе
а потом придумали псевдо решение для нее - все написать на С ....

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

помоги plz.

> софта на чистом QT практически нету. Мне ещё раз повторить, чтобы до ананимусов дошло?

Нету: Skype, Syntext Serna, Sim, Psi, Opera... Я понял, их не существует? Как ни парадоксально, но такого софта, при том довольно полезного, очень даже не мало. Выслушаю про альтернативы Syntext Serna (XML-редактор), мне правда интересно. Я не буду искать "больше 6 программ", я не адвокат Qt, просто надоело слышать бредовое нытьё.

Забыл одну песенку про переключение раскладок, придумал другую про темы, приплёл велосипеды, хотя, как я понимаю, в велосипедах ты просто ничего не смылишь. Вопрос на засыпку, чем переднее колесо за $20 хуже, чем переднее колесо за $200? А ведь всё одно и то же -- переднее колесо от велосипеда...

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

> адобу нет альтернатив?

Хе-хе... Пожалуй, в некоторых случаях, нет. Пресловутый Firefox'ный PDF правильно показывается только в Acrobat'е :-).

>> Не надо сваливать проблемы компилятора на плечи языка.
> тут уже не проблема языка, а проблемы ООП в целом - отсутствие единого ABI

ABI - дело OS - это проблема Unix :)))

а вот такие упертые - которые пишут и пушут на C
прикрываясь мифическими аргументами
препятствуют решению этих проблем
И вообще - Java появилось только потому, что некоторые !@#$%^&*
до сих пор пишут на C

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

в компиляторах паскаля кстати, изначально была возможность обявления С-функций. И никаких дополнительных шагов в виде ассемблера. Более того - call <addr> это всегда call <addr>. Вызов же виртуального метода ООП подразумевает определенный формат vmt в памяти. Отсюда и косяки

>получается что лучше всего GNOME писать на асемблере ....

а С - это практически ассемблер и есть. Не, асм конечно, попроще и побыстрее...но у него с кроссплатформенностю беда :(

> не нужно - эти биндинги существуют исключительно для С

Этих биндингов не существует. Тот, кто утверждат обратное, ДАЖЕ НЕ ПЫТАЛСЯ НИ РАЗУ их использовать. Типичная черта типичного линуксоида - рассуждать с умным видом о том, о чём не имеет ни малейшего понятия.

> проблема в том что вы придумали проблему - совместнаяя работа двух языков вместе

...в то время, как прогрессивные товарищи используют DCOP и компоненты :)

>ABI - дело OS - это проблема Unix :)))

это проблема пионеров-писателей c++ библиотек

>И вообще - Java появилось только потому, что некоторые !@#$%^&* до сих пор пишут на C

в фортунки.

>проблема в том что вы придумали проблему - совместнаяя работа двух языков вместе а потом придумали псевдо решение для нее - все написать на С ...

ты это...путаешь причину и следствие. Попей кофейку, что ли

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

Ну, это черта любого флеймера, который сам ничего не делал.

> помоги plz.

Из pyqt можно взять. только они кривые.

> Этих биндингов не существует. Тот, кто утверждат обратное, ДАЖЕ НЕ ПЫТАЛСЯ НИ РАЗУ их использовать. Типичная черта типичного линуксоида - рассуждать с умным видом о том, о чём не имеет ни малейшего понятия.

"Все п*****сы, а я - Д'Артаньян!".
Вместо того, чтобы обобщать, научил бы, статью умную написал бы, опубликовал, денег получил, а мы, тёмные, просвещались бы.

> Корба - одна из самых быстрых сомпонентных моделей.

Быстрая - где? В карьере, среди карьерных экскаваторов? Может быть. На десктопе, где карьерными экскаваторами и не пахнет - вряд ли.

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

>Ну, это черта любого флеймера, который сам ничего не делал.

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

Но намного приятнее, когда говорят спасибо не за слова, а за созданную ценность :)

Слюнявьте дальше ЛОР, аминь :)

> sim, vyqchat, kmail, kate, kdevelop, konsole

YaKuake, YaKuake забыли!!! :)

>а С - это практически ассемблер и есть. Не, асм конечно, попроще и побыстрее...но у него с кроссплатформенностю беда :(

Интересно! Вроде ядро написано на С и никаких проблем с кроссплатформенностью!

> и локальный COM вызов всегда будет быстрее корбового в силу хотябы отсутствия маршалинга :)

Ну, некоторый маршалинг там все равно есть. Пусть и оформленный в итоге как вызов по таблице виртуальных функций :-)

> YaKuake, YaKuake забыли!!! :)

Если уж на то пошло, пусть уважаемый gnome-апологет найдет аналог qjackctl.

>> CORBA - Common Object Request Broker Arhitecture CCM - Corba omponent Model .... COM - Component Object Model

> Не хочу спорить о терминах. http://en.wikipedia.org/wiki/CORBA
In computing, Common Object Request Broker Architecture (CORBA) is a standard for software componentry ...
CORBA Component Model (CCM) is an addition to the family of CORBA definitions. It was introduced with CORBA 3, and it describes standard application framework for CORBA components. It could be described as "language independent Enterprise Java Beans (EJB)".

>> Компоненты не существуют без контейнеров - иначе это оксюморон
> В корбе компоненты существуют в пределах серверов приложений.


как динамически загрузить реализацию интерфейса в CORBA "сервер приложений" ?
мы говорим о разных вещах - вы о компонентной архитектуре
я об развертывании компонентов - deployment
оба правы :)))



>> для поддержки компонентной модели нужно как минумум [Class|Object]Factory
> Это ваше личное мнение, а вот здесь - другое http://en.wikipedia.org/wiki/Software_componentry



почитайте - там же ясно сказано - A unit of independent deployment and versioning



>> и вы правы в целом, но быстрее прямого вызова быть ничего не может (наверное :) так что COM будет быстрее всех :)
> Повторюсь - В Корбе - когда и клиент и сервер находятся в границах одного процесса маршаллинга нет. Все вызовы локальны. Также как и в MS COM.



кошмар - вы COM знаете ?
вызов var->method () будет самый быстрый ? не правда ли ?
что то вроде
->implementation
в CORBA - в лучшем случае -
->stub->implementation

просто Servant не наследник Object :)

Зато какой ценой... Сколько препроцессорных заморочек и т.п... :)

>Интересно! Вроде ядро написано на С и никаких проблем с кроссплатформенностью!

а ты поглубже в сырцы загляни.

> gnu никуда не отправится - одна из лицензий, под которыми распространяется mono, как раз gnu (остальные - lgpl и mit + можно договориться с новелом за отдельные бапки о предоставлении коммерческой лицензии)

Лицензия - дело даже не первостепенное (хотя какой смысл распространять одну и ту же софтину под GPL и под LGPL - не пойму, думается, у де Иказы все-таки мозг есть).

Рассказывать, что такое GNU и как соотносятся dotGNU и Mono?

> Все п*****сы, а я - Д'Артаньян

Ну, если ты себя считаешь всеми, тогда все п*****сы.

> Вместо того, чтобы обобщать, научил бы, статью умную написал бы, опубликовал, денег получил, а мы, тёмные, просвещались бы

Пишу здесь. Читай, просвещайся : никогда не пытайся рассуждать о том, чем не занимался. 100% обосрёшься.

2yeolahim: давай, единое представление экземпляра класса в памяти для C++ и питона в студию. Потом поговорим об удобстве вызова c++ из других языков.

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

> в компиляторах паскаля кстати, изначально была возможность обявления С-функций. И никаких дополнительных шагов в виде ассемблера. Более того - call <addr> это всегда call <addr>. Вызов же виртуального метода ООП подразумевает определенный формат vmt в памяти. Отсюда и косяки

в виртовском паскале ???
call <addr> это хорошо - но как ты аргументы передашь ?
тебя поймут ?
спецификация на vmt не больше спецификации на способ передачи аргументов