Кстати, в качестве предположения, уж не задумал ли Опоссум наваять toolkit-sever (типа X-servera) с интерфейсом через CORBA? Вот это будет тормоз - по сравнению с которым вопросы писать ли API на С или С++ отступают на второй план.

Это Вы не на тот пост ответили. Вы это скажите тому анонимусу, который про "пародию на ОО". Да, и еще - ОО Буч изобрел?;)

Мысль любопытная. Боюсь, только народ недоволен будет. Особенно те, кто все-таки захотят вять гуи на С (или С++) - в этом случае один С код будет генерить поток команд, которые другой С код будет интерпретировать. Медленновато как-то получится.

С обертками для хедеров - вообще говоря, эту задачу можно немного автоматизировать при помощи препроцессоров. Представьте, например, такой gob, который умеет генерить не только С код, но и обертки для перла-питона. Синтакс, возможно, придется подправить - но, в принципе, реализуемо - если поставить такую задачу. Короче, до сегодняшнего дня как-то народ с врапперами справлялся - хотя, Вы правы, 4 функции обернуть сильно проще, чем 444 класса.

> запарили ! не ну сколько можно !! ненавижу !!! :) вот иди сам и читай : http://www.planetpdf.com/mainpage.asp?WebPageID=620 svu - respect; p.s. мое мнение : C++ - только в обетрки годиться...

Есть еще одно мнение, что написанные на _ПРАВИЛЬНОМ_ С++ библиотеки и программы работают быстрее по сравнению с имитацией ООП на С из за того, что часть работы во время выполнения забирает на себя компилятор. В результате выигрыш. Не очень большой но для имитаций ООП на С неликвидируемый. Мое мнение с этим совпадает. Вот только Qt написан не на _ПРАВИЛЬНОМ_ C++ и у него этот выигрыш может отсутствовать. Но я много ковырялся в реализации gtk. Там реализовано столько работы во время выполнения, что это выливается в немеренную разницу для любой реалиции (естественно в пользу плюсовой реализации). Так что, несмотря на то что идеологически вернее писать на С для gtk(и мне это нравиться), но удобнее писать и быстрее работает Qt. Что поделаешь. Такова жизнь. Есть идеалы, а есть реальность. :(

Знаете, у меня в процессе обсуждения на ЛОРе началось складываться ощущение, что ПРАВИЛЬНЫЙ С++ приближается по достижимости к Святому Граалю. Не совсем (все-таки некоторые его видели, а некоторые даже утверждают, что сами производят), но что-то близкое:)) Особенно - после чтения интервью с автором языка (даже дело не в самом тексте, который может быть уткой, а в мыслях, на которые этот текст наводит).

> столько работы во время выполнения

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

Скорость работы Gtk+

>Но я много ковырялся в реализации gtk. Там реализовано столько работы во время выполнения, что это выливается в немеренную разницу для любой реалиции (естественно в пользу плюсовой реализации). Так что, несмотря на то что идеологически вернее писать на С для gtk(и мне это нравиться), но удобнее писать и быстрее работает Qt. Что поделаешь. Такова жизнь. Есть идеалы, а есть реальность. :(

Я сейчас не стою на стороне какого-либо лагеря (ни Gtk, ни Qt), но ты можешь конкретно указать место про "немереную разницу" реализации? Не трудозатрат на написание текста, а именно работы написанного? Ну это чтобы внести ясность, а то вот я тоже ковырялся в исходниках Gtk и Glib и что-то такого "немеряного" я не нашел. Давай оставим в стороне сигналы - это отдельный разговор и сузим обсуждение до конкретных вещей в реализации объектной модели Glib.

P.S. А интервью - явная утка. Это я так предполагаю. Хотелось бы знать, не на 1 апреля ли это было опубликовано :)

Что касается скорости работы Gtk+ 2.x, то смею уверить, что работает тулкит очень быстро. Он рисует медленно, но, скорее всего, потому что как-то не совсем эффективно взаимодействует с X-ами, с расширениями типа RENDER и т. п.

> Есть еще одно мнение, что написанные на _ПРАВИЛЬНОМ_ С++ библиотеки и программы работают быстрее по сравнению с имитацией ООП на С из за того, что часть работы во время выполнения забирает на себя компилятор. В результате выигрыш. Не очень большой но для имитаций ООП на С неликвидируемый. Мое мнение с этим совпадает. Вот только Qt написан не на _ПРАВИЛЬНОМ_ C++ и у него этот выигрыш может отсутствовать.

"Правильный C++" меньше подходит для работы с GUI чем, скажем Objective C.

3-ий пункт.

http://doc.trolltech.com/3.3/templates.html

> Что касается скорости работы Gtk+ 2.x, то смею уверить, что работает тулкит очень быстро. Он рисует медленно, но, скорее всего, потому что как-то не совсем эффективно взаимодействует с X-ами, с расширениями типа RENDER и т. п.

Не очень-то убедительное оправдание для библиотеки, в обязанности которой и входит взаимодействие с Х-ами.

Туше..:)

Конечно, панго подтормаживает (рендеринг уникода приличного качества - дорогое удовольствие). За gtk1 не угнаться - это факт. Но, скажем, на PIII gtk2 работает с вполне достаточной скоростью отрисовки (вообще, есть мнение, что скорость работы gtk2 достаточно сильно зависит от сборки и от графических дров - каким образом, точно не скажу). Вообще, слыша все крики "gtk2 - тормоз" и "qt - тормоз" очень хочется, чтобы люди конкретно ткнули пальцами, померяли и сказали: "Вот этот виджет (окно) тормозит в отрисовке. Страшно тормозит."

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

Можно и так, но есть вариант получше (но в этом случае придется подумать, прежде чем интерфейс сочинять - нужно следовать определенным правилам). Можно просто вызывать callbacks, определенные в основной программе, из tk интерфеса, или записывать состояние интефейса в tcl переменные, а из основной программы их trace-ить и при их изменении читать/писать (кажется, начиная с tcl8.0 запись/чтение переменных можно осуществить, минуя конвертацию в строку, несмотря что в tcl все есть строка).
С генераторами (в частности для GTK) тоже не все так гладко. Единственные, по-моему, кто честно генерировал биндинги из *.h - это авторы pygtk. Осальные или пишут вручную или генерируют свои биндинги уже из python-овских (т.к. проще)

> А что GTK, что QT - пока обертки под все хедеры напишешь - ипанутся можно.

SWIG ?

FLTK, wxWidgets, FOX toolkits - если не устраивают QT & GTK(GTK--, VDK)

не устраивает C , C++ - ADA (только снова идет GTK, QT в сторонке).

Авалон

Ну так tk и есть решение ;) Доказательством служит наличие биндингов для практически всех языков.

Но минус в том, что он уродлив и чуть-чуть тормознут :(

> Единственные, по-моему, кто честно генерировал биндинги из *.h - это авторы pygtk.

Так значит - можно?:) Тогда и овцы (нормальный сишный API) целы, и волки (скриптовые байндинги) сыты. Мне кажется, так лучше. Хотя, если Вы уверены, что байндинг в тиклевом стиле не будет тормозить - такой подход тоже имеет право на существование. Боюсь только, народу (пришедшему от сохи С) не понравится.

IDE для Glib

Кстати, есть один проект, который обещал некоторые вещи, которые идут дальше обычного препроцессора gob. Проект называется scaffold, который должен был стать мощным IDE для GNOME с мощной системой плагинов, автоматическим парсингом (!) Glib-ориентированного кода и много всяких хороших идей. Он даже активно на devel-tools на lists.gnome.org обсуждается. Но, похоже, проект несколько подзаброшен. Насколько я понял, он даже предполагал некоторую автоматизацию для байндингов. Точно я не вдавался в детали...

Scaffold

Вот тут кое-какая информация первичная.

http://martianrock.com/papers/scaffold_whitepaper_code_automation.html

>>>А вы что на это скажете?
Скажем что пора это делать !
Если хочешь что-то сделать правильно - сделай это сам !

>>Объясните пожалуйста, чем вас так не устраивает API Qt? Только >>аргументированно.
Лчно меня не прут уродливые и тормозные сигналы, понятно что их скорость имеет последнее значение однако выглядит это очень коряво есть и явные баги и глюки которые приходится обходить.

здесь более правильно сравнивать руководство helloworld на qt с helloworld на связке gtk и libglade , тогда будет одинаково коротко.

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

В двух словах. В gtk огромное количесвто приведений типов. Узнай получше про генерик программирование в плюсах и поймешь, что в плюсах их будет на порядки меньше.

> В gtk огромное количесвто приведений типов.

А любой плюсовой библиотеке полно class, public, private, typename и прочего словесного мусора.

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

Узнай получше Qt и пойми, что эти минимальные и синтаксически уродливые возможности С++ в этой библиотеке не используются.

Gtk+ vs Qt

Не, спор идет неправильно. Начинают друг-другу какие-то абсолютно второстепенные вещи доказывать...

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

> Узнай получше Qt и пойми, что эти минимальные и синтаксически уродливые возможности С++ в этой библиотеке не используются.

Правильно. Почему? Потому, что в С++ все статично. И даже генерики мало спасут (конечно, некоторые конструкции будут выглядеть элегантнее - но не более того). Динамики слотов и сигналов от плюсов только средствами языка по хорошему не добиться.

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

amulet? http://www-2.cs.cmu.edu/Groups/amulet/

Лучше бы Tcl/Tk везде повнедряли и развивали!

Круто! Вааще выкинули ребята все ОО навороты плюсов и построили свой ОО мирок. Очень занятная игра ума. И байндинги лепятся просто влет... Приятно смотреть, когда люди интересно и осмысленно фантазируют.

> Круто! Вааще ...

> svu (*) (01.04.2004 0:02:37)
           ^^^^^

:)

Это неправда! В Гринвиче еще только 23 часа! А тогда и вовсе было 21!

Ну и зачем он нужнен?

Во первых, нужно разделять Tcl(язык) и Tk(графику). Что все-таки предлагается развивать?

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

А про язык - что же, хороший простой язык. Да вот только хочется все-таки объектного программирования (как в Python). Есть, конечно, itcl (кстати, без iwidgets и tix тяжело довольно-таки обойтись в графическом приложении), но ведь это уже не развитие языка.

ну и зачем писать такие посты? сразу же видно что то ни сном ни духом и не разу не писал под кутэ.

>>И все забывают о реально универсальном API MFC
Бюэ-эээ...

>>Может, надо ввести проверку на наличие диплома об окончании ВУЗа перед >>тем, как давать людЯм постить :>?
Гоша а ты в натуре считаешь что диплом вуза о чем-то говорит ? :)))
Так может считать только человек вуза не закончивший :)))

> Что все-таки предлагается развивать?

> Про библиотеку вообще обсуждения быть не может,

Простой и очень удобный в использовании API.

> пока она не приведена к современному виду

Ага, пока битмапы с АА-фонтами на несколько мег для каждой кнопки не начала по сети гонять.

> А то сейчас Motifовские окошки выглядят нелепо.

Почитай про X-resources. Дефолтные gtk и qt тоже выглядят нелепо (а gtk к тому же и по motif-овски).

> Да вот только хочется все-таки объектного программирования (как в Python).

Проста так, чтоб было? И почему как в python, мне вот хочется чтоб как в Io.