[c++] А есть ли какая альтернатива Qt?

Windows Forms, Visual C++ =) Вполне достойные штуки. Правда, только винды.

Ну а так что-то в голову ничего и не приходит. Походу нет такой замены.

Судя по последним течениям в рассылке, из Qt упорно делают JS-фреймворк.

4.2

Посмотрел ещё на boost.

совсем не то

Интересно, есть ли ещё что-нибудь в этом плане, чтобы можно было полноценно заменить Qt?

для С++ - нет, а вообще Gtk

Интересно, есть ли ещё что-нибудь в этом плане, чтобы можно было полноценно заменить Qt?

Его слишком раздули, что бы чем-то одним заменить. Хотя может Mono?

[c++]

tk

И?

Mono, [c++]... ???

>4.2

Странно, а тут уже обсуждают http://lists.qt.nokia.com/pipermail/qt5-feedback/2011-September/001013.html Выходит, врут?

http://www.mono-project.com/CPlusPlus

1. обсуждают, релиза ещё нет
2. «JS engine in QtCore», и что?
3. Qt останется С++ фреймворком
3. что не так с js?

>Его слишком раздули, что бы чем-то одним заменить.

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

Хотя может Mono?

Жирновато будет, да и не c++...

http://www.mono-project.com/CPlusPlus

это не аналог Qt

XUL

2. «JS engine in QtCore», и что? 3. Qt останется С++ фреймворком

В этих фразах есть явное противоречие.

3. что не так с js?

А, собственно, при чём тут js? Почему сразу не питон?

2. «JS engine in QtCore», и что? 3. Qt останется С++ фреймворком

В этих фразах есть явное противоречие.

ну так раскрой его, я никакого противоречия не вижу

>3. что не так с js?

А, собственно, при чём тут js? Почему сразу не питон?

подумай

>ну так раскрой его

Зачем?

подумай

Так я уже подумал и решил. Думать второй раз не вижу смысла.

А вообще, подожду более адекватных комментариев.

Думать второй раз не вижу смысла.

офисный планктон, такой важный

>XUL

Судя по файерфоксу, gtkmm/glibmm менее прожорливо будет.

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

Да никому сейчас десктопные приложения не нужны. А кому нужны вытерпят и кюте и все остальное.

>офисный планктон, такой важный

Тебя это сильно беспокоит?

> полноценно заменить Qt

Полноценно никак, даже если говорить только о GUI. На мой взгляд ближе всего wxWidgets (особенно если брать в расчет кроссплатформенность). В принципе больше и ничего нет.

Если не ошибаюсь, тут конкурирующая контора нарисовалась. Ладно, отвечу.

на JS гуй удобнее описывать и меньше возможностей себе в ногу выстрелить.

Думаю, на питоне таких возможностей ещё меньше. Но речь про c++.

Плюс ежели не хочется, то пиши весь гуй на с++ по старинке.

Так бессмысленно уже. Тащить с собой огромную неподдерживаемую библиотеку.

Юзайте Qt. Они говорили, что C++ останется навсегда.

Нет, писать на новом SceneGraph фреймворке. Ты не забывай, все эти qml обьекты это прежде всего С++ обьекты и спокойно юзаются вне js!

Питон в сравнении с JS фееричный тормоз.

>На мой взгляд ближе всего wxWidgets (особенно если брать в расчет кроссплатформенность). В принципе больше и ничего нет.

Пока тестил, оверхед относительно Qt имеет место быть. Может под Windows оно лучше в плане зависимостей? А то под Linux тащит gtk со всем зоопарком в виде glib/pango..

> Пока тестил, оверхед относительно Qt имеет место быть. Может под Windows оно лучше в плане зависимостей? А то под Linux тащит gtk со всем зоопарком в виде glib/pango..

под Windows лучше, а вот на маке это неюзабельное говно, которое одинаково хорошо не умеет ни carbon ни cocoa

>Нет, писать на новом SceneGraph фреймворке.

Так.., а там виджеты хоть есть? А то мне тут подсказывают, что это что-то совсем уж низкоорувневое и использовать его можно только через QtDeclarative со всем зоопарком. Кроме того, необходимость OpenGl ES 2.0 совсем не радует, особенно на встроенной интеловской видяхе.

>Питон в сравнении с JS фееричный тормоз.

Но это не значит, что надо выкручивать руки в сторону последнего. Да и вообще, нокиевцы вроде сами говорили, что в qml нет тяжёлых вычислений.

>Юзайте Qt. Они говорили, что C++ останется навсегда.

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

qml для описания гуя гораздо красивше выглядит нежели Питон.

Так.., а там виджеты хоть есть? А то мне тут подсказывают, что это что-то совсем уж низкоорувневое и использовать его можно только через QtDeclarative со всем зоопарком.

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

>qml для описания гуя гораздо красивше выглядит нежели Питон.

Это относительно. По мне, он выглядит также ужасно, как html вперемешку с js или php. Но речь идёт о другом. Если мы говорим о разметке, то js в qml можно заменить на python (или любой другой динамический язык). Но, видимо, выкрутить руки проще. Это меня и удручает.

C++ для гуя куда ужаснее выглядит и ничего, пишут же. Какие динамические языки у нас кроме js держат систему метатипов Qtшную? Для PySide или PyQt я уже могу спокойно создавать на С++ обьекты? Js не просто так туда гвоздями прибит. Да и по сути это всё равно скорее клей для плюсовых обьектов. И вообще, пусть лучше так будет, чем зоопарк динамических языков.

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

Ну не знаю. Пока меня запарили findChild-ы, чтобы хоть как-то достучаться до объектов из c++. Впрочем, и использование setProperty() на каждый чих тоже не добавляет простоты. Ошибся в тексте - компилятор проглотил. Не говоря уж про такие геморройные вещи, как QDeclarativeImageProvider и динамические интерфейсы. Не зря в доках советуют использовать js для минимизации взаимодействий между c++-кодом и qml.

>C++ для гуя куда ужаснее выглядит и ничего, пишут же.

Для гуя он выглядит ровно также, как и для js и даже python. Разметка гуёв в этих языках не предусмотрена, впрочем, они для этого и не создавались.

Qt 4

>Судя по последним течениям в рассылке, из Qt упорно делают JS-фреймворк.

Тьяго не даст, он с нами ;)

>Для PySide или PyQt я уже могу спокойно создавать на С++ обьекты?

Тоже самое могу сказать и про JS+Qml. Мало того, необходимо наследоваться от QOBject, так ещё и функции помечать как Q_INVOKABLE. Такое можно навернуть и для питона, если сильно захотеть.

>Qt 4

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

Для PyQt C++ объекты делаются тривиально с помощью утилиты sip. Как с этим обстоят дела в PySide не в курсе.

>Qt 4

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

>Для PyQt C++ объекты делаются тривиально с помощью утилиты sip

С qml это будет проблематично. Придётся, наверное, свой Declarative написать или что-то в этом роде, рисующее через scengraph. Хотя вроде собирались делать поддержку qml+python с трансляцией в qml+js.. В рассылке PyQt пробегало.

Может мне кто-нибудь внятно описать на что похожа архитектура Qt5 и к чему именно приделан qml?

Блин, ну прикрутят JS к QtCore, тебе-то какое дело? Не хочешь - не используй.

Развел тут нытик-тред.

Может мне кто-нибудь внятно описать на что похожа архитектура Qt5

на Qt4

Four big architectural changes:

• Re-architecture our graphics stack - We will put Qt Quick and the QML Scenegraph into the center of our new graphics architecture. QPainter will still be available and is very useful for many things, but it won’t be used for the main user interface. Qt will require OpenGL (ES) 2.0 to work. QWidgets will be layered on top of the scene graph (not the scene graph on top of QWidgets as is currently done with Qt 4).
• Base all Qt ports on Lighthouse - The Lighthouse project was started with the goal of providing a better way to abstract the window system integration than we currently are using. It’s now reaching maturity with Qt 4.8, and we intend on using it exclusively for all Qt ports in Qt 5.0.
• Modular repository structure - A lot of this work has been done over the last weeks and you can see the results in the new modular Qt repositories. The modularization of Qt will facilitate and speed up the possibility to integrate contributions to Qt.
• Separate all QWidget related functionality into its own library - While the QWidget based classes are extremely important for existing applications, we are, over time, going to move to a model where all UIs are being done in QML. Separating the QWidget based functionality into its own library is therefore a good measure to achieve a clean architecture in Qt 5 in the long term.

Да ладно вам, господа хорошие... Последнее десятилетие показало что программировать интерфейсы по принципу «разметка»/«оформление»/«клиентский код»/«серверный код» намного удобнее чем с помощью классов в приплюснутом коде. И набившая оскомину MVC прекрасно встраивается в такой интерфейс, и командную работу проще организовать, и прототипирование и много других вещей.... «Ajax-Rich-Applications» / «Adobe AIR»/ «QML»... Нокиевцы не первые, это тренд.

Ты думаешь неправильно. Вероятно у тебя битые сегменты в мозге есть.
Ну и модуль ЧСВ надо заменить на исправный, а то этот что-то зашкаливает.