«я имел в виду унификацию внешнего вида и библиотек…»
внешнего вида у библиотеки вообще нету…
Чтоб вы знали Qt не GUI фреймворк, он вообще под виндой рисует элементы чере WinAPI, в GTK+ через GTK виджеты а в QWS и KDE сам рисует в зависимости от выбраного стиля.
Внешнего вида у Qt нету как такового вообще. В отличие от GTK и wx.
Открою вам завесу, есть даже возможность запускать приложения с неродной ABI на линуксе, допустим приложение от Solaris может быть запущено на Linux.
Вообще не вижу связи между производительностью конкретного веб движка и Qt, Понятное дело что в Opera не дураки сидят, но причина ухода от Qt скорее всего в том, что они хотят иметь возможность запускать Opera на ограниченых устроствах, имея как можно меньше зависимостей и иметь это все в одном проекте. С таким подходом как в новой опере, это даст им возможность запускаться на любой платформе с Иксами (а иксы можно водрузить практически везде).
На данный момент у них есть Опера для голых иксов, есть опера с кути, есть опера на Direct-fb, вот ребята почесали голову и решили что все это нужно свернуть в одну кучу, а не вести все отдельно.
А то начали тут Qt тормозит.
Вот щас возьму, скачаю эту оперу и протестю на производительность против Arora на маке и под виндой. Для чистоты эксперемента нужно было бы еще под линукс, но уже когда выйдет тогда и потестим.
Так вот выложу тут результаты и посмотрим кто есть кто.
«главное преимущество Win это стандартизация и унификация»
Вот это весело, спасибо за порцию смеха. Можете разъяснить каким же таким стандартам и унификациям соотвествует Win? может POSIX? :-)))))))
«насколько я понимаю Qt — это частично открытый проект, ведь для коммерческого использования его применять без лицензирования нельзя… а с gtk таких ограничений нет…»
МММ поясните чем отличается GNU LGPL v. 2.1 в Qt от GNU LGPL v. 2.1 в GTK+ ???
Вот если не верите:
ну вобще из достоверных источников знаю что Qt использовалось только для построения гуи, на скорость построения дом, css, render деревьев это ни как не сказывалось. Отрисовка у них происходит опять же в своей канве, что с кути общего не имеет. По моему пустой наезд на кути.
Ради интереса можно сравнить эту новую оперу и допустим Arora (который построен на кути изначально) и посмотреть результаты. То что WebKit самый быстрый — я уже проверял, Opera и Safari самые быстрые и по JS и по отрисовке, и оба построены на WebKit.
как так никто не знал ????????????????????
iPhone, Palm Pre, Nokia N900, несколько моделей HTC (HD2 в частности)
Это очень популярная платформа (OMAP-3) а за OMAP-4 уже в очереди стоят, только вот один недостаток у TI'ных SOC'ов — очень дорогие, по сравнению с конкурентами. По этой причине на работе после ресеча была выбрана SH-4 архитектура от STI micro, дешевле на порядок, а в некоторых местах и лучше, единственное чего не хватает — 3Д ускоритель. Но обещают в следующем поколении.
Так что зря про то что никто не знает.
А ну это естественно если идти не по мной предложенному пути. В моем случае опять же такой штуки не будет (вернее Qt-style way).
Проверю это в GCC. Вроде он молчит в данном случае даже при -Wall
ну как раз это нужно только самому первому приватному классу, все остальные унаследуют у него. Получается позаботиться об этом нужно всего один раз, и особенно это актуально, если наследников будет писать кто-нибудь другой (например индус), и будет жаловаться что у него там не работает, а он допустим в приватный класс передал (0), так как было лень читать документацию что туда нужно ложить this. Так как нам в любом случае нужно в приватный класс положить именно этот this то не вижу необходимости это делать везде в иерархии, лучше сделать один раз в вершине дерева и забыть про это.
ну как по мне, так то что написал std, и Вы cyberbobs, не очень удобно, так как требует дополнительного параметра в конструктор приватного объекта.
По производительности никаких бонусов тут нет. Но строки Q_D(MyClass);
d->q_ptr = this;
будут присутствовать только в конструкторе самого базового объекта, в остальных же ничего подобного фигурировать не будет. А параметр конструктора приватного класса придется передавать во всей иерархии.
Поэтому в моем подходе конструктор наследника будет выглядеть таким образом: MyClassDerived::MyClassDerived(QObject *parent)
:MyClass(*new MyClassDerivedPrivate(), parent)
А в вашем: MyClassDerived::MyClassDerived(QObject *parent)
:MyClass(*new MyClassDerivedPrivate(this), parent)
поэтому достаточно спорно тут как лучше, мне кажется в моем варианте лучше, так как необязательно создавать конструктор, пусть будет конструктор по умолчанию, если необходимо просто проинициализировать q_ptr (и то если он нужен). А если он нужен, то это действие делается только в конструкторе одного объекта а не тянется вся эта эпопея с инициализацией в них. как минимум снижается риск, что в конструктор подчиненного объекта будет помещен не тот объект. То есть в моем случае код более «ошибкостойкий», опять же ИМХО. Хорошо, что С++ дают простор для фантазии :-)
А вот Linux kernel — это уже ядро.
внешнего вида у библиотеки вообще нету…
Чтоб вы знали Qt не GUI фреймворк, он вообще под виндой рисует элементы чере WinAPI, в GTK+ через GTK виджеты а в QWS и KDE сам рисует в зависимости от выбраного стиля.
Внешнего вида у Qt нету как такового вообще. В отличие от GTK и wx.
Открою вам завесу, есть даже возможность запускать приложения с неродной ABI на линуксе, допустим приложение от Solaris может быть запущено на Linux.
А вот о виндовз такого сказать точно нельзя.
На данный момент у них есть Опера для голых иксов, есть опера с кути, есть опера на Direct-fb, вот ребята почесали голову и решили что все это нужно свернуть в одну кучу, а не вести все отдельно.
А то начали тут Qt тормозит.
Вот щас возьму, скачаю эту оперу и протестю на производительность против Arora на маке и под виндой. Для чистоты эксперемента нужно было бы еще под линукс, но уже когда выйдет тогда и потестим.
Так вот выложу тут результаты и посмотрим кто есть кто.
www.gtk.org/
«главное что бы она была полностью открытая и прекратилась вся эта чехарда с Qt, GTK, wx»
Эти все библиотеки открытые, а в чем состоит чехорда ???
«вот, например, имеется у меня принтер Canon iP1500»
А причем здесь производители софта и разработчики *nix ??? обращайтесь в Canon.
Вот это весело, спасибо за порцию смеха. Можете разъяснить каким же таким стандартам и унификациям соотвествует Win? может POSIX? :-)))))))
«насколько я понимаю Qt — это частично открытый проект, ведь для коммерческого использования его применять без лицензирования нельзя… а с gtk таких ограничений нет…»
МММ поясните чем отличается GNU LGPL v. 2.1 в Qt от GNU LGPL v. 2.1 в GTK+ ???
Вот если не верите:
Ради интереса можно сравнить эту новую оперу и допустим Arora (который построен на кути изначально) и посмотреть результаты. То что WebKit самый быстрый — я уже проверял, Opera и Safari самые быстрые и по JS и по отрисовке, и оба построены на WebKit.
iPhone, Palm Pre, Nokia N900, несколько моделей HTC (HD2 в частности)
Это очень популярная платформа (OMAP-3) а за OMAP-4 уже в очереди стоят, только вот один недостаток у TI'ных SOC'ов — очень дорогие, по сравнению с конкурентами. По этой причине на работе после ресеча была выбрана SH-4 архитектура от STI micro, дешевле на порядок, а в некоторых местах и лучше, единственное чего не хватает — 3Д ускоритель. Но обещают в следующем поколении.
Так что зря про то что никто не знает.
qt.gitorious.org/qt-jambi
Проверю это в GCC. Вроде он молчит в данном случае даже при -Wall
qt.gitorious.org/qt/qt/blobs/master/src/corelib/kernel/qobject.cpp#line756
как мы видим стиль немного другой, но в общем подход тот-же.
По производительности никаких бонусов тут нет. Но строки
Q_D(MyClass);
d->q_ptr = this;
будут присутствовать только в конструкторе самого базового объекта, в остальных же ничего подобного фигурировать не будет. А параметр конструктора приватного класса придется передавать во всей иерархии.
Поэтому в моем подходе конструктор наследника будет выглядеть таким образом:
MyClassDerived::MyClassDerived(QObject *parent)
:MyClass(*new MyClassDerivedPrivate(), parent)
А в вашем:
MyClassDerived::MyClassDerived(QObject *parent)
:MyClass(*new MyClassDerivedPrivate(this), parent)
поэтому достаточно спорно тут как лучше, мне кажется в моем варианте лучше, так как необязательно создавать конструктор, пусть будет конструктор по умолчанию, если необходимо просто проинициализировать q_ptr (и то если он нужен). А если он нужен, то это действие делается только в конструкторе одного объекта а не тянется вся эта эпопея с инициализацией в них. как минимум снижается риск, что в конструктор подчиненного объекта будет помещен не тот объект. То есть в моем случае код более «ошибкостойкий», опять же ИМХО. Хорошо, что С++ дают простор для фантазии :-)