[посоветуйте][да будет срачъ]Надоела java

> C++: Qt и на винде, и на маке выглядит нативно.

Damn lie

GPL2 к патентам не имеет никакого отношения. GPL3 в явном виде гарантирует возможность использовать все патентованные технологии в производных работах. Какие от этого проблеммы? А у моно с лицензией все нормально, и не нужно мешать лицензии и патенты в одну кучу.

Зато PHP + JS + HTML5 везде будет выглядеть ненативно. А если еще учесть, что браузеры бывают разные, то вылезет еще и куча проблемм.

На appdb.winehq.org лень глянуть? Но зачем ее ставить в вайн?

>Проверяются только при коннекте/дисконнекте сигнала и слота.

Ага. В рантайме. Если прототип сигнала изменится, или просто где-то опечатка, то никаких ошибок компиляции, вообще ничего - мы узнаем об этом только в рантайме. И это на С++!

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

ты что-то делаешь не так или выбрал не тот тулкит.

Какие-то педиковатые ответы))

.Net решает, да.

Более десктопная проблема. Для разведки трудоемкости QT/GTK и тп.

Есть дерево, в основе - композит. Нужно его вывести в «TreeView», но для каждого типа данных свое оформление.

Заодно вопрос, есть ли в Qt аналоги Action из явы?

>Единственное ограничение «шаблонного» QObject'а - невозможность определения сигналов/слотов

Что есть невозможность использовать его по прямому назначению.

>Решается либо прямым использованием event'ов

Отлично! И тут мы пришли к тому, от чего в своё время пытались избавиться.

>> ни тебе множественного наследования куобжектов

Приведи пример, когда ты реально упираешься в это ограничение

Легко - набор интерфейсов, испускающих те или иные сигналы, имеющих те или иные слоты, и набор классов, реализующих разные комбинации этих интерфейсов.

>> ни тебе вложенных классов-куобжектов

4.2

4.2 на твоё 4.2:

#include "obj.hpp"

int main (int argc, char *argv[]) {
    (void) argc;
    (void) argv;
    return 0;
}

#ifndef __OBJ_HPP__
#define __OBJ_HPP__

#include <QObject>

class Foo: public QObject {
    Q_OBJECT

    class Bar: public QObject {
        Q_OBJECT
    };
};

#endif // __OBJ_HPP__

~/devel/qtsucks $ make
g++ -c -pipe -O2 -Wall -W -D_REENTRANT -DQT_WEBKIT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -I. -o main.o main.cpp
/usr/bin/moc-qt4 -DQT_WEBKIT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -I. obj.hpp -o moc_obj.cpp
obj.hpp:10: Error: Meta object features not supported for nested classes
make: *** [moc_obj.cpp] Error 1

Плохое наследство от первых версий Qt. И это таки мелочь, которая не может сделать годный тулкит говном.

QAction - не оно?

Я понятия не имею, что там за Action в яве

JavaScript хороший язык, лучше вашего хваленого питона.

Javascript для десктопных приложений? :D

А вот Lua вполне годен.

>Если прототип сигнала изменится
Необходимо осторожнее подходить к изменениям в архитектуре проекта.

просто где-то опечатка

При первом же тестовом запуске это обнаружится.

Другие варианты?

Практически Лисп. Замени всё. Остается только дождаться когда под него напишут все существующие либы

>Необходимо осторожнее подходить к изменениям в архитектуре проекта.

Класс, испускающий сигнал, может быть и не свой :)

При первом же тестовом запуске это обнаружится.

Да, но всё равно неприятно

>Надоела java

Выбери себе замену http://hyperpolyglot.org/

Десктопы меняются. Морда пусть будет на js, а бэкэнд может быть хоть на чем.

Для JS уже есть биндинги для нормальных гуйных тулкитов?

>Легко - набор интерфейсов, испускающих те или иные сигналы, имеющих те или иные слоты, и набор классов, реализующих разные комбинации этих интерфейсов.

Так не делай интерфейсы QObject'ами. Определи сигналы и слоты как чисто виртуальные методы и реализуй их в потомках.

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

В Qt5 это хотят поправить: http://developer.qt.nokia.com/wiki/New_Signal_Slot_Syntax

Ага, оно самое, пасибо

4.2 на твое 4.2:

#ifndef __OBJ_HPP__
#define __OBJ_HPP__

#include <QObject>

class Foo: public QObject {
    Q_OBJECT
    class Bar;
};

class Foo::Bar: public QObject {
    Q_OBJECT
};

#endif // __OBJ_HPP__

Ну слава Богу!

Вот это прикол. Тогда им стоило об этом сказать в том же #error

> Python: хм... даже не знаю...

Python + PySide

>но чтобы можно было пистаь на «все» (Win+Mac+Linux) платформы

Java тоже не всегда так умеет.

PHP :-)

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

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

Легко - набор интерфейсов, испускающих те или иные сигналы, имеющих те или иные слоты, и набор классов, реализующих разные комбинации этих интерфейсов.

Программируя на Qt, легко убедиться, что потомки QObject'ов, как правило, представляют собой описания объектов, обладающих законченной или практически законченной реализацией. Это следствие использования moc, ограничений C++ и общего подхода к дизайну фреймворка (а это, на секундочку, один из наиболее вменяемых API в мире C++ в принципе). Чисто теоретически претензия принимается, но она имеет смысл только в отрыве от того, что конкретно в Qt такая необходимость возникает опять же редко. Просто потому, что API вполне располагает к тому, чтобы с ней не столкнуться. Хотя, уверен, что поклонникам стандартной библиотеки и boost'a, желающим применить привычные подходы в Qt без всякой адаптации, батхерт обеспечен.

Отлично! И тут мы пришли к тому, от чего в своё время пытались избавиться.

Все зависит от задачи. Иногда прямое использование Qt'шных event'ов вполне оправдано. Кроме того, ты пропустил «или» в оригинальном посте, а конкретно - наследование от шаблонного QObject'a и определение сигналов/слотов в потомке, что абсолютно не является проблемой, «плохой практикой» и т.п.

4.2 на твоё 4.2:

Прошу прощения, показалось, что ты имел ввиду вложенные объекты. Нельзя совершенно точно сказать, что вложенные определения классов - это всегда очень плохо. Но вложенные определения «сложных» классов (а наследование от QObject это предполагает) - совершенно очевидный способ получить кочергой по е**лу от других участников проекта. Закинь свой классец в namespace detail и забудь.

Какие-то педиковатые ответы))

Ну если ты по-прежнему считаешь что перечислил железобетонные признаки «говна и зла», то ты явно слишком чувствительный парень.

Кстати, когда Qt5 выходит? Есть ли смысл учить 4.7 а потом переходить на 5 или сразу с 5го?

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

> Кстати, когда Qt5 выходит? Есть ли смысл учить 4.7 а потом переходить на 5 или сразу с 5го?

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

Qt5 - это будущее, и наступать оно будет постепенно.
Лучше прямо сейчас начать учить Qt4.7, он уже работает. Когда официально выйдет Qt5, докажет свою нужность и т.п., тогда можно переходить на него.

>гимп и варешарк на винде смотрятся вполне нормально

дооо, про гимп я промолчку, а вот, к примеру, Dia под виндой выглядела в старых версиях как говно

Qt5 - это будущее, и наступать оно будет постепенно.

Вместе с Nokia, очевидно. :)

>Даже на винде криво смотрится,

Даже на винде криво и ненативно смотрятся Dreamweaver, Photoshop, OpenOffice, Microsoft Office, Winamp, iTunes, Safari, Visual Studio. Но никто по этому поводу не печалится

Покажите уже «ужасный гтк на винде», а то я только dia и pidgin пользовался, проблем не заметил. Ну и как на макОС выглядит, хочу посмеяться.

А для Вас судьба нокии так очевидна?

а вот на «нативность» мне глубоко похрен и вам того же советую.

Некоторые идут ещё дальше: используют приложения, скажем, только на gtk или только на qt. С учётом общего (низкого) уровня развития софта зачастую проблема хоть каку-нить вменяемую софтину найти.

>dia
И ты хочешь сказать, что она хорошо выглядит? Когда мне приходилось ей пользоваться на винде (где-то 1,5 года назад) - dia выглядела ужасно. Сейчас что-то поменялось?

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

http://confluence.atlassian.com/download/attachments/166528194/CrucibleReview... вполне себе виндовенько

Сейчас что-то поменялось?

пользовался года четыре назад или ещё раньше. Выглядела так же как в линухе. Примерно так: http://my.opera.com/kurzon/blog/2009/02/08/visi . Были недоработки с прорисовкой, в остальном принципиальной разницы не почувствовал.

а проги на разных ЯП не бесят? :). Нет ненависти к php? :)

>Ну и как на макОС выглядит, хочу посмеяться.

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

Вот так? http://www.figuiere.net/hub/blog/images/gtk-mac-1.jpg Действительно страшноватенько.

У меня инкскейп даже похуже)

Кста, на твоем скрине gtk1 :)

Если тебе хочется тянуть все в веб - тяни. Мне нет, так что пхп мне не упал. А вообще, не бесят.

>Покажите уже «ужасный гтк на винде», а то я только dia и pidgin пользовался, проблем не заметил. Ну и как на макОС выглядит, хочу посмеяться.

да тот же pidgin на Windows 7

>Есть ли смысл учить 4.7 а потом переходить на 5 или сразу с 5го?

Большой разницы в API между 4.7, 4.8 и 5 нет и не ожидается. Более принципиальный вопрос: учить С++ или QML?

gedit на OS X:

http://dl.dropbox.com/u/1523274/tmp/Screen Shot 2011-09-03 at 22.03.27.png