Задаю здесь, а не в Средства разработки или, не дай Бог, Священные войны, т.к. интересует именно приложение к C++, более того, под Win32.
Вопросы простые:
1) Использует ли кто Qt или GTK+ или и то, и другое, или что-то еще для GUI.
2) Что проще для изучения, с чем проще начать (просто взять и без особых проблем начать писать, типа как Delphi в свое время), я знаю, что для GTK+ есть специальные редакторы, один из них идет в комплекте, для Qt -- не знаю. Может кто подскажет, как проще использовать. Короче, что более удобно для изучения и использования.
3) Может у кого есть информация, что более эффективно? Знаю, что GTK+ жрет меньше памяти. Больше -- не в курсе. Или может даже есть мнение за чем будущее? (Может за чем-то еще, кроме этих двух, а сюда не стоит и соваться?) Вроде как Nokia выбрала Qt, Motorola -- GTK+. С лицензией вроде как у GTK+ попроще.
Короче, что учить и использовать (или вообще что-то другое).
Спасибо.
05.08.09 11:56: Перенесено модератором из 'C/C++' — Кодт
Если для Windows то WTL или MFC. Все это эффективнее (по памяти) чем тобою означенные системы. Плюс все это нативное для Windows.
WTL она правда токмо для настояшших мушшин которые знают буквы CRTP. И там и там есть class wizards и UI (dialog) editors.
Ну и само собой не лишне упомянуть что вот настояшши художники юзают htmlayout:
Здравствуйте, vadimcher, Вы писали:
V>Задаю здесь, а не в Средства разработки или, не дай Бог, Священные войны, т.к. интересует именно приложение к C++, более того, под Win32.
.. V>3) Может у кого есть информация, что более эффективно? Знаю, что GTK+ жрет меньше памяти. Больше -- не в курсе. Или может даже есть мнение за чем будущее? (Может за чем-то еще, кроме этих двух, а сюда не стоит и соваться?) Вроде как Nokia выбрала Qt, Motorola -- GTK+. С лицензией вроде как у GTK+ попроще.
Моторола использовала Qt в linux-телефонах (т.н. linuxjava).
Сейчас и у Qt тоже классная лицензия — LGPL. Работает (субъективно) шустрее GTK.
Есть нормальное IDE — QtCreator. Есть возможность использовать html, с неплохим javascript binding-ом к Qt-объектам.
Html рендерит очень хорошо. Ну и там еще куча вкусностей, только доки читай
Здравствуйте, vadimcher, Вы писали:
V>Задаю здесь, а не в Средства разработки или, не дай Бог, Священные войны, т.к. интересует именно приложение к C++, более того, под Win32.
V>Вопросы простые: V>1) Использует ли кто Qt или GTK+ или и то, и другое, или что-то еще для GUI. V>2) Что проще для изучения, с чем проще начать (просто взять и без особых проблем начать писать, типа как Delphi в свое время), я знаю, что для GTK+ есть специальные редакторы, один из них идет в комплекте, для Qt -- не знаю. Может кто подскажет, как проще использовать. Короче, что более удобно для изучения и использования. V>3) Может у кого есть информация, что более эффективно? Знаю, что GTK+ жрет меньше памяти. Больше -- не в курсе. Или может даже есть мнение за чем будущее? (Может за чем-то еще, кроме этих двух, а сюда не стоит и соваться?) Вроде как Nokia выбрала Qt, Motorola -- GTK+. С лицензией вроде как у GTK+ попроще.
V>Короче, что учить и использовать (или вообще что-то другое).
V>Спасибо.
Пишу на Qt уже несколько лет, с GTK+ не знаком поэтому могу сказать только о Qt.
И так что ты получаешь.
1 Отличный кроссплатформенный framework. Поддерживаеться Windows, Mac OS, множество Unix/Linux платформ
2 Отличная(хорошо продуманная) ООП модель, это как раз не мало важно при изучении
3 Отличная документация, хорошие примеры
4 + Много-много разных вкусностей
5 Лицензий их теперь 3 — коммерческая, GPL, LGPL
Насчет редакторов есть как уже говорили QtCreator — родная среда разработки. но я к примеру пользуюсь той же студией иногда просто обычным редактором при этом вобще не чувствую никаких затруднений. Для любителей "всего в одном" есть интеграторы для студии и eclips.
Здравствуйте, c-smile, Вы писали:
CS>Ну и само собой не лишне упомянуть что вот настояшши художники юзают htmlayout:
Когда уже *nix будет? не говоря уже о mac...
Приветствую, Сергей Савостин, вы писали:
СС> S>А кто мешает пользовать в кутэ поддержку css для интерфейса, СС> ну, если тянуть Qt только ради html интерфейса, то htmllayout imho полегче
Возможно. Но не стоит забывать что красивый интерфейс и на кутэ написать можно.
У кутэ же огромных 2 плюса — кроссплатформенность и универсальность. Тоесть можно писать любые приложения, использую только Qt, а потом запускать их на всех поддерживаемых платформах.
ИМХО, gtk попроще, ибо фич там поменьше. Но для гуя без извращенных требований — вполне себе неплох.
Однако под винду почему-то не так много gtk-приложений (и то это по большей части порты из линупсов).
V>2) Что проще для изучения, с чем проще начать (просто взять и без особых проблем начать писать, типа как Delphi в свое время), я знаю, что для GTK+ есть специальные редакторы, один из них идет в комплекте, для Qt -- не знаю. Может кто подскажет, как проще использовать. Короче, что более удобно для изучения и использования.
По-моему wxWidgets проще всего изучить — эта простая библиотека без никому ненужных наворотов, но зато с продвинутыми интерфейсами:
Редакторы Code::Blocks, DialogBlocks и wxFormBuilder
V>3) Может у кого есть информация, что более эффективно? Знаю, что GTK+ жрет меньше памяти. Больше -- не в курсе. Или может даже есть мнение за чем будущее? (Может за чем-то еще, кроме этих двух, а сюда не стоит и соваться?) Вроде как Nokia выбрала Qt, Motorola -- GTK+. С лицензией вроде как у GTK+ попроще.
Здесь wxWidgets вне конкуренции. Поскольку она использует контролы из системы, а не тащит свои, она занимает на порядок меньше места и памяти во время работы.
Здравствуйте, Mr.Cat, Вы писали:
MC>ИМХО, gtk попроще, ибо фич там поменьше. Но для гуя без извращенных требований — вполне себе неплох. MC>Однако под винду почему-то не так много gtk-приложений (и то это по большей части порты из линупсов).
Gtk под винду довольно коряв, перепутанные кнопки и страшные диалоги.
_>Здесь wxWidgets вне конкуренции. Поскольку она использует контролы из системы, а не тащит свои, она занимает на порядок меньше места и памяти во время работы.
Родные контролы — это как бы хорошо. А что с расширяемостью этих контролов? Любой контрол на Qt можно абклассныть и извратить до невозможности, и это прокатит на любой платформе. А wxWidgets?
Здравствуйте, MasterZiv, Вы писали: MZ>У меня по крайней мере 3 стоит. И замечательно работают.
Не, ну то, что они работают — это никто не спорит. Сам тот же гимп юзаю.
Просто мало таких приложений почему-то. Тут вот высказывается идея, что gtk плохо рисует под виндой. Хз, у меня и гимп, и xchat, и pidgin неплохо выглядели. Возможно, дело в том, что нужно вместе с аппликухой и gtk тянуть (метров 20, если с динамической линковкой делать), а с повторным использованием уже установленных либ в винде вроде бы бида (Была? Но вот у того же питона до сих пор как минимум 2 несовместимых сборки под винду).
Здравствуйте, astral_marine, Вы писали: _>Здесь wxWidgets вне конкуренции. Поскольку она использует контролы из системы, а не тащит свои, она занимает на порядок меньше места и памяти во время работы.
+1. А под никсами будет по сути тот же gtk, ибо бэкэнд.
Здравствуйте, astral_marine, Вы писали: _>Здесь wxWidgets вне конкуренции. Поскольку она использует контролы из системы, _>а не тащит свои, она занимает на порядок меньше места и памяти во время работы.
Родные контролы это хорошо для определенного уровня приложений.
И это жутко узкий уровень. По мне нативные контролы так это не плюс совсем.
Уж лучше хороший инструмент для создания нужных контролов.
Вот пара-тройка моих самописных:
Простой колор-чузер.
выбор типа рамки:
ну и собственно табличный редактор:
подробности тут: http://code.google.com/p/unnstudioreport/
Так, что уж лучше иметь хороший мощный механизм имплементации контролов,
чем скудный набор из нативных.
M>Родные контролы — это как бы хорошо. А что с расширяемостью этих контролов? Любой контрол на Qt можно абклассныть и извратить до невозможности, и это прокатит на любой платформе. А wxWidgets?
Приведенный Шериданом пример имеет очень сильные ограничения, что никак не подпадает под понятие "извратить до невозможности".
А легко это можно сделать, наследуешся от wxControl и выебываешся перед пользователем до умопомрачения последнего.
T>Уж лучше хороший инструмент для создания нужных контролов.
А еще лучше когда родные контролы дополняются самописными на платформах, где они не реализованы. Например wxGrid реализуется как самописный контрол: wxGrid
и wxPropertyGrid<br />
T>Вот пара-тройка моих самописных: T>Простой колор-чузер.
Нафига изобретать велосипед, если это уже в wxWidgets реализовано лет десять назад? Прорисовка в wxOwnerDrawnComboBox позволяет легко изменять фоновой рисунок в выпадающем списке<br /> Выбор цвета также имеет привычный вид для пользователя: (wxColourDialog)<br />
T>Так, что уж лучше иметь хороший мощный механизм имплементации контролов, чем скудный набор из нативных.
А еще лучше иметь родные контролы, которые дополняются мощным механизмом имплементации контролов из wxWidgets. (Примеры выше)
Здравствуйте, astral_marine, Вы писали: T>>Уж лучше хороший инструмент для создания нужных контролов. _>А еще лучше когда родные контролы дополняются самописными на платформах, где они не реализованы. Например wxGrid реализуется как самописный контрол:
А группировки и секции твой wxGrid делать умеет? А в xml сохраняться/восстанавливаться? T>>Вот пара-тройка моих самописных: T>>Простой колор-чузер. _>Нафига изобретать велосипед, если это уже в wxWidgets реализовано лет десять назад?
Нафига? Шас расскажу. Фишка в том, что не всякий программист
есть хороший цветовой дизайнер, и давая ему выбор из хорошо подобранных НЕСКОЛЬКИХ цветов мы ускоряем его работу, причем ничто не мешает мне добавить в контрол кнопку для выбора произвольного цвета.
T>>Так, что уж лучше иметь хороший мощный механизм имплементации контролов, чем скудный набор из нативных. _>А еще лучше иметь родные контролы, которые дополняются мощным механизмом имплементации контролов из wxWidgets. (Примеры выше)
Лучше иметь контролы хорошо приспособленные к выполнению задачи и хорошую систему их имплементации.
Для каждой индивидуальной задачи свои требования.
Вот этот wxGrid я полагаю жутко универсальная вещь перепичканная возможностями.
Я врятле рискну его применять где либо, потому, что он избыточен для одних задач, слишком абстрактен для других и недостаточен для третьих, но подходит для 4-го рода задачь .
ПС. кстати, че ты меня в велосипедостроении упрекаешь,
если твои контролы на wx написаны, а я пишу на Qt и у них куча отличий
мозгом то пораскинь ))
a> M>Родные контролы — это как бы хорошо. А что с расширяемостью этих контролов? Любой контрол на Qt можно абклассныть и извратить до невозможности, и это прокатит на любой платформе. А wxWidgets?
a> Приведенный Шериданом пример имеет очень сильные ограничения, что никак не подпадает под понятие "извратить до невозможности".
Я не Шеридана пример имел в виду
a> А легко это можно сделать, наследуешся от wxControl и выебываешся перед пользователем до умопомрачения последнего.
То есть все делать руками? Не, ну его нафиг. Если я хочу, например, отсабкласситься от банальной кнопки?
a> T>Уж лучше хороший инструмент для создания нужных контролов.
a> А еще лучше когда родные контролы дополняются самописными на платформах, где они не реализованы. Например wxGrid реализуется как самописный контрол: wxGrid http://www.simpol.com/guiimages/wxgrid.jpg[/img]
Если на каждый чих надо рисовать контрол с нуля — в топку. Потому что Qt тоже позволяет создать любой контрол с нуля. Но при этом Qt позволяет расширить функциональность любого контрола.
Здравствуйте, Сергей Савостин, Вы писали:
СС>Здравствуйте, c-smile, Вы писали:
CS>>Ну и само собой не лишне упомянуть что вот настояшши художники юзают htmlayout: СС>Когда уже *nix будет? не говоря уже о mac...
Я сам вот делаю порт в свободное от основной разработки время.
Но вроде как вот Cyberax со товарищи в рамках своего проекта "Java, Swing & Htmlayout"
собираются тоже порт сделать под Unix. У них по идее мотивация сильнее — должно раньше получиться.
M>То есть все делать руками? Не, ну его нафиг. Если я хочу, например, отсабкласситься от банальной кнопки? M>Ты предстаавляешь, сколько времени понадобится, чтобы это дело реализовать с нуля? Гораздо лучше — это сделать сабкласс существующего контрола и дописать требуемую функциональность
M>Кстати, каким образом достигается нормальный вид эих гридов на разных платформах? то кодируется вручную программистом или все же есть щастя?
Если нет родной поддержки для контрола, то другого выхода нет, чем использовать свой эмулятор. Здесь уже ничего не поделаешь. К счастью на большинстве платформ контролы совпадают и можно использовать в подавляющем большинстве случаев только родные контролы.
M>На этом примере мы, кстати, видим убогость реализации (виндовая стрека вниз проглядывает из-за самонарисованой)
Везде есть баги. Это всего лишь пример рисования. Реальные баги это когда контролы Qt и GTK+ отличаются от родных, а таких примеров — море.
Да, в wxWidgets есть свой пример нестадартного диалога выбора цвета, его можно взять за основу.
M>Если на каждый чих надо рисовать контрол с нуля — в топку. Потому что Qt тоже позволяет создать любой контрол с нуля. Но при этом Qt позволяет расширить функциональность любого контрола.
Qt позволяет лишь заебывать пользователя нестандартными цветами, а возможность расширения контролов там крайне убогая.
T>Для каждой индивидуальной задачи свои требования. T>Вот этот wxGrid я полагаю жутко универсальная вещь перепичканная возможностями. T>Я врятле рискну его применять где либо, потому, что он избыточен для одних задач, слишком абстрактен для других и недостаточен для третьих, но подходит для 4-го рода задачь .
Т.е. под каждые требования новый грид?
Я считаю, что если в гриде есть возможность объединять колонки, а это не требуется в конкретной задаче, то это не значит что надо писать свой велосипед вместо существующего грида.
Здравствуйте, astral_marine, Вы писали:
M>>То есть все делать руками? Не, ну его нафиг. Если я хочу, например, отсабкласситься от банальной кнопки? M>>Ты предстаавляешь, сколько времени понадобится, чтобы это дело реализовать с нуля? Гораздо лучше — это сделать сабкласс существующего контрола и дописать требуемую функциональность
_>Сабклассинг имеет очень сильные ограничения и не позволяет задрочить пользователя изменениями. А реализация собственой кнопки — это примитивная операция, которая не всегда оправдывает использование тяжелых расширителей.
a>>> и wxPropertyGrid<br />
<span class='lineQuote level3'>a>>> http://hiphotos.baidu.com/tigerjgh/pic/item/2029fa506c2d255c1038c2d2.jpg</span>
M>>Кстати, каким образом достигается нормальный вид эих гридов на разных платформах? то кодируется вручную программистом или все же есть щастя?
_>Если нет родной поддержки для контрола, то другого выхода нет, чем использовать свой эмулятор. Здесь уже ничего не поделаешь. К счастью на большинстве платформ контролы совпадают и можно использовать в подавляющем большинстве случаев только родные контролы.
M>>На этом примере мы, кстати, видим убогость реализации (виндовая стрека вниз проглядывает из-за самонарисованой) _>Везде есть баги. Это всего лишь пример рисования. Реальные баги это когда контролы Qt и GTK+ отличаются от родных, а таких примеров — море.
a>>> Выбор цвета также имеет привычный вид для пользователя: (wxColourDialog)<br />
<span class='lineQuote level3'>a>>> http://www.simpol.com/guiimages/wxcolorselector.jpg</span>
M>>Иногда может потребоваться реализовать нестандартный диалог выбора цвета, например:
_>Да, в wxWidgets есть свой пример нестадартного диалога выбора цвета, его можно взять за основу.
M>>Если на каждый чих надо рисовать контрол с нуля — в топку. Потому что Qt тоже позволяет создать любой контрол с нуля. Но при этом Qt позволяет расширить функциональность любого контрола. _>Qt позволяет лишь заебывать пользователя нестандартными цветами, а возможность расширения контролов там крайне убогая.
T>>Для каждой индивидуальной задачи свои требования. T>>Вот этот wxGrid я полагаю жутко универсальная вещь перепичканная возможностями. T>>Я врятле рискну его применять где либо, потому, что он избыточен для одних задач, слишком абстрактен для других и недостаточен для третьих, но подходит для 4-го рода задачь .
_>Т.е. под каждые требования новый грид? _>Я считаю, что если в гриде есть возможность объединять колонки, а это не требуется в конкретной задаче, то это не значит что надо писать свой велосипед вместо существующего грида.
Да и не смотря на такую "убогость" Qt становиться де-факто стандартом кроссплатформенного программирования и стал основой для KDE(де-факто стандартным WM для Linux) Да и вообще ваш пост провоцирует начала холивара чего просил не устраивать автор темы, поэтому попрошу не оскорблять(и воздержаться от нецензурных слов) горячо любимую мою библиотеку которая к тому же дает мне хлеб насущный
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, vadimcher, Вы писали:
CS>Если для Windows то WTL или MFC. Все это эффективнее (по памяти) чем тобою означенные системы. Плюс все это нативное для Windows. CS>WTL она правда токмо для настояшших мушшин которые знают буквы CRTP. И там и там есть class wizards и UI (dialog) editors. CS>Ну и само собой не лишне упомянуть что вот настояшши художники юзают htmlayout: CS>
А htmlayout поддерживает javascript?
В Qt очень вкусный биндинг к яваскрипту:
class QObjectDescendant : public QObject
{
Q_OBJECT
Q_PROPERTY(speed READ speed WRITE setSpeed)
public:
int speed() const;
void setSpeed(int speed);
public slot:
void jsCallback(const QString& str1, const QString& str2);
};
...
webFrame->addToJavaScriptWindowObject("qobjDesc", qobjectDescendantInstance);
и потом используем в яваскрипте —
function doSomething() {
qobjDesc.speed = 1234;
qobjDesc.jsCallback("sdaf", "dfg");
}
Приветствую, c-smile, вы писали:
c> СС>Когда уже *nix будет? не говоря уже о mac... c> Я сам вот делаю порт в свободное от основной разработки время. c> Но вроде как вот Cyberax со товарищи в рамках своего проекта "Java, Swing & Htmlayout" c> собираются тоже порт сделать под Unix. У них по идее мотивация сильнее — должно раньше получиться.
Здравствуйте, astral_marine, Вы писали: M>>На этом примере мы, кстати, видим убогость реализации (виндовая стрека вниз проглядывает из-за самонарисованой) _>Везде есть баги. Это всего лишь пример рисования. Реальные баги это когда контролы Qt и GTK+ отличаются от родных, а таких примеров — море. родные контролы это догмат и ретроградство. их раз-два и опчелся:
поле ввода, флажек, чекбокс, кнопка, дерево, список, дататайминпут, сплитер, скролбар.... все.
остальные все экстеншены или спец-контролы. и тут уже они в зависимости от задачи наворачиваются программистом:
диаграммы, табличные редакторы, ричэдит-подобные контролы и их экстенсивы, редакторы карт, сцены в Qt и т.п.
тут уже догматные предрассудки ограничивают как цепь для собаки. тут надо исходить из задачи, из удобства а ты это багом называешь.
акстись.
M>>Если на каждый чих надо рисовать контрол с нуля — в топку. Потому что Qt тоже позволяет создать любой контрол с нуля. Но при этом Qt позволяет расширить функциональность любого контрола. _>Qt позволяет лишь заебывать пользователя нестандартными цветами, а возможность расширения контролов там крайне убогая.
угу. вспомнил своего школьного учителя физики.
он про таких говорил: "- техника в руках дикаря — кусок металла.".
_>Т.е. под каждые требования новый грид?
естественно. У моего несколько главных целей:
— быстрое макетирование шаблона печатного документа.
— программное формирование отчета на основе макета.
— печать
я и мысли не держу использовать его как вьюв и/или редактор для базы данных. он не подходит вообще.
под эти цели я планирую взять и адаптировать контрол из 1с++ этот: http://www.1cpp.ru/docum/html/TableField.html#id3
_>Я считаю, что если в гриде есть возможность объединять колонки, а это не требуется в конкретной задаче, _>то это не значит что надо писать свой велосипед вместо существующего грида.
вот тут ты правильно думаешь, но я знаю много интересных особенностей
гридов, делающих их очень удобными в работе, и если не найду действительно
стоящего контрола, то сяду и напишу нужный. морока конечно, но опыт есть и
пользователи будут довольны а это деньги и главная цель девелопмента
Здравствуйте, astral_marine, Вы писали: T>>Вот пара-тройка моих самописных: T>>Простой колор-чузер. _>Нафига изобретать велосипед, если это уже в wxWidgets реализовано лет десять назад? [url=http://docs.wxwidgets.org/trunk/classwx_owner_drawn_combo_box.html]
кстати при разработке моего контрола я руководствовался скоростью выбора типа рамки при работе с макетом.
в моем виджете выбор рамки делается в один клик: т.к. они все навиду.
в твоем же контроле необходимо сначала кликнуть на кнопку раскрытия списка а потом выбрать нужный, а если не дай бог список еще и не все отображает, прийдется подергать скрол.
вот казалось бы такие мелочи, но они подтолкнули меня на пару часов работы над новым контролом.
надеюсь будущие девелоперы оценят мои старания
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, c-smile, вы писали:
c>> СС>Когда уже *nix будет? не говоря уже о mac... c>> Я сам вот делаю порт в свободное от основной разработки время. c>> Но вроде как вот Cyberax со товарищи в рамках своего проекта "Java, Swing & Htmlayout" c>> собираются тоже порт сделать под Unix. У них по идее мотивация сильнее — должно раньше получиться.
S>Так чем не устраивает то css в Qt?
Mr.Cat пишет:
> Просто мало таких приложений почему-то. Тут вот высказывается идея, что > gtk плохо рисует под виндой. Хз, у меня и гимп, и xchat, и pidgin
Ты знаешь, у меня такое ощущение, что оно под виндой чуть ли не лучше рисует,
чем под линухом.
a> M>То есть все делать руками? Не, ну его нафиг. Если я хочу, например, отсабкласситься от банальной кнопки? a> M>Ты предстаавляешь, сколько времени понадобится, чтобы это дело реализовать с нуля? Гораздо лучше — это сделать сабкласс существующего контрола и дописать требуемую функциональность
a> Сабклассинг имеет очень сильные ограничения и не позволяет задрочить пользователя изменениями.
Что значит сильные ограничения? В чем они проявляются? Что значит «задрочить пользователя изменениями». Почему сабклассинг этого не позволяет?
a> А реализация собственой кнопки — это примитивная операция, которая не всегда оправдывает использование тяжелых расширителей.
То есть тем же wxWidgets надо реализовывать, по сути, два движка? Один — эмулятор, один — поддержка родных контролов?
a> M>На этом примере мы, кстати, видим убогость реализации (виндовая стрека вниз проглядывает из-за самонарисованой)
a> Везде есть баги. Это всего лишь пример рисования. Реальные баги это когда контролы Qt и GTK+ отличаются от родных, а таких примеров — море.
a> M>Если на каждый чих надо рисовать контрол с нуля — в топку. Потому что Qt тоже позволяет создать любой контрол с нуля. Но при этом Qt позволяет расширить функциональность любого контрола.
a> Qt позволяет лишь заебывать пользователя нестандартными цветами, а возможность расширения контролов там крайне убогая.
Я так понимаю, это сказано, опираясь лишь на предоставленные Шериданом скриншоты?
M>Что значит сильные ограничения? В чем они проявляются? Что значит «задрочить пользователя изменениями». Почему сабклассинг этого не позволяет? M>Что значит «тяжелые расширители»? 0_о
Основная возможность этих контролов — это игнорировать цвета и прочие параметры, которые пользователь выбрал в системе, ничего существенного они не привносят.
M>То есть тем же wxWidgets надо реализовывать, по сути, два движка? Один — эмулятор, один — поддержка родных контролов?
wxWidgets — это не Qt, самописные контролы — это всего лишь дополнение к нативным, которые пишутся в случае:
1. Ни одна платформа не поддерживает контролы, они есть лишь в третьих библиотеках
2. Одна из платформ не поддерживает контрол, он пишется на основании поведения на других платформах.
Контролы, которые приходится эмулировать, пишутся максимально приближенно к родным и используют наиболее близкий класс. Например кнопка с рисунком — это наследник от родной кропки, а не от просто прямоугольник на родной форме операционной системы как в Qt.
_>>Т.е. под каждые требования новый грид? T>естественно.
Если вы отрицаете повторное использование кода, то мне уже нечего на это ответить. :(
Впрочем это уже никак не относится к данной теме.
S>Да и не смотря на такую "убогость" Qt становиться де-факто стандартом кроссплатформенного программирования и стал основой для KDE(де-факто стандартным WM для Linux)
Вот уже 10 лет становится, все никак не может стать. А стандартный DE под дистрибутивы это GNOME, а не KDE — его выбирали Fedora, Debian, OpenSUSE, Ubuntu и другие ведущие дистрибутивы Linux.
GTK+ — родной под GNOME, Qt — родной под KDE, wxWidgets — родной под Windows, GNOME и Mac OS X. А под Windows Qt это всего лишь портированный KDE с взятыми из системы цветами, и поэтому под новую версию операционной системы надо писать новую цветовую схему. И это вы называете "кроссплатформенностью"? X11 тоже можно запускать под Windows, и он тоже такой же "кросплатформенный" — там даже цвета не берутся из системы и ни одна уважающая себя фирма так не делает.
Здравствуйте, vadimcher, Вы писали:
V>Задаю здесь, а не в Средства разработки или, не дай Бог, Священные войны, т.к. интересует именно приложение к C++, более того, под Win32.
V>Вопросы простые: V>1) Использует ли кто Qt или GTK+ или и то, и другое, или что-то еще для GUI. V>2) Что проще для изучения, с чем проще начать (просто взять и без особых проблем начать писать, типа как Delphi в свое время), я знаю, что для GTK+ есть специальные редакторы, один из них идет в комплекте, для Qt -- не знаю. Может кто подскажет, как проще использовать. Короче, что более удобно для изучения и использования. V>3) Может у кого есть информация, что более эффективно? Знаю, что GTK+ жрет меньше памяти. Больше -- не в курсе. Или может даже есть мнение за чем будущее? (Может за чем-то еще, кроме этих двух, а сюда не стоит и соваться?) Вроде как Nokia выбрала Qt, Motorola -- GTK+. С лицензией вроде как у GTK+ попроще.
V>Короче, что учить и использовать (или вообще что-то другое).
V>Спасибо.
В общем, что я понял (если где не прав или не так понял, то поправьте):
Первое. Есть два типа кроссплатформенных библиотек. Первый -- поддерживающий родные компоненты для каждой системы, второй -- реализующий свои компоненты, работающие под (почти) всеми системами.
Второе. Самыми распространенными/проработанными/эффективными/... являются для первого типа -- wxWidgets, для второго -- как раз упомянутые мной GTK+ и Qt.
Третье. У каждого типа есть свои плюсы.
Первый тип (родные компоненты):
а) более эффективно
б) родной, близкий пользователю (каждой системы) интерфейс
Второй тип:
а) противоположный пункту б) выше эффект -- одни и те же "ожидания" от компонент на всех системах
б) более богатый выбор компонент
Четвертое. Для второго типа большинство из тех, кто ответил, отдают предпочтение Qt по причине того, что она менее глючная (я, кстати, перестал использовать Gimp именно по причине того, что у меня на системе она страшно глючила) и более продуманная, более того, как я понял, Qt переродился в своего рода стандарт (может я не так/не то прочитал?). Кроме того, я видел, что wxWidgets и Qt -- нативные C++шные, в отличие от GTK+. Однако, для разработки коммерческого ПО GTK+ предоставляет "свободную" лицензию, в отличие от Qt.
Пятое. Что не спрашивай, как не проси -- все равно все превратится в СВ.
Вывод: гляну в следующем порядке (прошу прощения у всех фанатов того или иного решения, порядок не имеет никакого отношения к тому, что лучше или хуже -- мне нужно выбрать какой-то порядок): Qt, wxWidgets, GTK+.
В связи с этим два вопроса.
1) Какое IDE лучше использовать, например, можно ли просто добавить поддержку в VS 2008, а может генерить родными средствами, а затем использовать то, к чему привык?
2) "Оптимальное" руководство, типа "*** за 10000 секунд".
Угу Qt почти платформа, поэтому появление фанатов неизбежно
V>Вывод: гляну в следующем порядке (прошу прощения у всех фанатов того или иного решения, порядок не имеет никакого отношения к тому, что лучше или хуже -- мне нужно выбрать какой-то порядок): Qt, wxWidgets, GTK+.
V>В связи с этим два вопроса. V>1) Какое IDE лучше использовать, например, можно ли просто добавить поддержку в VS 2008, а может генерить родными средствами, а затем использовать то, к чему привык?
У Qt c IDE неплохо во первых есть плагин для студии и eclipse, во вторых свое IDE Qt Creator правда по моему пока глючноватое.
У Gtk есть штатный конструктор форм Glade
У wx куча разных от мощных коммерческих, до недоделаных OS конструкторов форм http://wiki.wxwidgets.org/Tools
V>2) "Оптимальное" руководство, типа "*** за 10000 секунд".
Для wx есть неплохие книжки
"Cross-Platform GUI Programming with wxWidgets"
"WxPython in Action"
Для обоих в сети валяются куски русских переводов.
Здравствуйте, trdm, Вы писали:
T>ПС. кстати, че ты меня в велосипедостроении упрекаешь, T>если твои контролы на wx написаны, а я пишу на Qt и у них куча отличий T>мозгом то пораскинь ))
V>Первый тип (родные компоненты): V>а) более эффективно V>б) родной, близкий пользователю (каждой системы) интерфейс V>Второй тип: V>а) противоположный пункту б) выше эффект -- одни и те же "ожидания" от компонент на всех системах V>б) более богатый выбор компонент
Да, кстати наиболее одинаково ведет на всех платформах только X11 — она в этом плане уверен бесспорный лидер. Она практически полностью игнорирует системные настройки.
"более богатый выбор компонент" это спорно, wxWidgets имеет очень и очень продвинутые контролы. Вот есть wxAUI, wxGrid и wxPropertyGrid. Я так и не нашел ихние аналоги в Qt и GTK+, может мне кто подскажет? Скриншоты wxGrid и wxPropertyGrid я уже приводил. wxAUI — это фреймворк табов, который реализован в Code::Blocks, DialogBlocks и wxFormBuilder (скриншоты тоже выше) или вот:
V>Четвертое. Для второго типа большинство из тех, кто ответил, отдают предпочтение Qt по причине того, что она менее глючная (я, кстати, перестал использовать Gimp именно по причине того, что у меня на системе она страшно глючила)
GTK+ под Windows и OS X действительно довольно глюкавый, Qt получше GTK+ эмулирует контролы на Windows, но все равно есть отличия от родных.
V> и более продуманная
Это спорно, я считаю wxWidgets более продуманной чем Qt, а Qt — раздутой безделушками и без необходимых возможностей. Поклониики GTK+ думаю ее свою библиотеку тоже считают продуманной.
Т.е. это понятие субъективно и единственный способ это проверить пройтись по в отладке и посмотреть как разумно она работает.
V> более того, как я понял, Qt переродился в своего рода стандарт (может я не так/не то прочитал?).
Стандартная библиотека — это только STL, среди графических нет такого понятия, популярны как минимум 4 — GTK+, Qt, X11 и wxWidgets.
V> Кроме того, я видел, что wxWidgets и Qt -- нативные C++шные, в отличие от GTK+.
Qt и wxWidgets — С++ билиотеки, GTK+ — чисто Сишная библиотека с легкой С++ обверткой.
V> Однако, для разработки коммерческого ПО GTK+ предоставляет "свободную" лицензию, в отличие от Qt.
GTK+ и Qt обязывают линковать только динамические (DLL) коммерчиские версии, а wxWidgets — еще и статические, что влияет на размер инсталляции и сложность ее создания. В случае wxWidgets можно сделать так, что установка будет заключаться в простом копировании одного главного EXE файла.
V>В связи с этим два вопроса. V>1) Какое IDE лучше использовать, например, можно ли просто добавить поддержку в VS 2008, а может генерить родными средствами, а затем использовать то, к чему привык?
В wxWidgets есть созданные проекты для Visual C++, ничего дополнительно устанавливать не надо, кроме самой библиотеки. Они находятся в wxWidgets/build/msw
V>2) "Оптимальное" руководство, типа "*** за 10000 секунд".
Можно начать отсюда http://docs.wxwidgets.org/trunk/ или Гугла.
Но проще мене оказалось собрать minimal пример и начать с него изучение в отладке. А потому уже остальные примеры.
Здравствуйте, Сергей Савостин, Вы писали:
CS>>Ну и само собой не лишне упомянуть что вот настояшши художники юзают htmlayout: СС>Когда уже *nix будет? не говоря уже о mac...
Под *nix будет точно, видимо с backend'ом на QT (я этим сейчас занимаюсь).
Под Mac лучше кроссплатформенный код не писать, а использовать местные инструменты — очень они уж специфические.
a> M>То есть все делать руками? Не, ну его нафиг. Если я хочу, например, отсабкласситься от банальной кнопки? a> M>Ты предстаавляешь, сколько времени понадобится, чтобы это дело реализовать с нуля? Гораздо лучше — это сделать сабкласс существующего контрола и дописать требуемую функциональность
a> Сабклассинг имеет очень сильные ограничения и не позволяет задрочить пользователя изменениями.
Что значит сильные ограничения? В чем они проявляются? Что значит «задрочить пользователя изменениями». Почему сабклассинг этого не позволяет?
a> А реализация собственой кнопки — это примитивная операция, которая не всегда оправдывает использование тяжелых расширителей.
То есть тем же wxWidgets надо реализовывать, по сути, два движка? Один — эмулятор, один — поддержка родных контролов?
a> M>На этом примере мы, кстати, видим убогость реализации (виндовая стрека вниз проглядывает из-за самонарисованой)
a> Везде есть баги. Это всего лишь пример рисования. Реальные баги это когда контролы Qt и GTK+ отличаются от родных, а таких примеров — море.
a> M>Если на каждый чих надо рисовать контрол с нуля — в топку. Потому что Qt тоже позволяет создать любой контрол с нуля. Но при этом Qt позволяет расширить функциональность любого контрола.
a> Qt позволяет лишь заебывать пользователя нестандартными цветами, а возможность расширения контролов там крайне убогая.
Я так понимаю, это сказано, опираясь лишь на предоставленные Шериданом скриншоты?
Приветствую, Cyberax, вы писали:
C> Под *nix будет точно, видимо с backend'ом на QT (я этим сейчас занимаюсь). C> Под Mac лучше кроссплатформенный код не писать, а использовать местные инструменты — очень они уж специфические.
Просто сделай дополнительное дерево классов контролов для Qt и живи спокойно.
Здравствуйте, Sheridan, Вы писали:
C>> Под *nix будет точно, видимо с backend'ом на QT (я этим сейчас занимаюсь). C>> Под Mac лучше кроссплатформенный код не писать, а использовать местные инструменты — очень они уж специфические. S>Просто сделай дополнительное дерево классов контролов для Qt и живи спокойно.
По удобству разработки НИЧЕГО пока не сравнивается с htmlayout'ом.
a> M>Что значит сильные ограничения? В чем они проявляются? Что значит «задрочить пользователя изменениями». Почему сабклассинг этого не позволяет? a> M>Что значит «тяжелые расширители»? 0_о
a> Основная возможность этих контролов — это игнорировать цвета и прочие параметры, которые пользователь выбрал в системе, ничего существенного они не привносят.
Еще раз. Что такое «тяжелые расширители»?
a> M>То есть тем же wxWidgets надо реализовывать, по сути, два движка? Один — эмулятор, один — поддержка родных контролов?
a> wxWidgets — это не Qt, самописные контролы — это всего лишь дополнение к нативным, которые пишутся в случае: a> 1. Ни одна платформа не поддерживает контролы, они есть лишь в третьих библиотеках a> 2. Одна из платформ не поддерживает контрол, он пишется на основании поведения на других платформах. a> Контролы, которые приходится эмулировать, пишутся максимально приближенно к родным и используют наиболее близкий класс. Например кнопка с рисунком — это наследник от родной кропки,
Я про это изначально и спрашивал. Что, если родная для системы кнопка не поддерживает рисунок? (Кнопка в винде рисунки не поддеривает, насколько я понмю)
a> а не от просто прямоугольник на родной форме операционной системы как в Qt.
Ты вообще Qt видел? Или эта, вообще разбираешься в том, что такое сабклассинг там. Не? Кнопка с рисунком — точно такой же сабкласс кнопки, а не «просто прямоугольник на форме».
a> S>Да и не смотря на такую "убогость" Qt становиться де-факто стандартом кроссплатформенного программирования и стал основой для KDE(де-факто стандартным WM для Linux)
a> Вот уже 10 лет становится, все никак не может стать. А стандартный DE под дистрибутивы это GNOME, а не KDE — его выбирали Fedora, Debian, OpenSUSE, Ubuntu и другие ведущие дистрибутивы Linux.
Несмотря на то, что эти вопросы задавал не я, все же отвечу. В OpenSUSE стандартный DM — KDE. И стандартный DE под дистрибутивы... А нет такого понятия, как стандартный DE под дистрибутивы.
Более того, Gnome посленее время развивается очень медленно.
a> GTK+ — родной под GNOME, Qt — родной под KDE, wxWidgets — родной под Windows, GNOME и Mac OS X. А под Windows Qt это всего лишь портированный KDE с взятыми из системы цветами,
Здравствуйте, Mamut, Вы писали: a>> GTK+ — родной под GNOME, Qt — родной под KDE, wxWidgets — родной под Windows, GNOME и Mac OS X. А под Windows Qt это всего лишь портированный KDE с взятыми из системы цветами, M>Пипец. Такого бреда я еще никогда не слышал.
Не, ну в каждой шутке есть все-таки доля шутки... или правды... в общем — не важно.
Gtk и qt правда ведь "родные" там, где большинство других аппликух использует соответственно gtk или qt. Gtk-приложение в kde-окружении (по крайней мере — в последнее время) будет выглядеть немного коряво. Хотя qt надо отдать должное — он под gtk маскируется довольно хорошо (ну разве кроме иконок).
Ну а у wxwidgets и вправду вроде бы три разных бэкенда под разные платформы, хотя въедливые коллеги могут подметить, что, помимо внешнего вида кнопочек, существуют такие важные вещи, как stock-иконки в gtk, расположение пунктов меню и т.п.
А фразу про kde в windows я тоже как-то не понял.
MC> a>> GTK+ — родной под GNOME, Qt — родной под KDE, wxWidgets — родной под Windows, GNOME и Mac OS X. А под Windows Qt это всего лишь портированный KDE с взятыми из системы цветами,
MC> M>Пипец. Такого бреда я еще никогда не слышал.
MC> Не, ну в каждой шутке есть все-таки доля шутки... или правды... в общем — не важно. MC> Gtk и qt правда ведь "родные" там, где большинство других аппликух использует соответственно gtk или qt. Gtk-приложение в kde-окружении (по крайней мере — в последнее время) будет выглядеть немного коряво. Хотя qt надо отдать должное — он под gtk маскируется довольно хорошо (ну разве кроме иконок). MC> Ну а у wxwidgets и вправду вроде бы три разных бэкенда под разные платформы, хотя въедливые коллеги могут подметить, что, помимо внешнего вида кнопочек, существуют такие важные вещи, как stock-иконки в gtk, расположение пунктов меню и т.п. MC> А фразу про kde в windows я тоже как-то не понял.
Ну я, говоря про бред, именно про kde в windows говорил
Здравствуйте, vadimcher, Вы писали:
V>Здравствуйте, vadimcher, Вы писали:
V>>Задаю здесь, а не в Средства разработки или, не дай Бог, Священные войны, т.к. интересует именно приложение к C++, более того, под Win32.
Если это ты написал "C++, более того, под Win32." то я буду настаивать на WTL.
Это нативная очень тонкая прослойка (что-то около 6 .h файлов) для С++ для именно w32/w64 и mobile.
Вообще подход WTL полезен для изучения как образец наименее интрузивного способа оборачиваия win api.
(Интересно было бы глянуть на нечто аналогичное но для скажем Gnome или чистых X если такое наличествует в природе)
Qt это строго говоря не есть С++ ибо требует своего препроцессора для компиляции.
GTK+ это набор сугубых C API. Для C++ тебе потребуется gtkmm или аналогичные конструкции.
Приветствую, c-smile, вы писали:
c> Если это ты написал "C++, более того, под Win32." то я буду настаивать на WTL.
Если человек решит впоследствии писать кроссплатформенно, то с твоим советом ему потом придется переучиваться.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, c-smile, вы писали:
c>> Если это ты написал "C++, более того, под Win32." то я буду настаивать на WTL. S>Если человек решит впоследствии писать кроссплатформенно, то с твоим советом ему потом придется переучиваться.
+1 к тов. c-smile. Кроссплатформенный GUI существует лишь в теории. Если есть такой заказ, то кроссплатформенной делать надо собственно программу, а UI цеплять в соответствии с капризами платформы. Потому как пользователям все равно что вы сэкономили на разработке и если вы сэкономили на их юзабилити — они не простят.
Приветствую, SleepyDrago, вы писали:
SD> +1 к тов. c-smile. Кроссплатформенный GUI существует лишь в теории.
Странно, я эту теорию уже неоднократно применял на практике...
Здравствуйте, Sheridan, Вы писали:
SD>> +1 к тов. c-smile. Кроссплатформенный GUI существует лишь в теории. S>Странно, я эту теорию уже неоднократно применял на практике...
Ты просто не писал commercial-quality приложения. Чаще всего надо или делать уж совсем кастомный UI, или писать нативный UI под каждую платформу.
Приветствую, Cyberax, вы писали:
C> SD>> +1 к тов. c-smile. Кроссплатформенный GUI существует лишь в теории. C> S>Странно, я эту теорию уже неоднократно применял на практике... C> Ты просто не писал commercial-quality приложения. Чаще всего надо или делать уж совсем кастомный UI, или писать нативный UI под каждую платформу.
Здравствуйте, Sheridan, Вы писали:
C>> SD>> +1 к тов. c-smile. Кроссплатформенный GUI существует лишь в теории. C>> S>Странно, я эту теорию уже неоднократно применял на практике... C>> Ты просто не писал commercial-quality приложения. Чаще всего надо или делать уж совсем кастомный UI, или писать нативный UI под каждую платформу. S>Что мешает писать кастомный уй на основе куте?
Смысла нет. Это не так уж просто делается — проще взять родной для системы тулкит.
Скажем, на Маке имеет смысл брать Cocoa и не заниматься фигнёй. На Линуксе — QT. На Винде, разве что, можно брать что угодно — так как везде бардак.
M>Еще раз. Что такое «тяжелые расширители»?
Хотя бы взять пример stylesheet, в нем настройки интерфеса прописаны в неком формате QSS — жалком подобии CSS. Если уже реализовывать HTML подобный интерфейс, то уже как в HTMLLayout и прочих HTML библиотеках, а так получилось и родные интерфейсы не поддерживает, и нормальный HTML не дает.
M>Что, если родная для системы кнопка не поддерживает рисунок? (Кнопка в винде рисунки не поддеривает, насколько я понмю)
Да, Windows не поддерживает кнопок, это считается под Windows что лишь мешает в работе. GNOME поддерживает эти кропки, но я слышал о предложении отлючить их и там.
В этом случае под GTK+ используется родная прорисовка, а под виндовс ничего другого не остается, как рисовать через OwnerDraw: http://svn.wxwidgets.org/svn/wx/wxWidgets/trunk/src/msw/button.cpp
Но я, чесно говоря, никогда рисунки к кнопкам не ставил.
В общем если какая то возможность не принята под конкретной осью, то она вполне может быть не реализована там.
M>Ты вообще Qt видел? Или эта, вообще разбираешься в том, что такое сабклассинг там. Не? Кнопка с рисунком — точно такой же сабкласс кнопки, а не «просто прямоугольник на форме».
Контролы в Qt — это Window less элементы, то есть они ничего общего с родными контролами не имеют, а их цвет и поведение — это чистая эмуляция. Поэтому с точки зрения операционной системы — это всего лишь прямоугольник, который отрисовывает внешняя либа. Ты не знал об этом?
Впрочем кнопка довольно неплохо эмулируется в Qt.
M>Несмотря на то, что эти вопросы задавал не я, все же отвечу. В OpenSUSE стандартный DM — KDE. И стандартный DE под дистрибутивы... А нет такого понятия, как стандартный DE под дистрибутивы.
А википедия считает, что GNOME и KDE — это DE http://en.wikipedia.org/wiki/Desktop_environment#Examples_of_desktop_environments
"стандартный DE под дистрибутивы" — это как правило то, который ставится по умолчанию. Но поставить "не стандартный" можно, скачав его.
M>Более того, Gnome посленее время развивается очень медленно.
Зато KDE4 так быстро "развивается", что он стал не юзабельным и я постоянно слышу, что кто то с него сваливает.
Сейчас популярны под Linux они оба, но к этой теме это уже не относится.
M>Пипец. Такого бреда я еще никогда не слышал.
А это уже неконструктивная критика.
Приветствую, Cyberax, вы писали:
C> Здравствуйте, Sheridan, Вы писали:
C> S>Что мешает писать кастомный уй на основе куте? C> Смысла нет. Это не так уж просто делается — проще взять родной для системы тулкит. C> Скажем, на Маке имеет смысл брать Cocoa и не заниматься фигнёй. На Линуксе — QT. На Винде, разве что, можно брать что угодно — так как везде бардак.
А казалось бы — возьми Qt и сделай сразу под 3 платформы. Ан нет, мы будем мучаться...
Здравствуйте, Sheridan, Вы писали:
C>> Смысла нет. Это не так уж просто делается — проще взять родной для системы тулкит. C>> Скажем, на Маке имеет смысл брать Cocoa и не заниматься фигнёй. На Линуксе — QT. На Винде, разве что, можно брать что угодно — так как везде бардак. S>А казалось бы — возьми Qt и сделай сразу под 3 платформы. Ан нет, мы будем мучаться...
А пользователи на Маках потом плеваться будут, да?
Здравствуйте, astral_marine, Вы писали:
M>>Ты вообще Qt видел? Или эта, вообще разбираешься в том, что такое сабклассинг там. Не? Кнопка с рисунком — точно такой же сабкласс кнопки, а не «просто прямоугольник на форме». _>Контролы в Qt — это Window less элементы, то есть они ничего общего с родными контролами не имеют, а их цвет и поведение — это чистая эмуляция. Поэтому с точки зрения операционной системы — это всего лишь прямоугольник, который отрисовывает внешняя либа. Ты не знал об этом?
Не совсем. Скажем, в Windows используется родной механизм тем для отрисовки элементов управления. В чем элементарно можно убедиться, если поставить нестандартную тему и запустить QT.
Приветствую, Cyberax, вы писали:
C> S>А казалось бы — возьми Qt и сделай сразу под 3 платформы. Ан нет, мы будем мучаться.. C> А пользователи на Маках потом плеваться будут, да?
На что? Ты же делаешь html. На его основе — гуй. На что плеваться? Qt webkit вроде нормально рисует хтмл контролы...
Здравствуйте, Sheridan, Вы писали:
C>> S>А казалось бы — возьми Qt и сделай сразу под 3 платформы. Ан нет, мы будем мучаться.. C>> А пользователи на Маках потом плеваться будут, да? S>На что? Ты же делаешь html. На его основе — гуй. На что плеваться?
HTMLayout позволяет делать уникальный дизайн, а не плохую имитацию платформы.
S>Qt webkit вроде нормально рисует хтмл контролы...
WebKit в QT и близко не подходит по возможностям к htmlayout'у.
S> C> Ты просто не писал commercial-quality приложения. Чаще всего надо или делать уж совсем кастомный UI, или писать нативный UI под каждую платформу.
S> Что мешает писать кастомный уй на основе куте?
Hello, astral_marine, you write:
a> M>Еще раз. Что такое «тяжелые расширители»?
a> Хотя бы взять пример stylesheet, в нем настройки интерфеса прописаны в неком формате QSS — жалком подобии CSS. Если уже реализовывать HTML подобный интерфейс, то уже как в HTMLLayout и прочих HTML библиотеках, а так получилось и родные интерфейсы не поддерживает, и нормальный HTML не дает.
Мде, это явно тяжелые расширители сознания.
А реализация собственой кнопки — это примитивная операция, которая не всегда оправдывает использование тяжелых расширителей.
Тебя кто-то заставляет использовать QSS? Тебе кто-то мешает реализовать свою кнопку в Qt? Эти самы тяжелые расширители мешают?
a> M>Что, если родная для системы кнопка не поддерживает рисунок? (Кнопка в винде рисунки не поддеривает, насколько я понмю)
a> Да, Windows не поддерживает кнопок, это считается под Windows что лишь мешает в работе. GNOME поддерживает эти кропки, но я слышал о предложении отлючить их и там. a> В этом случае под GTK+ используется родная прорисовка, а под виндовс ничего другого не остается, как рисовать через OwnerDraw: a> http://svn.wxwidgets.org/svn/wx/wxWidgets/trunk/src/msw/button.cpp a> Но я, чесно говоря, никогда рисунки к кнопкам не ставил.
Именно я об этом и говорил — что в wxWidgets в таком случае придется поддерживать два способа отрисовки — родные контролы и эмуляцию
a> В общем если какая то возможность не принята под конкретной осью, то она вполне может быть не реализована там.
a> M>Ты вообще Qt видел? Или эта, вообще разбираешься в том, что такое сабклассинг там. Не? Кнопка с рисунком — точно такой же сабкласс кнопки, а не «просто прямоугольник на форме».
a> Контролы в Qt — это Window less элементы, то есть они ничего общего с родными контролами не имеют, а их цвет и поведение — это чистая эмуляция. Поэтому с точки зрения операционной системы — это всего лишь прямоугольник, который отрисовывает внешняя либа. Ты не знал об этом?
a> Впрочем кнопка довольно неплохо эмулируется в Qt.
Пипец. Тебе-то какая разница, как это видит ОС?
a> M>Несмотря на то, что эти вопросы задавал не я, все же отвечу. В OpenSUSE стандартный DM — KDE. И стандартный DE под дистрибутивы... А нет такого понятия, как стандартный DE под дистрибутивы.
a> А википедия считает, что GNOME и KDE — это DE
А стандартный DE под дистрибутивы это GNOME, а не KDE — его выбирали Fedora, Debian, OpenSUSE, Ubuntu и другие ведущие дистрибутивы Linux.
Нет такого понятия, как стандартный DE в мире линукса
a> M>Более того, Gnome посленее время развивается очень медленно. a> Зато KDE4 так быстро "развивается", что он стал не юзабельным и я постоянно слышу, что кто то с него сваливает. a> Сейчас популярны под Linux они оба, но к этой теме это уже не относится.
Относится к твоим словам, в которых ты утверждаешь, что Gnome — это стандарный DE
a> M>Пипец. Такого бреда я еще никогда не слышал. a> А это уже неконструктивная критика.
Более, чем. Напомнить твои слова?
А под Windows Qt это всего лишь портированный KDE с взятыми из системы цветами,
Приветствую, Mamut, вы писали:
M> S> Что мешает писать кастомный уй на основе куте? M> Стоимость коммерческой лицензии.
Я чтото пропустил? кутэ опять закрыто для коммерческого использования?
Или к чему было счастье у шароварщиков?
Hello, Sheridan, you write:
S> Приветствую, Mamut, вы писали:
S> M> S> Что мешает писать кастомный уй на основе куте?
S> M> Стоимость коммерческой лицензии.
S> Я чтото пропустил? кутэ опять закрыто для коммерческого использования? S> Или к чему было счастье у шароварщиков?
У Qt три лицензии: коммерческая, lgpl и gpl. Могут быть причины, когда lgpl не подходит
Приветствую, Mamut, вы писали:
M> Могут быть причины, когда lgpl не подходит
Конечно могут быть, кто спорит? Выдумать можно какую угодно ситуацию. Ты выдумал ситуацию, когда лгпл не подходит. Я например могу выдумать ситуацию, когда микрософт разорился. Вероятность твоей ситуации выше. но и вероятность моей ситуации не равна нулю.
Так то.
Так что давай не будем выдумывать ситуации.
Здравствуйте, vadimcher, Вы писали:
V>Вопросы простые: V>2) Что проще для изучения, с чем проще начать (просто взять и без особых проблем начать писать, типа как Delphi в свое время), я знаю, что для GTK+ есть специальные редакторы, один из них идет в комплекте, для Qt -- не знаю. Может кто подскажет, как проще использовать. Короче, что более удобно для изучения и использования. V>3) Может у кого есть информация, что более эффективно? Знаю, что GTK+ жрет меньше памяти. Больше -- не в курсе. Или может даже есть мнение за чем будущее? (Может за чем-то еще, кроме этих двух, а сюда не стоит и соваться?) Вроде как Nokia выбрала Qt, Motorola -- GTK+. С лицензией вроде как у GTK+ попроще.
Qt не настолько простая как Delphi, но не намного сложнее.
Вообще в ней удобно делать GUI приложения без визуальных редакторов. Очень много возможностей ручной настройки.
Сейчас с лицензией всё в порядке, можно использовать эту библиотеку в своих коммерческих приложениях и ничего за это не платить. Единственное ограничение — нельзя править саму библиотеку.
Библиотека очень хорошо спроектирована, всё выполнено в одном стиле, но к некоторым вещам нужно привыкнуть — сразу бывает непонятно, как что-то сделать.
Сколько памяти что жрёт по большому счёту не важно, можно и на Win Api так написать, что тормозить будет страшно.
Единственное — программы, использующие QtGui4.dll (весит более 10 Мб) грузятся довольно долго.
Hello, Sheridan, you write:
S> Приветствую, Mamut, вы писали:
S> M> Могут быть причины, когда lgpl не подходит
S> Конечно могут быть, кто спорит? Выдумать можно какую угодно ситуацию. Ты выдумал ситуацию, когда лгпл не подходит. Я например могу выдумать ситуацию, когда микрософт разорился. Вероятность твоей ситуации выше. но и вероятность моей ситуации не равна нулю. S> Так то. S> Так что давай не будем выдумывать ситуации.
Я не выдумываю ситуации. То, что Qt выпускается под тремя лицензиями — это факт, который существует объективно, вне зависимости от твоей, моей или чьей-нибудь еще фантазии. Тот факт, что коммерческая лицензия существует, означает, что есть далеко не самое маленькое количество случаев, когда эта лицензия востребована.
Более того, lgpl в Qt появилась очень недавно (в этом году, что ли). До этого коммерческая разработка на Qt стоила очень и очень дорого
Здравствуйте, vadimcher, Вы писали:
V>В общем, что я понял (если где не прав или не так понял, то поправьте):
[] V>Вывод: гляну в следующем порядке (прошу прощения у всех фанатов того или иного решения, порядок не имеет никакого отношения к тому, что лучше или хуже -- мне нужно выбрать какой-то порядок): Qt, wxWidgets, GTK+.
V>В связи с этим два вопроса. V>1) Какое IDE лучше использовать, например, можно ли просто добавить поддержку в VS 2008, а может генерить родными средствами, а затем использовать то, к чему привык? V>2) "Оптимальное" руководство, типа "*** за 10000 секунд".
Взял это в .chm формате. Есть ли существенные отличия от Qt4?
Здравствуйте, vadimcher, Вы писали:
V>>2) "Оптимальное" руководство, типа "*** за 10000 секунд". V>Взял это в .chm формате. Есть ли существенные отличия от Qt4?
Для начального освоения, в принципе, не так уж много.
Mamut, мы говорили о "расширителях", а не о собственной отрисовке. Поэтому все мои замечания об ущербности относятся к ним. Механизм собственной отрисовки реализован приблизительно одинаково во всех библиотеках так что здесь сравнивать особо нечего.
То, как показывает это операционная система важно, поскольку она делает это более качественно, чем собственная эмуляция. Из-за багов в эмуляции можно достаточно легко обнаружить приложения на GTK+, Qt и X11 не заглядывая в исходники.
Qt — это родная библиотека для KDE, поэтому это единственное место, где ее контролы — действительно родные. И поэтому KDE была приведена в качестве примера.
[offtopic]
Повторюь, что термин DE не относится к этой теме и я не вижу смысла продолжать в этом направлении.
Также ссылка без комментариев на обзор в Википедии Qt — это не аргумент. Просьба давать свои аргументы, а не чужие пространственные обзоры обо всем.
Просьба не повторять одни и те же вопросы, не вести разговор в духе "Это все бред. Однозначно! Точка", "Я написал выше, почитай" и не переходить на личности. Я этого не делаю и ты будь добр не делай этого. Невоспитанностью ты ничего не докажешь.
[/offtopic]
M>> Могут быть причины, когда lgpl не подходит S>Конечно могут быть, кто спорит? Выдумать можно какую угодно ситуацию. Ты выдумал ситуацию, когда лгпл не подходит. Я например могу выдумать ситуацию, когда микрософт разорился. Вероятность твоей ситуации выше. но и вероятность моей ситуации не равна нулю.
Действительно, могут быть ситуации когда LGPL не подходит, а лицензия позволяющая линковать wxWidgets статически может пригодится:
У меня была ситуация, когда необходимо было распространить версию приложения на несколько городов, права доступа на компы — от самых жестких, до чуть ли ни админовских, персонал на 90% — неквалифицированный совсем, ограничения доступа к ресурсам самые разнообразные для разных подразделений и что самое важное, обновление приложения должно происходить в реальном времени менее чем за 10 секунд в любой точке.
Для этого я сделал:
1. Распространяется файл как через MSI так и через простое копирование.
2. Всего один файл, без внешних зависимостей.
3. Один файл и он имеет номер версии, по которому однозначно можно определить полностью все возможности данной инсталляции.
4. Библиотеки обновлять и проверять совместимость не надо, поскольку линковка статическая
Инсталляция при этом работает как часы — один раз сделал и на года.
И это всего лишь обычная фирма с персоналом в несколько сотен человек в нескольких городах.
Здравствуйте, astral_marine, Вы писали:
_>Для этого я сделал: _>1. Распространяется файл как через MSI так и через простое копирование. _>2. Всего один файл, без внешних зависимостей. _>3. Один файл и он имеет номер версии, по которому однозначно можно определить полностью все возможности данной инсталляции. _>4. Библиотеки обновлять и проверять совместимость не надо, поскольку линковка статическая
Это МОЖНО сделать с LGPL. Всё что от тебя требуется — предоставить по требованию версию с динамическим связыванием. Совсем необязательно всё делать с динамикой.
Здравствуйте, astral_marine, Вы писали:
_>Mamut, мы говорили о "расширителях", а не о собственной отрисовке. Поэтому все мои замечания об ущербности относятся к ним. Механизм собственной отрисовки реализован приблизительно одинаково во всех библиотеках так что здесь сравнивать особо нечего.
Не согласен. В QT отрисовка реализована кардинально лучше, чем в wx. Скажем, QT влёгкую поддерживает resolution independance.
_>То, как показывает это операционная система важно, поскольку она делает это более качественно, чем собственная эмуляция.
Не согласен. Та же QT позволяет сейчас делать приложения с намного более красивым поведением. Скажем, resize и вообще манипуляции без flicker'а.
Здравствуйте, vadimcher, Вы писали:
V>Здравствуйте, vadimcher, Вы писали:
V>>В общем, что я понял (если где не прав или не так понял, то поправьте): V>[] V>>Вывод: гляну в следующем порядке (прошу прощения у всех фанатов того или иного решения, порядок не имеет никакого отношения к тому, что лучше или хуже -- мне нужно выбрать какой-то порядок): Qt, wxWidgets, GTK+.
V>>В связи с этим два вопроса. V>>1) Какое IDE лучше использовать, например, можно ли просто добавить поддержку в VS 2008, а может генерить родными средствами, а затем использовать то, к чему привык? V>>2) "Оптимальное" руководство, типа "*** за 10000 секунд".
V>Взял это в .chm формате. Есть ли существенные отличия от Qt4?
Есть. Все же лучше скачать книгу по 4-ке на torrents.ru она есть. А вобще если у тебя с английским нормально то тебе хватит с головой Assistant(справка идушая вместе с Qt)
a> Mamut, мы говорили о "расширителях", а не о собственной отрисовке. Поэтому все мои замечания об ущербности относятся к ним. Механизм собственной отрисовки реализован приблизительно одинаково во всех библиотеках так что здесь сравнивать особо нечего.
Я так и не понял, что такое «тяжелые расширители». Особенно в контексте
a> Qt — это родная библиотека для KDE, поэтому это единственное место, где ее контролы — действительно родные. И поэтому KDE была приведена в качестве примера.
Еще раз. Читай историю Qt. Да, KDE написан на Qt. Но это не значит, что Qt для винды — это портированый на винду KDE. Qt для винды появился задолго до самого KDE.
Здравствуйте, astral_marine, Вы писали: _>Механизм собственной отрисовки реализован приблизительно одинаково во всех библиотеках так что здесь сравнивать особо нечего.
Вроде бы эта фраза должна вызвать гнев кутешников, у которых и аппаратное ускорение, и шустрый векторный движок... Тут на форуме были дискуссии на эту тему, который вроде как демонстрировали техническое превосходство qt над gdk, cairo и прочими камрадами.
Здравствуйте, ArtDenis, Вы писали:
C>>Не согласен. В QT отрисовка реализована кардинально лучше, чем в wx AD>Wx не отрисовывает стандартные контролы. Это делает операционная система. Так что сравнение абсолютно некорректное.
Вот как раз операционная система (Windows) и делает это из рук вон плохо.
Здравствуйте, vadimcher, Вы писали:
V>Задаю здесь, а не в Средства разработки или, не дай Бог, Священные войны, т.к. интересует именно приложение к C++, более того, под Win32.
V>Вопросы простые: V>1) Использует ли кто Qt или GTK+ или и то, и другое, или что-то еще для GUI. V>2) Что проще для изучения, с чем проще начать (просто взять и без особых проблем начать писать, типа как Delphi в свое время), я знаю, что для GTK+ есть специальные редакторы, один из них идет в комплекте, для Qt -- не знаю. Может кто подскажет, как проще использовать. Короче, что более удобно для изучения и использования. V>3) Может у кого есть информация, что более эффективно? Знаю, что GTK+ жрет меньше памяти. Больше -- не в курсе. Или может даже есть мнение за чем будущее? (Может за чем-то еще, кроме этих двух, а сюда не стоит и соваться?) Вроде как Nokia выбрала Qt, Motorola -- GTK+. С лицензией вроде как у GTK+ попроще.
V>Короче, что учить и использовать (или вообще что-то другое).
V>Спасибо.
C>Это МОЖНО сделать с LGPL. Всё что от тебя требуется — предоставить по требованию версию с динамическим связыванием. Совсем необязательно всё делать с динамикой.
LGPL требует что бы библиотека могла быть заменена при условии сохранения бинарных интерфейсов:
6. b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.
6. b) для связывания с Библиотекой должен использоваться подходящий механизм разделяемых библиотек. Механизм разделяемых библиотек считается подходящим, если он: 1) в течение времени исполнения использует копию библиотеки, которая уже находится в компьютерной системе пользователя, а не копирует функции библиотеки в исполняемый файл и 2) надлежащим образом работает с модифицированной версией библиотеки, установленной пользователем, при условии совместимости интерфейсов модифицированной версии и той версии библиотеки, которая использовалась для создания произведения, содержащего части Библиотеки;
Например одна фирма уже попалилась на этом: она распространяла Linux на устройстве, которое работало только с подписанной версией ядра.
Соответственно поскольку статическая линковка на позволяет заменять библиотеку, пользователь не может подменить библиотеку и поэтому распространение ее в таком виде — незаконно.
Здравствуйте, astral_marine, Вы писали:
C>>Это МОЖНО сделать с LGPL. Всё что от тебя требуется — предоставить по требованию версию с динамическим связыванием. Совсем необязательно всё делать с динамикой. _>LGPL требует что бы библиотека могла быть заменена при условии сохранения бинарных интерфейсов:
Нет. LGPL требует чтобы это можно было сделать, но не обязательно для любой поставки. Ты можешь на своём сайте выложить набор .o-файлов и в документации к статически связанной программе указать, что их можно там скачать. Это выполнит все требования LGPL.
_>Например одна фирма уже попалилась на этом: она распространяла Linux на устройстве, которое работало только с подписанной версией ядра.
Опять мимо.
_>Соответственно поскольку статическая линковка на позволяет заменять библиотеку, пользователь не может подменить библиотеку и поэтому распространение ее в таком виде — незаконно.
Опять мимо.
Здравствуйте, Cyberax, Вы писали:
C>Нет. LGPL требует чтобы это можно было сделать, но не обязательно для любой поставки. Ты можешь на своём сайте выложить набор .o-файлов и в документации к статически связанной программе указать, что их можно там скачать. Это выполнит все требования LGPL.
Если так то зачем отдельно обговаривают static linking exception для LGPL?
Здравствуйте, FR, Вы писали:
C>>Нет. LGPL требует чтобы это можно было сделать, но не обязательно для любой поставки. Ты можешь на своём сайте выложить набор .o-файлов и в документации к статически связанной программе указать, что их можно там скачать. Это выполнит все требования LGPL. FR>Если так то зачем отдельно обговаривают static linking exception для LGPL?
Чтобы не требовалось делать и этого. Всё-таки дополнительные проблемы.
Здравствуйте, Cyberax, Вы писали:
FR>>Если так то зачем отдельно обговаривают static linking exception для LGPL? C>Чтобы не требовалось делать и этого. Всё-таки дополнительные проблемы.
Сейчас читаю похоже да ты прав, хотя конечно надо бы юриста специализируещегося на этом расспросить.
Но помню лет восемь назад этого не было, или нас неправильно проконсультировали.
Еще есть интересный вопрос. Допустим есть приложение запакованное py2exe (должно пускатся легко
с флешки). При этом py2exe запоковывает туда все включая dll и pyd, но получившийся exe по
сути простой zip файл, легко открывается к примеру WinRAR'ом или другим подобным архиватором,
получается это не нарушает LGPL?
Здравствуйте, FR, Вы писали:
C>>Чтобы не требовалось делать и этого. Всё-таки дополнительные проблемы. FR>Сейчас читаю похоже да ты прав, хотя конечно надо бы юриста специализируещегося на этом расспросить.
Спрашивай сюда, при желании могу напрячь юриста в головной компании в США.
FR>Но помню лет восемь назад этого не было, или нас неправильно проконсультировали.
Ага.
FR>Еще есть интересный вопрос. Допустим есть приложение запакованное py2exe (должно пускатся легко FR>с флешки). При этом py2exe запоковывает туда все включая dll и pyd, но получившийся exe по FR>сути простой zip файл, легко открывается к примеру WinRAR'ом или другим подобным архиватором, FR>получается это не нарушает LGPL?
Если ты в документации напишешь как его распаковать — не нарушает.
Здравствуйте, Cyberax, Вы писали:
FR>>Сейчас читаю похоже да ты прав, хотя конечно надо бы юриста специализируещегося на этом расспросить. C>Спрашивай сюда, при желании могу напрячь юриста в головной компании в США.
Ну по сути впорос уже задан, про py2exe, правда паковщик там другой но работает полностью аналогично.
FR>>Но помню лет восемь назад этого не было, или нас неправильно проконсультировали. C>Ага.
То есть тогда еще не было такого?
FR>>получается это не нарушает LGPL? C>Если ты в документации напишешь как его распаковать — не нарушает.
Здравствуйте, FR, Вы писали:
FR>>>Но помню лет восемь назад этого не было, или нас неправильно проконсультировали. C>>Ага. FR>То есть тогда еще не было такого?
Нет, вас тогда неправильно проконсультировали.
C>>>Это МОЖНО сделать с LGPL. Всё что от тебя требуется — предоставить по требованию версию с динамическим связыванием. Совсем необязательно всё делать с динамикой. _>>LGPL требует что бы библиотека могла быть заменена при условии сохранения бинарных интерфейсов: C>Нет. LGPL требует чтобы это можно было сделать, но не обязательно для любой поставки. Ты можешь на своём сайте выложить набор .o-файлов и в документации к статически связанной программе указать, что их можно там скачать. Это выполнит все требования LGPL.
А как же требование "в течение времени исполнения использует копию библиотеки, которая уже находится в компьютерной системе пользователя, а не копирует функции библиотеки в исполняемый файл", при статической линковке это невозможно.
_>>Например одна фирма уже попалилась на этом: она распространяла Linux на устройстве, которое работало только с подписанной версией ядра. C>Опять мимо.
Опять мимо. Если железо работает с версией ПО только с определенной MD5 суммой, то это нарушает "надлежащим образом работает с модифицированной версией библиотеки, установленной пользователем, при условии совместимости интерфейсов модифицированной версии и той версии библиотеки, которая использовалась для создания произведения, содержащего части Библиотеки"
_>>Соответственно поскольку статическая линковка на позволяет заменять библиотеку, пользователь не может подменить библиотеку и поэтому распространение ее в таком виде — незаконно. C>Опять мимо.
Опять мимо. Нарушение лицензий использования и в частности LGPL — незаконно.
Cyberax, перед тем как отвечать прочитай пожалуйста еще раз приведенную цитату из LGPL.
FR>Еще есть интересный вопрос. Допустим есть приложение запакованное py2exe (должно пускатся легко FR>с флешки). При этом py2exe запоковывает туда все включая dll и pyd, но получившийся exe по FR>сути простой zip файл, легко открывается к примеру WinRAR'ом или другим подобным архиватором, FR>получается это не нарушает LGPL?
Распространять ПО под LGPL в архивах можно, поскольку в все равно выполнение идет в распакованном виде с динамическим связыванием, независимо от того кто распаковал — пользователь, WinRAR или сама операционная система.
Здравствуйте, astral_marine, Вы писали:
_>Распространять ПО под LGPL в архивах можно, поскольку в все равно выполнение идет в распакованном виде с динамическим связыванием, независимо от того кто распаковал — пользователь, WinRAR или сама операционная система.
Тот же py2exe сам напрямую грузит dll из архива в память, без распаковки на диск. С точки зрения того же Process Explorer это монолитное приложение без динамической линковки.
Здравствуйте, astral_marine, Вы писали:
C>>Нет. LGPL требует чтобы это можно было сделать, но не обязательно для любой поставки. Ты можешь на своём сайте выложить набор .o-файлов и в документации к статически связанной программе указать, что их можно там скачать. Это выполнит все требования LGPL. _>А как же требование "в течение времени исполнения использует копию библиотеки, которая уже находится в компьютерной системе пользователя, а не копирует функции библиотеки в исполняемый файл", при статической линковке это невозможно.
См. пункты 6 c и 6 d.
_>>>Например одна фирма уже попалилась на этом: она распространяла Linux на устройстве, которое работало только с подписанной версией ядра. C>>Опять мимо. _>Опять мимо. Если железо работает с версией ПО только с определенной MD5 суммой, то это нарушает "надлежащим образом работает с модифицированной версией библиотеки, установленной пользователем, при условии совместимости интерфейсов модифицированной версии и той версии библиотеки, которая использовалась для создания произведения, содержащего части Библиотеки"
Нет. Это НИЧЕГО не нарушает. Такое поведение называется "Tivoization" по имени компании TiVo. Оно не нарушает ровно ничего — ты МОЖЕШЬ создать свою версию программы, тебя никто не удерживает. Но лицензии LGPLv2.x и GPLv2 не требуют, чтобы ты мог запускать программу на том же устройстве, на котором ты их получил.
Вот [L]GPL v3 этого требуют. Собственно, tivoization и было одним из мотивов их создания.
_>>>Соответственно поскольку статическая линковка на позволяет заменять библиотеку, пользователь не может подменить библиотеку и поэтому распространение ее в таком виде — незаконно. C>>Опять мимо. _>Опять мимо. Нарушение лицензий использования и в частности LGPL — незаконно.
У тебя тут две ошибки:
1) Это не нарушение лицензии (смотри пункты 6 c и 6 d в http://www.gnu.org/licenses/lgpl-2.1.html#SEC3)
2) LGPL не является лицензией на использование, а является лицензией на распространение.
_>Cyberax, перед тем как отвечать прочитай пожалуйста еще раз приведенную цитату из LGPL.
Я лицензии LGPL и GPL построчно разбирал с юристами, специализирующимися на них
Здравствуйте, vadimcher, Вы писали:
V>Задаю здесь, а не в Средства разработки или, не дай Бог, Священные войны, т.к. интересует именно приложение к C++, более того, под Win32.
V>Вопросы простые: V>1) Использует ли кто Qt или GTK+ или и то, и другое, или что-то еще для GUI. V>2) Что проще для изучения, с чем проще начать (просто взять и без особых проблем начать писать, типа как Delphi в свое время), я знаю, что для GTK+ есть специальные редакторы, один из них идет в комплекте, для Qt -- не знаю. Может кто подскажет, как проще использовать. Короче, что более удобно для изучения и использования. V>3) Может у кого есть информация, что более эффективно? Знаю, что GTK+ жрет меньше памяти. Больше -- не в курсе. Или может даже есть мнение за чем будущее? (Может за чем-то еще, кроме этих двух, а сюда не стоит и соваться?) Вроде как Nokia выбрала Qt, Motorola -- GTK+. С лицензией вроде как у GTK+ попроще.
V>Короче, что учить и использовать (или вообще что-то другое).
V>Спасибо.
Здравствуйте, Mr.Cat, Вы писали: MC>ИМХО, gtk попроще, ибо фич там поменьше. Но для гуя без извращенных требований — вполне себе неплох. MC>Однако под винду почему-то не так много gtk-приложений (и то это по большей части порты из линупсов).
Я как-то пробовал под виндой с ним разобратся... ниасилил.
А вот с Qt — с полпинка.
Здравствуйте, Tonal-, Вы писали:
T>Я как-то пробовал под виндой с ним разобратся... ниасилил. T>А вот с Qt — с полпинка.
T>Может сейчас положение и улучшелось.
Здравствуйте, vadimcher, Вы писали:
V>Задаю здесь, а не в Средства разработки или, не дай Бог, Священные войны, т.к. интересует именно приложение к C++, более того, под Win32.
В принципе, все уже сказали, но я дополню, как человек, уже почти 2 года пищущий кастомный интерфейс на GTK+.
Во-первых GTK+ написана на С и использует сложную и слабо поддающуюся осмыслению систему классов GObject. Т.е. там есть и наследование и абстрактные классы, и даже полифорфизм, но вы задумайтесь и представьте, как это может выглядеть на С. Так вот оно выглядит именно так как вы представили и даже еще хуже. Написать сабкласс для кнопки и перегрузить метод отрисовки — задача копания в исходном коде и скудной документации на день-два, которая в итоге приведет вас к тому, что для того, чтобы самому рисовать кнопку надо делать совсем не так.
Да, есть порты на С++, питон и по-моему даже Руби, но, честно говоря, они на мой взгляд добавляют к приложению еще один сложный и потенциально глючный уровень сложности.
Да, и еще на GTK наложили тяжелый отпечаток долгие годы разработки и тот факт, что это по сути слияние нескольких разных библиотек. Поробуйте-ка на раз-два-три рассказать, в чем отличия между классами GdkImage, GtkImage, GdkPixbuf и GtkPixmap, зная, что всех их можно использовать для загрузки и отображения картинок
Во-вторых, для GTK+ отвратительная документация. Простые вещи описаны неплохо, есть туториалы, и даже есть книга "Foundations of GTK+ development". Но в основном — это документация, автоматически сгенеренная из исходников, без примеров или дополнительных пояснений. И в какой-то момент вам надо разузнать что-то посложнее, чем как повесить картинку на кнопку, вы лезете в документацию и видите там что-то вроде этого: http://library.gnome.org/devel/gtk/stable/GtkContainer.html#GtkContainer-check-resize и со вздохом открываете исходники на несколько тысяч строк.
В-третьих для GTK существует весьма поганая поддержка. Основное коммьюнити — http://gtkforums.com/, где существуют несколько гуру, которые помогают с относительно несложными задачами, и множество вопрошающих.
В общем, это основное. Если у вас есть выбор между GTK и QT, выбирайте QT и не задумывайтесь. Единственный стрёмный момент с QT — это то, что trolltech вроде как купила моторола и если вы хотите разрабатывать серьезный интерфейс для коммерческого приложения, лицензия может обойтись недешево.
Здравствуйте, Corvin, Вы писали: C>В общем, это основное. Если у вас есть выбор между GTK и QT, выбирайте QT и не задумывайтесь. C>Единственный стрёмный момент с QT — это то, что trolltech вроде как купила моторола и если вы C>хотите разрабатывать серьезный интерфейс для коммерческого приложения, лицензия может обойтись недешево.
trolltech купила Nokia (не принципиально, просто уточнил).
А по ссылкам на документацию и правда жутковатая у жтк
пс. Для коммерческого применения недешовые лицензии это нормально, да и либа того стоит. Достойная поделка
Здравствуйте, trdm, Вы писали:
T>пс. Для коммерческого применения недешовые лицензии это нормально, да и либа того стоит. Достойная поделка
Хватит распространять бред. QT бесплатна для коммерческого использования по лицензии LGPL.
Здравствуйте, Corvin, Вы писали:
C>В общем, это основное. Если у вас есть выбор между GTK и QT, выбирайте QT и не задумывайтесь. Единственный стрёмный момент с QT — это то, что trolltech вроде как купила моторола и если вы хотите разрабатывать серьезный интерфейс для коммерческого приложения, лицензия может обойтись недешево.
Хватит распространять бред. QT бесплатна для коммерческого использования по лицензии LGPL.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Corvin, Вы писали:
C>>В общем, это основное. Если у вас есть выбор между GTK и QT, выбирайте QT и не задумывайтесь. Единственный стрёмный момент с QT — это то, что trolltech вроде как купила моторола и если вы хотите разрабатывать серьезный интерфейс для коммерческого приложения, лицензия может обойтись недешево. C>Хватит распространять бред. QT бесплатна для коммерческого использования по лицензии LGPL.
Возможно вы и правы, я не вникал, если честно, особо. Это было решение нашего заказчика, который свой отказ от КуТэ мотивировал таким образом (чтоб ему пусто было!)
Здравствуйте, Corvin, Вы писали:
C>Возможно вы и правы, я не вникал, если честно, особо. Это было решение нашего заказчика, который свой отказ от КуТэ мотивировал таким образом (чтоб ему пусто было!)
Все правильно, два года назад такой бесплатности не было.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Corvin, Вы писали:
C>>В общем, это основное. Если у вас есть выбор между GTK и QT, выбирайте QT и не задумывайтесь. Единственный стрёмный момент с QT — это то, что trolltech вроде как купила моторола и если вы хотите разрабатывать серьезный интерфейс для коммерческого приложения, лицензия может обойтись недешево. C>Хватит распространять бред. QT бесплатна для коммерческого использования по лицензии LGPL.
И нахрена так грубо? Человек сразу написал, что работает на GTK+ два года, как я понял два года назад (когда у него, или там босса, может быть и стоял выбор) лицензия на коммерческое использование Qt была другая, и сейчас он написал "может обойтись недешево", а не "обойдется недешево", потому как здраво предполагал, что за два года могло что-то поменяться...
А вот зайца кому, зайца-выбегайца?!
Re: Qt или GTK+ или ?
От:
Аноним
Дата:
09.09.09 06:11
Оценка:
Здравствуйте, vadimcher, Вы писали:
V>Задаю здесь, а не в Средства разработки или, не дай Бог, Священные войны, т.к. интересует именно приложение к C++, более того, под Win32.
V>Вопросы простые: V>1) Использует ли кто Qt или GTK+ или и то, и другое, или что-то еще для GUI. V>2) Что проще для изучения, с чем проще начать (просто взять и без особых проблем начать писать, типа как Delphi в свое время), я знаю, что для GTK+ есть специальные редакторы, один из них идет в комплекте, для Qt -- не знаю. Может кто подскажет, как проще использовать. Короче, что более удобно для изучения и использования. V>3) Может у кого есть информация, что более эффективно? Знаю, что GTK+ жрет меньше памяти. Больше -- не в курсе. Или может даже есть мнение за чем будущее? (Может за чем-то еще, кроме этих двух, а сюда не стоит и соваться?) Вроде как Nokia выбрала Qt, Motorola -- GTK+. С лицензией вроде как у GTK+ попроще.
V>Короче, что учить и использовать (или вообще что-то другое).
V>Спасибо.
Возможно имеет смысл посмотреть на библиотеку Ultimate++.
Единственный недостаток — нет порта на mac os x.
Преимущества: BSD лицензия, статическая линковка, поддержка алгоритмов сжатия и SQL, меньший в сравнении с QT размер исполняемых файлов, отсутствие moc — препроцессора.
))
Гораздо лучше — это сделать сабкласс существующего контрола и дописать требуемую функциональность
