LINUX.ORG.RU

Nokia, Trolltech и цифры


0

0

Один из разработчиков KDE делится интересной информацией по поводу сделки Nokia-Trolltech. Числа встречаются нерадостные - оказывается, Trolltech на протяжении последних трёх лет несла серьёзные убытки. А ведь судьба KDE сильно от них зависела - теперь уже, правда, она зависит от воли Nokia.

>>> Подробности

★★★★★

Проверено: JB ()

Ответ на: комментарий от adarovsky

>в пятых - ты помнишь, во что разворачивается Q_SLOT

Если придираться, кстати, то не Q_SLOT, а Q_SLOTS. Для тех, кому просто slots не нравится.

adarovsky ★★★★
()
Ответ на: комментарий от adarovsky

>это — не виртуальная функция? Не делай мне смешно

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

>А вот что генерит moc, мне глубоко пофиг, потому как его отладили тролли.

гм. раздвоение личности. Что генерит MOC - пофиг, а что генерит на порядки более часто используемый препроцессор (и отлаженный соответственно) - не пофиг

>убиццо. повторяю, я понимаю тех, кто использует mono.

mono используют потому что можно использовать. Так же как питон, лисп, D и ещё кучу языков.

ЗЫ: shape_engine на моно вряд ли писать будут, так что пример - мимо кассы.

ЗЗЫ: на _не_ С вообще обычно пишут _приложения_ а не модули glib/gobject, если ты не в курсе.

geek ★★★
()
Ответ на: комментарий от adarovsky

>Если придираться, кстати, то не Q_SLOT, а Q_SLOTS. Для тех, кому просто slots не нравится.

а я точно не помню. Помню, что там ещё кучка директив для MOC'a есть

geek ★★★
()
Ответ на: комментарий от geek

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

ты невнимателен. Больному страшно смотреть в эти чудо-исходники.

>гм. раздвоение личности. Что генерит MOC - пофиг, а что генерит на порядки более часто используемый препроцессор (и отлаженный соответственно) - не пофиг

вопрос в том, что этот препроцессор приходится кормить кучей параметров. И не дай бог ошибиться

>ЗЗЫ: на _не_ С вообще обычно пишут _приложения_ а не модули glib/gobject, если ты не в курсе

пока не потребуется откастомайзить какой-нибудь элемент интерфейса. А там — ой

adarovsky ★★★★
()
Ответ на: комментарий от geek

>а я точно не помню. Помню, что там ещё кучка директив для MOC'a есть

Нет там никакой кучки :) Есть signals, slots, и Q_PROPERTY, чтобы из QtScript и прочих можно было живым приложением рулить. В Qt4 появились интерфейсы. Теперь можно через QVariant типобезопасно передавать свои типы, и делать плагины, валидность которых автоматом проверяется.

adarovsky ★★★★
()
Ответ на: комментарий от adarovsky

>ты невнимателен. Больному страшно смотреть в эти чудо-исходники.


чем struct A{

void (*fn)(GObject* obj);
}

страшнее

class A : Gobject
{
void A();
}


>вопрос в том, что этот препроцессор приходится кормить кучей параметров. И не дай бог ошибиться

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

А если ты неправильно директивы MOC заюзаешь - кто ССЗБ?

>пока не потребуется откастомайзить какой-нибудь элемент интерфейса. А там — ой

бгг http://www.gnome.org/~davyd/gnome-journal-cairo-article/clock-ex3.c

вот тебе сэмпл. Пальчиком тыкни - где там что страшное?



geek ★★★
()
Ответ на: комментарий от adarovsky

>Нет там никакой кучки :) Есть signals, slots, и Q_PROPERTY

больше одного - уже кучка

>Есть signals, slots, и Q_PROPERTY, чтобы из QtScript и прочих

сигналы, слоты и пропертисы - не для этого, емнип

>В Qt4 появились интерфейсы.

охренеть. Асилили к четвертой версии-то. Кстати, где они? Что-то я не нашёл.

>Теперь можно через QVariant

ох ты, неужели теперь биндинги будут не через жопу? Хотя вряд ли, замыканий там так и не появилось - придеццо пейсателям извращаться с мапперами

geek ★★★
()

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

p.s. юзаю обе и вижу у обоих будующее gtk ПОКА работает лучше, но qt разумнее сделан "уцелом" (c) надеюсь они - чтото у друг другам общее ... поимеют ;)

anonymous
()
Ответ на: комментарий от geek

> чем struct A{ void (*fn)(GObject* obj); } страшнее class A : Gobject { void A(); }

Тем, что мне этот (*fn)(GObject* obj); придётся потом указывать в таблице функций. Это задача компилятора, вообще-то.

virtual в c++ варианте забыл :)

>А если ты неправильно директивы MOC заюзаешь - кто ССЗБ?

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

>вот тебе сэмпл. Пальчиком тыкни - где там что страшное?

чудеса сверху и снизу. Этим должен заниматься транслятор.

adarovsky ★★★★
()
Ответ на: комментарий от geek

>сигналы, слоты и пропертисы - не для этого, емнип

однако, изменяет :) QtScript работает только через них, в Qt Designer в панели свойств информация тоже оттуда берётся

>охренеть. Асилили к четвертой версии-то. Кстати, где они? Что-то я не нашёл

Q_DECLARE_INTERFACE. Пример Plug & Paint. Признаться, я в этом месте ждал слова "велосипед" :)

>ох ты, неужели теперь биндинги будут не через жопу? Хотя вряд ли, замыканий там так и не появилось - придеццо пейсателям извращаться с мапперами

QVariant был и в третьей версии. qt_cast сделан для удобства наплюсистов

Биндинги и так на ура делались. См. PyQt и Qt Jambi.

adarovsky ★★★★
()
Ответ на: комментарий от adarovsky

>однако, изменяет :) QtScript работает только через них,

не колышет, через что работает QtScript. Факт в том, что слоты и сигналы _не_ _специально_ для этого ввели (причем давно, ага)

>Q_DECLARE_INTERFACE. Пример Plug & Paint. Признаться, я в этом месте ждал слова "велосипед" :)

struct MyInterface { }... где-то я это уже видел ;)

>Биндинги и так на ура делались. См. PyQt и Qt Jambi.

да видел я эти биндинги. Тихий ужос

geek ★★★
()
Ответ на: комментарий от adarovsky

>Тем, что мне этот (*fn)(GObject* obj); придётся потом указывать в таблице функций. Это задача компилятора, вообще-то.

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

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

http://www.linux.org.ru/view-message.jsp?msgid=2236791

>чудеса сверху и снизу. Этим должен заниматься транслятор.

как ты транслятору объяснишь, в каком формате нужно всё это хранить?

по поводу динамической системы типов ты что-нибудь ответил? А то я как-то пропустил наверное

geek ★★★
()
Ответ на: комментарий от geek

>http://www.linux.org.ru/view-message.jsp?msgid=2236791

если с помощью vala сгенерить исходники и не прицепить к проекту, то тоже ничего не слинкуется, ага

>как ты транслятору объяснишь, в каком формате нужно всё это хранить?

есть такой документ — C++ ABI

>по поводу динамической системы типов ты что-нибудь ответил? А то я как-то пропустил наверное

ы? ты о чём вообще? Я говорил о метаинформации, которая доступна во время исполнения, вообще-то. Типа явовской reflection, чтобы можно было приложения скриптовать

adarovsky ★★★★
()
Ответ на: комментарий от adarovsky

>если с помощью vala сгенерить исходники и не прицепить к проекту, то тоже ничего не слинкуется, ага

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

>есть такой документ — C++ ABI

да что ты говоришь...а где он есть? И как изменить? =)

>ы? ты о чём вообще? Я говорил о метаинформации, которая доступна во время исполнения, вообще-то. Типа явовской reflection, чтобы можно было приложения скриптовать

я о "в-третьих" в http://www.linux.org.ru/jump-message.jsp?msgid=2456288&cid=2461344

geek ★★★
()
Ответ на: комментарий от geek

>ну тык, вот тебе и пример, который ты "с трудом представляешь"

от этого приложение покрашилось, или что? Человек впервые qt увидел, и qmake использовать поленился.

>да что ты говоришь...а где он есть? И как изменить? =)

гугуль скажет. И это, стандарты — они для того, чтобы их соблюдать, а не для того, чтобы менять

>я о "в-третьих" в http://www.linux.org.ru/jump-message.jsp?msgid=2456288&cid=2461344

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

adarovsky ★★★★
()
Ответ на: комментарий от adarovsky

>от этого приложение покрашилось, или что? Человек впервые qt увидел, и qmake использовать поленился.

да ничего, просто тебе там макросы не нравяцо почему-то =)

>гугуль скажет.

гугль говорит, что у каждого компилятора C++ABI свой. Шо делать?

>И это, стандарты — они для того, чтобы их соблюдать, а не для того, чтобы менять

гг

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

в glib/gobject динамическая система типов. Я тебя про альтернативу спрашивал. А то, понимаешь ли, у glib/gobject есть нехилое преимущество - не нужны врапперы для подключения скриптов. Ну и гибкость опять же. Отсутствие привязки к компилятору. Манглинг опять-таки.

geek ★★★
()
Ответ на: комментарий от geek

>гугль говорит, что у каждого компилятора C++ABI свой. Шо делать?

The GNU C++ compiler uses an industry-standard C++ ABI starting with version 3. Details can be found in the ABI specification. (http://www.codesourcery.com/cxx-abi/abi.html)

>в glib/gobject динамическая система типов.

То есть, тип объекта может меняться в течение его жизни, чтоли? С чем боролись...

>Я тебя про альтернативу спрашивал. А то, понимаешь ли, у glib/gobject есть нехилое преимущество - не нужны врапперы для подключения скриптов. Ну и гибкость опять же. Отсутствие привязки к компилятору. Манглинг опять-таки.

Для подключения к Qt тоже не нужны. Принцип я описывал. Если хочешь расширять объектную модель, то придётся делать обёртку. Как и в случае с C, кстати, смотри на SWIG. Удобный C++ аналог - sip

adarovsky ★★★★
()
Ответ на: комментарий от adarovsky

>То есть, тип объекта может меняться в течение его жизни, чтоли? С чем боролись...

не только. А зачем с этим бороться? Чтобы потом приходилось в биндингах лепить по несколько оберток на класс, как это сделанос QEvent?

>Для подключения к Qt тоже не нужны.

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

>Как и в случае с C, кстати, смотри на SWIG.

А ты смотрел? =) SWIG обеспечивает проверку типов и автоматическое преобразование типов для C. Всё.

биндинги можно сделать тупым import dl, dl.open, dl.sym

>Удобный C++ аналог - sip

а sip заворачивает одни классы в другие и плодит функции, которые доступны из скрипта и разворачивают завернутые классы чтобы вызвать их методы =) А по-другому и никак, собсна

я уже жду фразы "пофиг, что там внутри"

=)

geek ★★★
()
Ответ на: комментарий от geek

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

Что-то я и для C вижу врапперы: http://www.swig.org/Doc1.1/HTML/SWIG.html#n5

>а sip заворачивает одни классы в другие и плодит функции, которые доступны из скрипта и разворачивают завернутые классы чтобы вызвать их методы =) А по-другому и никак, собсна

как и свиг

>я уже жду фразы "пофиг, что там внутри"

ты совершенно прав. Оверхеда нет, пишу эти врапперы не я. Мало того, для кошерного си их всё равно делают

adarovsky ★★★★
()
Ответ на: комментарий от anonymous

>Jambi вполне вменяемый биндинг. И НИ какого ужоса!

бгг.

geek ★★★
()
Ответ на: комментарий от adarovsky

>Что-то я и для C вижу врапперы: http://www.swig.org/Doc1.1/HTML/SWIG.html#n5

гы, это - опционально. В питоне ты и так можешь получить доступ к структуре и полям. Без всякого свига

>как и свиг

свиг - он все-таки и для плюсов. Тот же pygtk в свиге не нуждается

>ты совершенно прав. Оверхеда нет

оверхед есть. Не испарится же он

>Мало того, для кошерного си их всё равно делают

а кто им запретит? Можно делать. Можно не делать, а дергать прямым call

это же не с++, где тебя гвоздями прибили к врапперу

geek ★★★
()
Ответ на: комментарий от geek

>гы, это - опционально. В питоне ты и так можешь получить доступ к структуре и полям. Без всякого свига

как и к c++-структуре. Разница-то какая? Мы ведь не про поля говорим, а про "наследовать от" :)

Всё равно тебе GObject'овских крокодилов мапить на нормальную объектную модель

>свиг - он все-таки и для плюсов.

и для C.

>Тот же pygtk в свиге не нуждается

да я вижу. вы и таблицы виртуальных функций вручную пишете :)

>оверхед есть. Не испарится же он

несколько тактов, константный, пренебрежимо мал, по сравнению с замедлением из-за интерпретатора

>а кто им запретит? Можно делать. Можно не делать, а дергать прямым call

это будет программа на C, написанная на питоне

>это же не с++, где тебя гвоздями прибили к врапперу

зато не пишет каждый драйверы мыши :)

adarovsky ★★★★
()
Ответ на: комментарий от adarovsky

>как и к c++-структуре. Разница-то какая? Мы ведь не про поля говорим, а про "наследовать от" :)

гы, будешь, зарывшись в доки смотреть - где VT, где RTTI, а где начинаются собственно поля?

>да я вижу. вы и таблицы виртуальных функций вручную пишете :)

_мы_ мало что пишем руками. У _нас_ есть инструменты, ага.

>это будет программа на C, написанная на питоне

гениальная фраза нот антдестуд

>зато не пишет каждый драйверы мыши :)

это к чему вообще?

geek ★★★
()
Ответ на: комментарий от geek

>гы, будешь, зарывшись в доки смотреть - где VT, где RTTI, а где начинаются собственно поля?

наследую класс и во всех виртуальных функциях пропишет заглушки для вызова методов в унаследованном классе целевого рантайма (точнее, это всё sip сделает)

>_мы_ мало что пишем руками. У _нас_ есть инструменты, ага.

примером тому мега-хидер

>гениальная фраза нот антдестуд

перефразировка с "программу на фортране можно написать на любом языке"

>это к чему вообще?

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

adarovsky ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.