Russian Qt Forum

Trolltech недавно прислали письмо о выходе Qt Jambi Technology Preview. Из любопытства глянул - да-а, выглядит крайне любопытно. Как-то и Java стала менее убого выглядеть: во-первых, это возможность разрабатывать на Java графические приложения (да ещё с помощью Qt Designer!), которые не тормозят, во-вторых - всё изящество Qt и тут доступно (например, сигналы и слоты, в том числе и для сокетов, к примеру), из-за чего большая часть корявости Java (вроде громоздких селектов nio и всяких Listener'ов) пропадает.

Теперь, значит, Qt не только кросс-платформенная, но и кросс-языковая технология. C++, Python, Java - пиши на чём хочешь. Причём Qt Jambi даёт возможность писать часть приложения на C++, а часть - на Java.

Я вообще не шибко люблю жабу, но тут она вдруг стала смотреться гораздо приятней. Кому интересно - читаем, качаем, пробуем:
http://www.trolltech.com/company/newsroom/announcements/press.2006-07-14.7914556269/

По мне Жабьи  Listeners, гораздо прозрачнее Qt сигнал - слотов...
Так как они часть языка! А не расширение, которое потом пропадает при moc обработке. Потом Swing не менее мощен чем Qt.
Потом есть же SWT. :) Qt уже не первая...
Во вторых, не знаю как оно пойдёт, но ведь основная беда Qt это коммерческая версия, т.е. если пишешь на java там нет никаких cost. Ставь пиши, продавай... Всё доступно.
С Qt слинковать не получиться...
Eclipse тоже есть в недрах IBM, вернее SWT обвязанная вокпуг Qt, и только несовместимость лицензий вынудила IBM отказаться от его публикования.

Так что...

Не понял, что куда пропадает, но по-моему



и



по прозрачности примерно одинаковы (в лучшем случае), а вот по компактности, изящности и читаемости Qt Jambi явный лидер. Да, а moc тут вообще нет, сигналы тут - это объекты специального класса.

С лицензиями действительно лажа. Для свободного ПО под GPL это, однако, никакого значения не имеет. У коммерческих потребителей будут проблемы, да. Хотя это они ещё сначала должны прикинуть, что выгоднее - писать бесплатно на чистой жабе или потратить деньги на лицензию Qt, но и сэкономить на времени разработки и получить более качественный продукт. Ну и от стоимости всё будет зависеть, конечно же.

SWT и Swing - непростительные тормоза. Непростительные буквально. В Windows это ещё не очень заметно, в Unix же на приличной машине они перегружают X настолько, что их даже программным продуктом назвать нельзя - больше, чем на грубый прототип они не тянут. У меня например при запуске Azureus становится невозможно играть в Vavoom и смотреть видео из-за лагов, хотя тот всего лишь отображает прогресс закачки с помощью SWT! Qt же помимо переносимости всегда славился и быстродействием, а поскольку в Qt Jambi основная библиотека всё та же, на C++, то работает оно так же резво. Вроде в SWT идея та же, но разница почему-то очень заметная.

Я бы привёл в пример адаптеры...
а не листенеры, потом анонимные классы, позволяют избавиться от проверки условий вызова мотодов.
Код выполниться только здесь!
Всё таки Qt это десктоп библиотека, а ява больше платформа.
Потом в энтерпрайз секторе где рулит Java EE и NET всем плевать на скорость, главное стабильность и масштабируемость!
Потом Swing-application можно через java web start вызвать не как апплет, а как приложение.
Сможет ли оно подгрузить qt не знаю..
но вот SWT вроде бы не видел...
Мне кажеться места там уже заняты, и тролли не смогут потеснить M$ и java...
Лучше б занялись доводкой до ума фич новых...
Но если хотят, пусть пробуют...

добавлено спустя 3 минуты:

 Потом сектор Java уже устаканился. Есть Swing, в котором есть все навороты. SWT и та идёт с трудом, а они ведь бесплатны.
По моему, если пишешь для десктоп пиши на qt, если на заказ в компанию на java...
Потом скажем если надо юзать оракл, скажем халявный но оракл - заказчик упёрся, Qt - без коммерческой версии этого сделать не позволит, к бАльшому сожалению...

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

А вот декстопные приложения, особенно свободные, на Java - дерьмо, все, что я видел. Ни одним пользоваться не смог, либо тормозит, либо глючит (доходит вплоть до того, что с левой жабой - работает, а с официальным релизом - не хочет), либо просто есть более вменяемые аналоги. Но вообще-то потенциал тут в жабу заложен нехилый, просто реализовать его в силу ряда причин (одна из них - невероятная тормознутость графики) не получается. И тут вдруг появляется возможность присоединить к жабе мощь Qt! Вернее наоборот ^_^

Если бы ещё Sun опомнился и сделал жабу хотя бы наполовину такой же переносимой, как Qt (читай: чтобы нормально шло под Unix в широком смысле ^_^) - уже был бы приличный продукт, а не универсальный микроскоп для забивания корпоративных гвоздей.

Это точно, но вот блин беда, от этих горе java программеров, которые сейчас начнут пробовать переписывать всё через Qt, больше вреда чем пользы...
УЖ если Qt неАсилили :) лучшеб и не брались :)...

Мне кажется, что Тролли это и хотят - спихнуть Жабу и ДотНет с рынка как можно дальше. Надеюсь, что у них получится.

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

http://www.trolltech.com/developer/downloads/qt/qtjambi-techpreview

Я не очень понял. А во что это будет собираться, в какой код?

Даже представить страшно :(...
Java сама не самолёт, Qt тоде не реактивная, что даст смесь этих йадов :)...

Код, написанный на C++ будет собираться в родные библиотеки (so, DLL), а код, написанный на жабе, будет к ним обращаться. Точно также, как жаба обращается к классам Qt, написанным на C++.

При грамотном применении даёт очень хороший результат. Грамотное применение - это когда поменьше вызовов туда-сюда и разделение подчинено разумной логике. То есть на жабе можно писать, к примеру, высокоуровневую логику, а на C++ - высокоэффективные компоненты, например, работу с сетью, с графикой, операции, требующие грамотного использования памяти (что в жабе нереально) и т. п. В принципе жаба и так это всю жизнь позволяла через JNI (часть жабы написана на C++), но Qt Jambi это дело сильно упрощает и автоматизирует. Насколько сильно - не знаю, не пробовал.

Возможен ли обратный вариант (приложение на C++ использует библиотеку на жабе) - Хрен его знает, но сомнительно, да и зачем такой изврат?

Преимущество жабы над всем, что есть на сегодняшний день в том, что .jar созданный на стандартном Sunовском или IBMовском JDK (использовать другой, без необходимости считается плохим тоном) запустится без проблем на любой JVM (или у меня не те .jar? :-). А если JVM у вас нет, то всё, что вам потребуется, - прогуляться на java.sun.com и скачать её оттуда (это касательно windows, к линям в дистры и так сановский jvm укладывается).  

И до тех пор, пока Jampi или SWT не войдут в стандартную поставку JVM (сертифицированную Sun), нормальные жаба программисты не будут использовать.
IBM для продвижения swt уже сделал не мало, но используется он лишь в виде базы для JFace/Eclipse. Так вот для создания RCP намного более привлекателен уже готовый Eclipse RCP.

А Jambi где использовать? Красивые десктопы писать хотите? На Qt и Java? Так по памяти всё= пролетите при использовании хотя бы одного класса. Без JVM никуда не деться. И десктоп приложение, на Qt жрущее +50 метров (использовать один класс - смешно и всё= 30 метров) просто так, юзер не оценит.

Qt - прекрасный фрэймворк для С++ программиста, значитально упрощающий разработку GUI и смежные задачи. И необходимость вязать к нему "мощь Java" (кстати, в чем же она, кроме простоты и кросплатформенности) не существует просто потому, что в Qt это и так уже всё сделано.

ЗЫ: Azareus построен на древнем Eclipse RCP 3.0 (там тормоза вообще везде и никуда от них не денешься), но это проблема Azareus и только. Давно уже есть более совершенный Eclipse.

ЗЫ2: Listener в Java не встроены, это вообще интерфейсы по 10 строчек каждый. В Java реализован чистый ООП и внутренние классы с интерфейсами, которые позволяют реализовывать паттерны значительно проще, чем где либо. Listener всего лишь реализация MVC модели, на котором построен Swing.

ЗЫ3: по поводу десктопов: есть две красивых кросплатформенных штуковины, которые я использую в повседневной жизни: OpenOffice2(03) и Eclipse 3.1/2. Чем они тормознуты?

А если у вас не Windows, то можете выкинуть этот .jar в помойку, как только поймёте, что под вашу платформу (NetBSD, OpenBSD, ...) жабы просто не существует. Это к вопросу о переносимости жабы. Под FreeBSD (наверное, 3-ю по популярности систему после Linux) она выходит, к примеру, с запозданием года на два и с большим скрипом. Хотя как надо умудриться написать приложение, чтобы оно нормально работало под Linux, но не хотело работать под FreeBSD - лично мне совсем не понятно.

Мощь жабы как раз не в кроссплатформенности (жаба гораздо менее переносима, чем C и C++, что легко проверяется экспериментально) и тем более не простоте (Где она в жабе?! Кому нужна простота, учите Python.), а в огромной стандартной библиотеке, плюс большом наборе дополнительных библиотек (Log4j и другие проекты Apache, например). Qt же, в отличие от жабы, перегруженной функциональностью не отличался особо никогда, так что там многого нет (java.math - ещё один пример).

Что касается всяких разных метров и необходимости что-то устанавливать - в наше время это уже не так актуально, с ростом объёмов памяти и доступности Интернета. Даже в России безлимитный Интернет и гиг памяти уже не диковинка, что там говорить о цивилизованных странах...


OpenOffice2(03) - это OpenOffice.org 2? Так то C++. Хоть и тормозит почти как жаба (но всё же меньше, да).
Eclipse - вы пробовали его запустить не на Windows? Тормозов более чем достаточно. Или в 3.1 что-то сильно изменилось после 3.0 в этом смысле?

по поводу OpenOffice (именно ooo у меня professional 203 от инфраресурса)
1) есть в OpenOffice фолдер /program/classes а там лежит много .jar и судя по размеру и названиям там куча логики
2) размер soffice.bin в памяти после запуска ни о чём не говорит?
3) ooo есть свободный расширенный com.sun.staroffice.
а то, что у него там куча dll, это похоже оптимизаторы вкрученной в soffice.bin jvm через JNI механизм. Так что с++ там постольку поскольку.

по поводу eclipse:
под линём работает товарищ anli насколько я понимаю. http://prog.org.ru/forum/lhtopic_384_0_0_asc_.html

по поводу кроссплатформенности:
C++ может и переносим, но принцип write once - run anywhere ни к одному приложению C++ не применим по определению. К тому же переносимость обеспечивается за счёт работы с одними и теми же (или совместимыми) либами crt,qt. Иначе придётся код править. И при использовании JNI в Java классы тоже перестают быть кросплатформенными.

по поводу стандартной библиотеки:
проект apache.jakarta штука, конечно, хорошая, и стандартная библиотека конечно не ограниченная, но ни то ни другое совсем не обширны. Стандартная библиотека очень хорошо укомплектована самыми нужными прикладнику инструментами(а вовсе не перегружена).  И нескоро ещё количество библиотек для Java покроют то, что было создано для C++ за (кажется 30 лет?). Касательно java.math.(Поэтому сравнивать Java и Qt  вообще некорректно)

Qt позволяет писать прикладное ПО на С++ с той же простотой, что и на java(имхо). В книжке Ж.Бланшет сказано, что C++ нравится программистам, судя по-всему, именно за это. Использование сигнал-слотов вместо листенера не даёт никаких преимуществ, и похоже нацелено на более мягкий переход к Java у Qt программистов (MVC всё-таки паттерн) а сигнал-слот - замена колбэку. А работать с  двумя разными механизма работы с контролами в одном коде... это ведь и патологию головы вызвать может.

По поводу .jar:
если у меня не виндовс, то у меня линь десктопный, макос или юникс от IBM,Sun или HP, в конце-концов нетварь какая-нибудь (даже у нас в режимных организациях именно так, фри нигде нету кроме как на серваках). Европейский рынок  ориентирован на пользователя, а не на windows или админов. Отсутствие дистрибутивов jvm для FreeBSD от Sun лишнее тому подтверждение. А FreeBSD может и третья по распространённости, но только в снг  у людей, близких к IT-сфере.  И никто среди производителей JVM(Sun,IBM,Intel,BEA) .jar выкидывать не собирается. Кстати, под нетварь Qt есть? :-)

по поводу простоты: Java значительно куда более проста для понимания (не сложнее паскаля 5.5, с более ранним не работал), чем C++ который до конца, наверно, не знает никто. А питон... он же даже не компилятор?

Итого: на Jambi должно быть сделано что-то толстое и очень вкусное, чтобы всем нравилось и заставило-таки работать с Jambi, либо его должен признать Sun и упаковать в jvm. Иначе распространения она не получит. Использовать же Java из qtшного ПО.. да, круто, но не более. Излишняя трате ресурсов и проблемы при отладке С++ в паре с Java. И вообще, как выглядит прикладная задача на Java, которую нельзя сделать на С++ и Qt?

придётся отказаться от исследования FreeBSD... на ней нет Java. Кстати, а не пробовали привернуть  JVM от соляриса или линукса? Чем они отличаются-то? JVM 6.0 Sun планирует выложить в opensource, наверно тогда под фрю сделают нормальный JVM.

OpenOffice.org написан на C++ и прекрасно работает вообще без жабы. Жаба там нужна для каких-то невнятных фич, которые лично мне никогда не нужны были:
http://download.openoffice.org/2.0.3/java.html

Я пробовал работать в Eclipse под GNU/Linux и FreeBSD на четвёртом пне с 512 МБ мозгов. Тормозит, но работать можно. Но в Qt Designer я работал и на третьем пне 533 МГц со 128 МБ мозгов! Попытки запустить на аналогичном комьютере Eclipse успехом не завершились - просто виснет при запуске. IntelliJ IDEA запускается, но страшно лагает.


Согласен. Единственное свойство жабы, имеющее отношение к кроссплатформенности. Но кому оно надо? Для свободного софта переносимость бинарного кода ничего не даёт, а коммерческий частенько ограничивается Windows, Linux и Mac, и живёт себе счастливо.

Что же касается библиотек, то тут проблема не в их наличии (тут C кого хошь переплюнет), а как раз в кроссплатформенности. Если как язык жаба заметно уступает кроссплатформенности тому же C++ (что следует хотя бы из того, что половина самой жабы написана на C++), то с библиотеками у неё дело обстоит очень хорошо. Потом, если использовать Qt, например, то библиотеками, использующими, к примеру, для строк что-то отличное от QString, становится просто неудобно работать. То есть жаба тут хороша не только и не столько обилием библиотек, сколько их переносимостью и, что самое главное, интегрируемостью!

Насчёт простоты не согласен. Я писал в IntelliJ IDEA, на Swing и на C++/Qt. Код, написанный на Qt, более изящен и компактен. И эффективен. И о многочисленных подпроцессах не приходится париться. Впрочем, главное тут всё же быстродействие. Swing был бы вполне удобен, если бы не его дикие тормоза.

Отсутствие дистрибутивов JVM для FreeBSD (точнее, их запаздывающий выход) - подтверждение тому, что в Sun не умеют писать под Unix. Правильно написаный код вообще работает почти в любом юниксе без проблем, тем паче в FreeBSD. Как они умудрились сделать жабу только под Линукс (а также сделать отдельные версии для Linux и Solaris) - это вообще чудо какое-то. Специально старались, что ли? Вот когда они действительно сделают жабу свободной и открытой, тогда ситуация должна резко измениться. Тот же Qt ведь имеет единый исходный код для всех разновидностей Unix/X11 и оно прекрасно всюду компилируется и работает. И код очень хорошо написан - понятно, обозримо. И процесс сборки такой же прозрачный. В отличие от жабы, которая при сборке жрёт пару гигов пространства, причём по большей части на создание копий одного и того же в чуть разных вариантах с разными именами, а также многочисленных архивов.

О простоте. Я изучал и жабу, и C++. С поверхности - оба языка достаточно простые (C++ изучал три дня со знанием C, жабу - где-то неделю). В глубине же - чёрти-что и сбоку бантик. Достаточно почитать Java Language Specification, чтобы убедиться. Другой разговор, что ни там, ни сям большая часть наворотов никому не нужна.


Тут всё-таки дело во-первых в быстродействии графических компонентов, а во-вторых, не в том, что сделать можно и нельзя, а в том, что сделать проще и что проще отладить, то есть в высокоуровневости жабы как языка программирования. Во всяком случае, я до сих пор не видел ни одной задачи, решённой на жабе, которую нельзя было бы решить быстрее, проще и лучше на чём-то другом. И сильно сомневался вообще в существовании таких задач и пригодности жабы для чего-то, кроме, быть может, упомянутых крупномасштабных производственных приложений. И то даже в их случае мне сомнительно, что нельзя их было как-нибудь реализовать в виде независимых модулей вообще на разных языках. Qt Jambi меняет эту ситуацию явно в лучшую сторону (не знаю правда, насколько существенно). Кое-чего стоит и то, что в FAQ Trolltech написано, что основной причиной создания Qt Jambi послужили многочисленные пожелания клиентов иметь нечто подобное.

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

По поводу FreeBSD: я же сказал, выходит с запозданием на два года. То есть таки выходит! Сертифицированная жаба 1.5.0 под FreeBSD есть. До этого была несертифицированная 1.4.2 (патченая линуксовая, собираемая из исходников) и нормально работала (вот Azureus под ней работает, а под сертифицированной - нет, вот тебе и переносимость ^_^). Ещё раньше вполне можно было использовать любую жабу под Linux, запуская её в режиме эмуляции, но оно подглючивало.

А ты не правил *.ini eclipse и IDEA?
Просто размар отводимой для них памяти ничтожно мал, учитывая размер и сложность этих программ.
IDEA по умолчанию юзает всего 192 Мегабайта, eclipse 256.
Я поставил 512, ты знаешь eclipse просто ЛЕТАЕТ, причём по Suse 10.1 быстрее, чем под виндой!
Java работает быстро при хороших объёмах памяти...
У меня Атлон64 3000+ и 1,5 ГБ оперативки, так вот если позволяет объём надо отдавать побольше.
Коллега заядлый java ист, писал складскую программу на свинге, толкали на Cel 600, 256 метров, сама программа работала быстро, единственный минус java (на данный момент), в 6й версии обещали исправить это долгий запуск, связанный со структурой classloader и верификации классов. Classloader вроде уже переписаль, по ощущениям люди говорят, стартует всё гораздо быстрее чем на 5.

Насчёт памяти я не подумал. Может быть, но пока это всё равно проблема. Вот ещё через пару лет, когда памяти станет ещё больше...

Ну посмотрим. Всё равно сомнительно, что Swing сможет хотя бы сравниться с Qt. Всё-таки ядро графических компонентов должно быть на C/C++ написано, мне кажется тут у AWT был более правильный подход.

И ещё Qt Designer, да. Жабе сильно не хватает чего-то подобного. Имеющиеся средства всё-таки не так удобны.

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

Это отчасти так, но с другой стороны, если язык объектно-ориентрированный, то частенько бывает и наоборот - с С++ проще. Взять тот же PyQt. То есть, конечно, если бы Qt был на С, то его всё равно к питону можно было бы привязать без проблем, но удобство пользования бы как сильно пострадало...

Правда? А сколько в памяти занимает soffice.bin без открытых документов?
компонент Base (который недавно появился и активно рекламируется сейчас), движок JavaScript, целый ряд мастеров и визуальные эффекты accesibility. SDK тоже на Java рассчитано. К чему бы это?
А для редактирования текстовых документов кому-то и фара достаточно.
Очень интересное предположение. Обязательно проверю в ближайшее время. Странно всё это.
Про JVM под фрю и подобные оси уже всё понятно.И что? Разве речь идёт о методиках разработки свободного софта? Jambi вроде так же входит в коммерческую версию qt, и тролли рассчитывают, что jambi будет приносить прибыль за счёт java-разработчиков. Open source версия qt существует в первую очередь для рекламных целей. Так что же такое кросплатформенность?конечно же уступает в кросплатформенности в общем, и как язык в частности :-)
Sun постарались, безусловно.так она же не кросплаторменная?
А без QString работать не так уж и неудобно. Нужно просто уметь работать с char*.Ну вы бы код привели? Слабо верится :-)Насколько я знаю, в IDEA интерфейс рисуется в редакторе и код скрыт. А если интерфейс писать руками, так и Qt Designer ни к чему.с подпроцессами в swing париться нужно, чтобы загрузку организовать и живучесть интерфейса при исполнении длительных операций, если же простой диалог, никаких подпроцессов там не надо. Лучше таких вещей никому не говорить :-)Если писать на станартном CRT, так ещё и в винде этот код будет работать без проблем  ;)  Вам приходилось сталкиваться с различиями Sparc Solaris и Power Linux? :-)  К сведению: в каждой JVM сидит JIT компилятор и транслирует байткод в нативный машинный код процессора и запуски системных функций. Вот поэтому JVM для всех разные. потому что это единство и рассчитано на X11 и CRT :-)это kaffe-то? :-) спасибо за подсказку, ни в жизни теперь этим заниматься не буду :))Т.е. вы хотите сказать, что ни то ни другое вы не знаете совсем? Собственно я так и полагал. Тогда к чему высказывать свои суждения (в большинстве случаев неверных в данном случае) таким количеством эмоциональных необуманных реплик? Замечательный документ, на самом деле. Просто он как и вариацонное исчисление - не для всех.С отладкой в Java всё значительно проще - бинарник везде одинаковый :-)по секрету: проблема не в быстроте разработки, а в сложности "переделки" :-)
не могу понять пока, куда это можно прилепить.
а на ПХП весь мир этот веб программирует без проблем :-)сертифицированная-то она на поддержку Pure Java 1.5, это не значит, что она работает как Sunовская или IBMовская. Отсуствие jvm под эту ось у передовых производителей JVM говорит о том, что BSD поддерживать никто не собирается.

ЗЫ: по поводу скорости графических компонентов: AWT устарел и его использование не оправдано. Давно существует SWT, который избавляет UI от тяжести Swing, никак при этом не отличаясь в использовании. И построен SWT как Qt: под винду на Win32 API, под мак - на карбоне, а под X11 на gtk! Вот на него и грешить надо.