Здравствуйте, Сергей Савостин, Вы писали:
СС>Здравствуйте, 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 и живи спокойно.
Гораздо лучше — это сделать сабкласс существующего контрола и дописать требуемую функциональность
.
