> Ну по крайней мере вы не знаете, что GTK/Cairo надо сравнивать с QtGui. Одно - unixway, другое - платформа. Просто две разных философии.

Какой то бред вы несете товарищ. Зачем мне сравнивать GTK/Cairo с QtGui ели я выразил свои мысли на счет сравнения GTK c QT в целом. Я тут не докторскую защищаю между прочим.

> мля лемминги, поймите наконец Python - обертка вокруг C/C++ фнукций, никаких существенных тормозов она не добавляет...

Поняли, при виде этого парня два раза 'ку'. :-)

быстрого проектирования быдлопроектирования элементов интерфейса

Очевидный фикс.

> Си++ ABI давно уже есть.

Дай пруф, я не в курсе.

Вы таки несете бред. Вы сравниваете салат и огурец. Qt - платформа, Gtk - часть платформы чисто для GUI. В ту платформу с Gtk входит Cairo, Pango, ATK, Glib и тд.

Приятно что остались еще здравомыслящие люди.

Джоно Бэкон порадовал.

Давно понятно, что место для qt у параши. А уж у k* разработчиков, с манией главное меню в 250 пунктов, и прямо в ней.


Хиг, хиг и только хиг.

То есть по твоему сравнивать GTK c QT неправильно?

Причем человек еще вычеркнул MSVC, на котором компилируют ой какую часть софта. Нормальный тулкит должен каким то образом дружить и сдругими компиляторами. А то программа на одном билде Qt падает с другим билдом Qt. Для Gtk-приложений это анекдот, но для Qt - суровая реальность.

Наконец-то! Сравнивай QtGui и Gtk/Cairo если надо. Хотя корректнее будет QtGui vs Gtkmm/Cairomm. Cairo нужен потому, что Gtk - gui only, он не содержит векторной графики и анимации.

> Даже когда оно затерло стек вызовов? Сказки.

Назови случаи, когда оно затирает стек вызовов.

Вот пример из моего фреймворка, вставил в функцию кривой указатель в release-mode (безымянные функции, потому что static):

Unhandled: 'cfAccessViolationException_ID: Attempt to read or write protected memory'

Thread: 'Main'.

Stacktrace:

./cf[0x8053f36]

[0x66a410]

./cf(window_OnLoad+0x47)[0x804e03b]

./cf(cfWindow_Show+0x2a5)[0x80524b9]

./cf(__cfMain+0xd7)[0x804e226]

./cf(main+0x20)[0x804e143]

/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x2eeb56]

./cf[0x804de51]

Под виндой разве что не работает. Но это пример на си. Если реализовывать систему, о которой я описал выше, будет оно слинковано несколько иначе. И виртуальная машина тут не нужна.

АХАХА! Еще на чей конец то. Не это ли я написал еще в самом своем посте? Разве я не писал что QT и GTK разные вещи?

http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

-rdynamic

Pass the flag -export-dynamic to the ELF linker, on targets that support it. This instructs the linker to add all symbols, not only used ones, to the dynamic symbol table. This option is needed for some uses of dlopen or to allow obtaining backtraces from within a program.

Но оно у меня не отображает static-функций. Но это си. В случае реализации отдельного языка ничто не мешает ему линковать static-функции как неstatic, т.е. добавлять имя в образ. И тут ВМ совсем не нужна :)

>> Си++ ABI давно уже есть.

Дай пруф, я не в курсе.

Тебя в гугле забанили?

http://www.delorie.com/gnu/docs/gcc/gcc_110.html:

«Starting with GCC 3.2, GCC binary conventions for C++ are based on a written, vendor-neutral C++ ABI that was designed to be specific to 64-bit Itanium but also includes generic specifications that apply to any platform. »

> Давно понятно, что место для qt у параши. А уж у k* разработчиков, с манией главное меню в 250 пунктов, и прямо в ней.

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

Поставил OpenSuse. Там полная жопа, нихера не работает. Поставил Mandriva. Жопа поменьше, не работает только половина, но всё равно неприятно. Поставил привычно-бубунтячий Mint - всё волшебно, почему-то проблем минимум.

Но таки вопрос с годными кроссплатформенными гуями остаётся открытым. Неужели wxWindows?..

> Ну реализуйте. Потом заметите, что у вас по факту получилась собственная ВМ.

Не отличайте runtime от virtual machine? В С++ есть vtbl, таблицы исключений, опциональный RTTI. И С++ от этго не стал ВМ внезапно. Рантайм станет ВМ только тогда, когда он начнёт опираться на байткод и иметь все нужные инструменты для работы с ним. А в моём предложении байткода нет.

>> Даже когда оно затерло стек вызовов? Сказки.

Назови случаи, когда оно затирает стек вызовов.

Указатель на автоматическую переменную (или alloca) + выход за границу массива; просто неинициализированный указател, направленный в стек.

> даже на олимпиадных числодробилках

Real-world GUI example, ёлы-палы.

Но это вилами по воде. Пишите, когда напишете приложение на GCC, которое будет юзать классы из библиотеки на С++, которая написана на MSVC. Или наоборот.

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

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

Где я писал «незаменимо»? Помогает. Перемещающий сборщик без ВМ будет писать довольно затруднительно.

С чего вы взяли? Как я уже сказал, нужен RTTI (который есть в с++) и интеграция потоков в райнтайм (ЕМНИП, это есть даже в glibc) для останова всех потоков. Заметьте, glibc и с++ ВНЕЗАПНО не считаются ВМ.

Вы хотите сказать, что умение системой интерпретировать некий целевой машинный код является обязательным условием для compacting gc?

> а к гтк нелюбовь, ибо оно уж очень стрёмное под виндой.

Кроме Windows Impersonator (неотличимый от оригинала на Vista/7), Gtk умеет на винде еще и Human, Clearlooks, а главное - Nimbus. Ну и конечно еще сотни тем. Осиливаем Gtk Theme Selector. Пишем приложения с включеной вашей любимой темой

>>> Даже когда оно затерло стек вызовов? Сказки.

Назови случаи, когда оно затирает стек вызовов.

Указатель на автоматическую переменную (или alloca) + выход за границу массива; просто неинициализированный указател, направленный в стек.

Хах, это если только писать на голом си вручную. Мы же говорили о реализации высокоуровневого языка, там такое невозможно в принципе (проверка на невыход, все переменные инициализированы в ноль и т. д.).

> Пишите, когда напишете приложение на GCC, которое будет юзать классы из библиотеки на С++, которая написана на MSVC. Или наоборот.

Ну, собери мне Линукс-приложение компилятором MSVC, я посмотрю, что можно сделать.

А, и еще вызови мне через GObject объект из Питона или Руби. Ведь GObject - универсальный ABI, да?

Именно. Простым memcpy часто бывает если не правильно размер задать.

> Хах, это если только писать на голом си вручную

Ну ты похвалялся, как круто у тебя Си-приблуда показывает бэктрейс, не?

> Ну, собери мне Линукс-приложение компилятором MSVC, я посмотрю, что можно сделать.

Во-первых я привожу пример просто другого компилятора, несмотря на то, что без ABI на винде вам будет грустно. Будете все ваши либы с нуля на MSVC компилить, чтобы его оттуда могли использовать. Но если послушать ваши выкрики «не нужно!» по поводу разработки под винду и даже с ними согласиться, то разве правильное техническое решение не должно учитывать все ситуации, даже такие. Они взяли и решили проблему разных компиляторов.

А, и еще вызови мне через GObject объект из Питона или Руби. Ведь GObject - универсальный ABI, да?

Я уверен, что это возможно. Основа заложена. Конечно этот обьект должен быть тоже GObject, что будет обеспечено инфраструктурой связи. Но в основном связь наоборот. И тогда все прекрасно.

> С чего вы взяли? Как я уже сказал, нужен RTTI (который есть в с++) и интеграция потоков в райнтайм (ЕМНИП, это есть даже в glibc) для останова всех потоков.

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

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

>> Хах, это если только писать на голом си вручную

Ну ты похвалялся, как круто у тебя Си-приблуда показывает бэктрейс, не?

Нет :) Там человек утверждал, что для вывода адекватного бектрейса обязательно наличие ВМ. У него свет клином сошёлся на слове «ВМ» :)

> Кроме Windows Impersonator (неотличимый от оригинала на Vista/7), Gtk умеет на винде еще и Human, Clearlooks, а главное - Nimbus. Ну и конечно еще сотни тем. Осиливаем Gtk Theme Selector. Пишем приложения с включеной вашей любимой темой

Осталось ещё отучить его тормозить феерически.

>Давно понятно, что место для qt у параши. А уж у k* разработчиков, с манией главное меню в 250 пунктов, и прямо в ней

Будь паинькой, найди стену, а?

Есть всё, но нет моно и мужика-2. Всё-таки мир несовершенен.

> Там человек утверждал, что для вывода адекватного бектрейса обязательно наличие ВМ.

Враньё.

Я утверждал, что ВМ _может гарантировать_ вывод адекватного бэктрэйса. Конечно, и без неё можно худо-бедно обойтись. Но полноценное решение как-то привлекательнее.

> Будете все ваши либы с нуля на MSVC компилить, чтобы его оттуда могли использовать.

Э? Библиотеки на чистом Си вроде бы совместимы у MSVC и GCC. Ну а для Си++ GObject просто нерелевантен.

А, и еще вызови мне через GObject объект из Питона или Руби. Ведь GObject - универсальный ABI, да?

Я уверен, что это возможно.

Это возможно _реализовать_, если кто-то напишет мост между GObject и объектной моделью Питона. Точно так же можно написать мост между GCC C++ ABI и MSVC ABI (если MSVC появиться на Linux).

GObject - это объекная модель, которую можно использовать в Си, не более (а можно и не использовать).

> Угу, управление выполнением кода вам понадобится.

Единственное управление - это останов потоков. Всё.

И изоляция от чужого нативного кода, не подлежащего перемещаемому GC

М? Вы знаете, как в compacting-gc выделяется память вообще? Она предвыделяется большущими сегментами по n МБ. Вероятность того, что нативная память каким-то образом overlapped с managed - равна нулю, если вы об этом. Мы прогоняем сборщик мусора только по таким сегментам. Мы никаким образом не пересекаемся с native-памятью. Алсо, никто не мешает завести отдельную кучу. Проверка на вхождение абсолютно lightweight-задача.

P/invoke-ссылки из managed-объектов в native-объекты просто не располагаются в таблицах смещений ссылочных объектов. Т.е. ссылки на нативную память ещё в compile-time определяются как «value types» и gc просто не берёт их в расчёт (у нас же не консервативный GC который ничего не знает о типах!).

А вот в случае со стеком, ссылкам в стеке для скорости лучше вести себя как Boehm-GC, т.е. если присходит ложное срабатывание, то ничего плохого не происходит, мы просто отсрочиваем сборку данного объекта (кем бы он ни был), тем самым не повреждая ничго.

> Они взяли и решили проблему разных компиляторов.

Виндовое решение разных компиляторов и, даже, языков называется .Net. Там очень много известных недоделок C++ пофиксили. При этом искусственно создали новые.

Правда режет глаза? Впрочем привыкшие к kde интерфейсу глаза ничем уже не напугать.

>Правда режет глаза? Впрочем привыкшие к kde интерфейсу глаза ничем уже не напугать.

Я не про KDE, а про это:

«Давно понятно, что место для qt у параши»

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

Лишние люди

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

Это подтверждает мою теорию, что гномеры любят выдавать свои какие-то гномотехнологии за стандарт.

мою теорию, что гномеры любят выдавать

Теория хорошая, и возможно даже имеет право на жизнь, только где ты здесь гномеров увидел? Это каноникловцо-убунтоиды, я б их не путал с гномерами.

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

> ....вчерашний анонимус....

Сказал позавчерашний анонимус.

Тред не читал, но

>Язык программирования Python

Десктоп окружение GNOME

Core i7 с 32Gb RAM и NVidia GTX300+ впридачу ко всему этому идут? Или пользователям предлагается насладиться тормозами?

Не замечал.

> GObject - это объекная модель, которую можно использовать в Си, не более (а можно и не использовать).

Это модель из которой потом автоматически генерируются байндинги на ваш С++, пайтон и прочее

> Ну... Он как php, имеет небольшую нишу. Пихать всюду не стоит. Вон кактусом це-два-плюса до сих пор давимся.

У python порог вхождения ниже, чем у C. Да и многие вещи в нём делаются проще, например, работа с сетью и обработка текстовых конфигурационных файлов.

libglade deprecated же. Они хотели сказать gtk.builder.

Библиотека libglade и дизайнер интерфейсов Glade - это разные вещи.

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

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

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

>> GObject - это объекная модель, которую можно использовать в Си, не более (а можно и не использовать).

Это модель из которой потом автоматически не генерируются байндинги на ваш С++, пайтон и прочее

fxd

Или предъяви уже генераторы байндингов для Питона и Си++.

PyGTK - это питоновая обёртка для того же GTK+, реализованная в виде откомпилированного модуля. Ничего особо страшного я тут не вижу.

В качестве примеров можете глянуть на Sonata или Gajim, например.

> Swing - хоронит и QtGui, и Gtk, и Cairo.

Нельзя так не любить людей >_<