Ставим отметки, кто чем пользуется.

Если выбираете вариант "другой", не поленитесь в сообщении указать какую.
Комментарии по теме приветствуются.

Модератор: пожалуйста, никаких тематических вопросов в этой теме.

M JackYF

Отредактировал. Имелись в виду графические библиотеки.

JackYF, а что вариантов ответа так мало? 
Разве этим списком ограничивается набор кроссплатформенных библиотек?
А как же icu, boost, libcurl, xerces+xalan(это хотя бы те, что покрывают некотрые неГУЁвые части Qt, причём, как правило, ф-ционал предоставляют лучший, чем Qt)?



Это сообщение отредактировал(а) archimed7592 - 24.11.2007, 01:43

Может тогда переделать вопрос на "Какими графическими кроссплаттформенными библиотеками вы пользуетесь"?

По сабжу ответил Qt

ответил wx, хотя это уже в прошлом))

Qt (на уровне "с доками накалякаем"). Последний месяц (и в будущем с января) пришлось углубиться в gtk2 - полный Ацтой по сравнению с Qt (по функциональности, юзабилити (ООП рулит), документации (по Qt4 она в разу лучше) ).

Qt мне конечно очень нравится, как и Windows и все остальное коммерческое. Но я не настолько богат, чтобы использовать ее в своих проектах. Поэтому приходится обходиться либами попроще: 

• wxWidgets (очень удобная, гибкая, но если использовать GTK - возможны тормоза, с x11 все ок; отлично документирована), 
• fox - очень нравится скорость работы, но плохо документирована и удобство не на высоте.

У Qt двойная лицензия - для коммерческих проектов коммерческая, для остальных - GPL2.

У меня сейчас основная Qt
а так еще Tk и Gtk

Голосовал за Qt.
Уже сказано о удобстве использования, великолепной документации и т.д. и т.п., от себя же хочу добавить что как только начал с ней знакомиться она просто прикипела как родная и на другие даже смотреть неохота.
Раньше пробовал изучить Tk, но как то не пошло, а здесь получаешь удовольствие от ее изучения и применения, даже не верится что все так просто. (-:
З.Ы. не реклама, а исключительно ИМХО (-;

+1000000000000

Изучаю QT. До этого программы с графическим интерфейсом писал только с использованием windows forms. Разница конечно...нет слов. QT - рулит  

мдаа... преимущество Qt в голосовании подавляющее   
что, впрочем неудивительно   

Это сообщение отредактировал(а) anatox91 - 7.6.2008, 12:59

+1 qt. На данном этапе изучаю. Библиотека сделана на ура!      

А я против, как из принципа(против массы и лукавых маркетологов), так и по сути. wxWidgets ничем QT не уступает. Юзал обе. Сейчас делаю на wxWidgets довольно тяжелый проект с обработкой растровой графики и видеопотоков, векторной графикой, полноценным GUI, взаимодействием с внешними устройствами и БД. Никаких преимуществ QT над wxWidgets не вижу.

Цитата провоцирующая на холивар  Если проводить раскопки, то минусы и плюсы можно найти везде. 

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

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

Мне нравится intel компилятор за хорошую оптимизацию кода, мне нравится компилятор microsoft за скорость выполнения кода, мне нравится gcc за кроссплатформенность и придерживание стандартов.

Мне нравится ассемблер за то, что он не ограничивает меня ни в чем, с ним я чувствую себя свободно. С ним для меня есть только один тип данных - байт, остальное - вариации. Это то, что позволяет заглянуть внутрь любой программы независимо от языка программирования.

и т.д., можно продолжать долго.

А Qt я выбрал не потому, что он лучше wxWidgets, просто я еще не чувствую, что Qt я знаю хотябы на 70%, чтобы изучать другую библиотеку и начать проводить параллели. Но что-то мне подсказывает, что 90% классов, которые есть в Qt я найду в любой другой библиотеке, хотябы потому, что конкуренция ведет к стиранию разницы. Т.ч. перескочить с одной на другую врятли будет большой проблемой.

SABROG, Вот задвинул!
+1

приходится работать с QT под KDE, а GTK под Gnome, но мне больше нравится конечно Qt, из-за документации и красивого ООП + хоть некоторые книги есть на русском

Долгое время работал с мфс. Сейчас решил перейти на бесплатную библиотеку. Выбор пал на виджеты (причина банальна - есть кому помочь с ними). Что понравилось:

1) просто огромное количесвто паралеллей с хорошими вещами мфс. То, что в мфс было неудобно - исправлено на лучшие вещи. 
2) следствие из первого - достаточно быстро можно перенести программу с мфс на кросплатформенность
3) Хорошая интегрируемость. Это я про отдельный редактор дилогов.

Не понравилось:
1) Отсутствие литературы. Ну или ее настолько мало что просто не достать
2) Отсутствие документации по сборке и функционалу "в коробке" (пришлось все выкачивать отдельно)

В целом для меня плюсы перевесили минусы ))

На какую, если не секрет?

судя по посту выше, wxWidgets

Меня сильно удивил в результате опроса тот факт, что wxWidgets популярнее чем Gtk+ - так как второй является основой Gnome, а он, в свою очередь, единственный конкурент KDE (тобеж Qt), да и вообще сообщество Gnome огромно (самый полпулярный дистрибутив Linux - Ubuntu - устанавливается с Gnome), а вот о wxWidgets ничего не слышно...

Может быть это потому что не все программисты линуксоиды(и наоборот)?.. Да и вообще выбирать библиотеку по ДЕ я бы не стал, ибо сам юзаю гном, а пробую изучать Qt, и не потому что мне КДЕ нравится, а потму что для меня Qt удобнее (сигналы и слоты - они прекрасны), Gtk например сразу как то не пошел) А теперь совсем не хочется пересаживаться на что то другое) Так и с виджетами, кто то попробовал - понравилось, и просто не захотел переходить на что то иное.

нет, не в этом дело.
я использую и пишу под линукс. видавс видел очень давно. GTK не использую ибо оно Си. Qt использую чтоб какой-то гуй быстро накодить. но технически, wxWidgets нравится больше.
еще есть прекрасная либа для создания гуя - egui. жаль что только под венду :(

Работал на всех сдесь приведенных фреймворках.. мой выбор пал на Qt потому что я ярый приверженец С и С-подобных языков(в часиности С++)
мне на нем работать проще и проекты быстро поднимаются.. 

Сам Линуксоид. 
Ось - Gentoo Base System release 2.0.1
Компилятор - gcc version 4.3.4 (Gentoo 4.3.4 p1.0, pie-10.1.5)
Фреймворк - Qt: 4.6.2
ДМ - KDE Development Platform: 4.4.5 (KDE 4.4.5)
IDE - QtCreator - 1.3.1

А на счет вашего спора - могу сказать что он не имеет конца ибо вопрос из темы кому что нравится.. и можно до безконечности спорить чей язык мощнее или чья среда удобнее.. У всего есть плюсы и у всего есть минусы.. К примеру Пролог тоже очень полезный и малоиспользуемый язык но для написания экспертных систем - нет ничего лучше (опятьже ИМХО)

А никто особо и не спорит ;-)

Нашел для себя еще один плюс виджетов. Можно сидя под линухом спокойно собирать программы под винду. Не знаю, может в Qt такое тоже можно - не пробовал.

Это называется кросс-компиляция. Qt тоже можно настроить.

Присоединяюсь, Qt пока ещё знаю плохо, что бы на другие глядеть - а свободного времени 0. Но в целом очень радует, особенно документация.

не участвовал в опросе, так как не владею знанием не одним из виджетов, сейчас решил освоить кросплатформенный виджет для gui 
qt не устроил ибо при статической линковке:
1. нужно платить
2. размер программы получается существенный
при динамической приходится тягаться с библиотеками... примерно также как давно было с net. framework - пришлось ставить библиотеку 2.0 которая тогда весила гдето метров 20 (это было еще до выхода vistы)

читаю описание WxWidgets в вики:
вот это хорошо, имхо. буду смотреть пока эту.

а gtk как работает - с ОС элементами или создает свои элементы?
чтот смотрю в опросе ответили 17 тел "другой", а в коментах помимо TK больше ничего не заметил.

ps: подскажите вот знаю что в win можно использовать windows region (непрямоугольные окна), а linux или macos тоже может так? и какие виджеты это поддерживают? в вики написано tk поддерживает, однако Последняя версия 8.5.7 (15 апреля 2009 года) - она того? 

Это заявление не верно. Точнее, не совсем верно. Сто раз уже обсуждалось повторяться не буду.


Технические статьи из русскоязычной Педивикии цитировать при нулевой компетенции в вопросе крайне глупо. Почти всегда попадёте впросак. Приведённая цитата обсуждалась так же сотни раз. В настоящий момент времени всё, что там написано - бред.


Существенный - это сколько, простите, в граммах?


Вот в который раз читаю и всё никак не пойму - что тягостного то?

Добавлено через 2 минуты и 27 секунд

Вот там точно свои.

Добавлено через 3 минуты и 13 секунд

Tk в 2011 можно использовать разве что для прототипирования.

Добавлено через 12 минут и 49 секунд

Из более-менее живого и используемого есть ещё FLTK, FOX, Ultimate++.

а ну видимо я ошибся при GNU LGPL можно статически линковать... \\?
существенный ну в зависимости от функциональности. к примеру windjvu, mtorrent, virtualdub
заметь этим программам не нужно тягать в своем дистрибутиве к примеру библиотеку QtGui4.dll (почти 10 мб)


ну, эт... самое...) раз такой умный, может сам напишешь что там должно быть на твое усмотрение, я скажу спасибо и остальные пользователи рувики (хотя думаю тебя это не мотивирует)

ps: можно ли на qt написать программу которая по сути имеет лишь несколько графических элементов ( кнопка, комбобокс, таблица) размером <1 мбайт? < 100 кбайт? подразумевается статическая линковка

Явным образом LGPL не запрещает статическую линковку. В тексте лицензии вообще нет упоминания ни о каких линковках. Но там есть следующий момент. Должна существовать возможность связывания вашего ПО с новейшей версией программы или библиотеки, охваченной LGPL. 

Что для этого сделать написано в пункте 4d. Под циферкой 1 речь идёт как раз о той самой динамической линковке:


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

Но это вопрос неоднозначный. То есть, если открывать исходники, то тут то всё однозначно и правильно. А вот вариант с предоставлением объектного кода спорный. Так что обычно рекомендуют LGPL-библиотеки линковать динамически, если не хотите открывать исходный код. Даже у Qt это не раз озвучивалось.

Но если стоит вопрос "Позволяет ли LGPL статическую линковку?", то ответ "Да, конечно." Только исходный код придётся открыть. Ну или вот этот спорный вариант с объектным кодом использовать...


Забавные у тебя примеры. Windows-only программы сравнивать с программами, написанными под кросс-платформенную либу? Смеёшься?


Спасибо, что просвятил.  


Меня это мотивирует не достаточно. Скажем так - есть дела и поважнее.


Я статически ни разу не линковал. Но думаю, что ответ, скорее, отрицательный.

Если тебе не нужна кросс-платформенность и при этом нужен (уж не знаю зачем, демосценщики вы наши  ) столь малый размер программы, ты ошибся разделом. Подумай об этом.

Qt не сильно предназначен для создания программ уровня "привет мир". Основное - создание бизнес-приложений (например, Adobe Photoshop). В таких приложениях размер библиотеки 10-20 МБ не считается чем-то экстраординарным. Зато очень ценится возможность быстро написать основную часть программы не заморачиваясь на создание кнопочек/окошек, а так же при необходимости портировать на другую платформу.
Например, начинающий программист вряд ли оценит то, что интерфейс для работы с таблицей в SQL БД делается всего в 10-20 строк. Ну не надо ему это...

Gtk+ пытается в Windows работать точно также как и Qt - получает через системный вызов битмап с отрисованным контролом (или же его части) и блитит его на окно. Но так как почти всем плевать на поддержку win32-версии gtk+, то до ума рендеринг системной темы не доведен (например отсутствует анимация fade in/out в Vista/7).

Это ваше Qt использует MOC, что не является нативными сями, плюс лицензия.
wxWidgets действительно использует нативные контролы и весит много меньше. Хеломир меньше метра собрать реально, возможности сопоставимы с кт.
Так что именно по этому его и выбираем!

Ах да, хочу передать привет тем людям, кто считает, что .net - это нормально. Вас проклинают те люди, которым из-за вашей проги с одной кнопкой нужно тащить 30 метров этого уродства.

Это сообщение отредактировал(а) Randajad - 10.6.2012, 16:45

основной плюс при выборе Qt - это документация (и онлайн и асситент интегрированный в creator).


=) после определнного момента перестаёшь обращать внимание не то что на чистоту языка, а вообще на язык. Любой необходимый базис нового языка изучается за неделю на ура. Так что это скорее предрассудок. Или вы про инструментарий (компиляторы)? В таком случае даже "чистый спп" (например 2011) не всеми компиляторами поддерживается в полной версии.


А в чём проблема с лицензией.
Если пишешь для себя, то спокойно юзай опенсорс вариант.
Если ты продаёшь свой продукт (и продаёшь успешно) то спокойно можно отстегнуть за удобный инструмент (ты же по сути тоже за свой труд хочешь деньги получать).


Размер результирующего файла (из личного опыта) интересует разве что определённую группу программистов, придающих этому внимание.
Остальных и пользователей в том числе это интересует по сути в последнюю очередь.
Есть конечно исключения для эмбеддед систем, но там обычно вообще на си и асме пишут.

MOC можно приделать далеко не к любому IDE. Qt становится невозможно юзать без перехода к другому IDE.
Конечно можно отстегнуть, наверное так и надо делать. Слово экономия нам чуждо. Действительно, сейчас все богатые, а в компьютерах харды уже на террабайты и памяти гигабайты. 
Реализуя какой-нибудь алгоритм в своем приложении вы так же мыслите, позвольте поинтересоваться? 

Если минус wxWidgets - это документация - да, там есть пробелы в ней. Но они не такие значимые, имхо.

Лицензия Qt не запрещает продавать свой продукт, сделанный из опенсоурс библиотеки. Даже не нужно, чтобы ваше приложение имело бы такую же лицензию. Главное - не изменять саму библиотеку.


А надо ? Есть IDE лучше, чем QtCreator под линукс и студия плюс Qt-шный аддон для Windows ?


Вот полностью согласен (никогда не понимал эту "определённую группу"). Randajad, вот скажи, неужели ты из двух программ, решающих  примерно одинаковые задачи (например - месенджеры QIP и PSI), выбираешь исключительно по тому, сколька каждая "весит" ? Разве не удобство, функционал, неглючность и т.д. и т.п. ?

Randajad, ты не о том говоришь.
первый и основной минус кути в том, что она не может без moc`а. а тот в свою очередь, не дает кодить в привычном для меня стиле, ибо запрещает шаблоны.
второй минус(на мой взгляд) - размножаются ###кодеры.

Randajad, позволь вопрос - ты зарабатываешь программированием? Если да, то за свой труд ты бы хотел получать деньги? Почему же давит жаба оплатить труд других программистов, результатами которого ты пользуешься для своего заработка?
 Да и касательно использования опенсор для своей коммерции borisbn уже сказал. Просто до версии 4.5. наша фирма именно коммерческую лицензию покупала - вот я и по инерции - но суть таже.


Зависит от "контекста" задачи (ТЗ, сроки выполнения и т.д.)


разве? Спокойно юзаю шаблоны по мере необходимости.

Это сообщение отредактировал(а) _GRIN_ - 11.6.2012, 23:37

значит твоя необходимость мала.

Вполне возможно, но мне хватает (шаблонные классы, шаблонные методы, шаблонные функции).

boostcoder, а можно пример кода (не зависимого от какой-либо библиотеки) содержий шаблон, который QtCreator не осилит?
Признаться очень интересно посмотреть.

Это сообщение отредактировал(а) _GRIN_ - 11.6.2012, 23:18

все-таки который MOC не осилит

закодь любой класс наследник QObject, и сделай его частичную специализацию основываясь на компайл-тайм типах/константах. тут-то moc скажет, что он о тебе думает 

Добавлено @ 23:33
хотя я удивлен тому, что кто-то этого не знает.
признаюсь, с использованием Qt не кодил уже больше двух лет. возможно moc пофиксили... но очень сомневаюсь. иначе его бы пришлось научить специализировать шиблоны и генерить GIMPLE. а это наверное половина компилятора.

Добавлено @ 23:37
а в качестве сигналов/слотов, он уже позволяет использовать шаблонные методы/функции/функциональные_объекты/лямбды?


Это сообщение отредактировал(а) boostcoder - 11.6.2012, 23:38

такой пример (из одного моего работающего на местах) проекта подойдёт:


тут правда шаблон нужен только в методе setPrivate() и там только конструктор шаблона с параметрами вызывался.
Но ничего другого под рукой нет к сожалению.

З.Ы. Я всё ещё достаточно плохо знаю кьют. Так что действительно посмотрел бы на ваш код илюстрирующий проблему.
Единтвенное ограничение, которое я знаю - это запрет множественного наследования qobject классов.

Добавлено через 5 минут и 11 секунд

alexvs11, ваше замечание абсолютно верно =).
Мос имеет свои ограничения, и свои плюсы (сигналы слоты).
Сам по себе кьют использует moc для сигналов слотов. Если эти плюсы не нужны, то можно спокойно забить на moc и использовать кьют без генерации moc-файлов как обычно - просто не объявляйте Q_OBJECT (правда и без сигналов-слотов останетесь)

так как посылать/принимать сигналы могут только наследники QObject (вроде не только, но там с какими-то извращениями), то из этого списка вопрос только о шаблонных методах
http://doc.trolltech.com/qq/qq15-academic.html
думаю, что и сейчас невозможно


видимо это достаточно редко требуется на практике?

не видно как используется CComplectT.


в псевдокоде:


типа этого.

касательно же:

это вряд ли.

Добавлено через 58 секунд

видимо по разным книжкам учились?

Qt 5. http://qt-project.org/wiki/New_Signal_Slot_Syntax

т.е. в конце этого месяца должен выйти релиз?

отсюда.

Судя по тому, что пока нет бетты, то и релиз запоздает.

Любитель, к сожалению и в этом варианте нет шаблонов. boostcoder прав - нет в Qt возможности связать шаблонный сигнал с шаблонным же слотом. А надо ?

без этого никак.
какой-то недо-С++ получается. собственно и кутю не назовешь С++. так...Си с классами, не более.

Речь о том, что функциональные объекты (в том числе лямбды_ могут выступать в качестве слотов.
А вот шаблонные сигналы.. Да, этого нету. Но откровенно область применения достаточно низкая (примеры приветствуются). Сигнал - это по сути часть интерфейса класса (обычный observer), мне лично сложно представить удачный пример, где реально нужен прям шаблонный сигнал.

Ну да, и если говорить про систему сигнал/слотов и пр. - то кроме Qt более удачной гуи либы для С++ я лично не знаю. Те жалкие function poiunter-ы в качестве колбэков в GTK+ или MFC-style месадж мэпы в wxWidgets.. Ужас 

Можно, конечно, начать разговоры, что не нужно писать гуи на С++ итд, но это уже в другую тему надо.

вот, както так

Почему же в другую ? Я вот, например, сейчас как раз в поиске чем заменить гуи... Смотрю в сторону Java (нравится) и до-диез .Net (тоже)...
ИМХО те, кто делает гуи на Си++ - делают это по одной простой причине - больше ничего не знают (я, кстати, в их числе... пока...).
Лично мне Си++ нравится, но делать на нём гуи или веб-приложения - увольте...
Однако, если больше ничего не знаешь/не хочешь знать (нужное подчеркнуть), то КуТя - лучший вариант. ИМХО, ессно

Это сообщение отредактировал(а) borisbn - 12.6.2012, 18:59

вот уж не сказал, что на java удобней гуй делается, что с swing'ом, что например в андроиде
в кутях же теперь к тому же будет javascript'овая морда (QML)

Это сообщение отредактировал(а) alexvs11 - 12.6.2012, 18:59

насколько я понял, на андрюшке просто ничего другого нету (можно только длл-ки какие-то низкоуровневые делать на плюсах - NDK, кажется)

что-то как-то о QML не очень позитивно народ отзывается - http://forum.vingrad.ru/forum/topic-347579.html

Давайте плз в теме С++ не обсуждать прочие технологии. Для этого есть другие разделы на форуме.

Да, товарищи, прежде чем писать пост, посмотрите на заголовок темы. Про Qt5 лучше обсуждайте в отдельной теме.

В wxWidgets обработку событий можно делать через вызов Bind/Connect. Просто слишком много туториалов написано с использованием таблиц диспетчеризации, в т.ч. и их примеры.

а шаблонные функции надо?

расширим приведенный выше код так:

в первой точке, какой тип передается сигналом?
во второй точке тот же вопрос.
и самое интересное в третьей точке: мне что, писать слотов столько, сколько типов педедает сигнал? - бред же. это именно та ситуация, когда слот должен быть шаблонным. но кто его специализировать будет? moc? ;)

именно по этому я и говорю, что кутя не позволяет кодить в хорошем стиле . в стиле "Си с классами" - да, пожалуйста.


Это сообщение отредактировал(а) boostcoder - 28.6.2012, 11:33

как раз для такого случая есть вполне сносный костыль QVariant. Он в куте повсюду используется.

Добавлено через 2 минуты и 9 секунд
Кстати, обрати внимание, как тема называется:

костыль, иначе не назовешь. зачем статически типизированный ЯП превращать в динамически?


а это к чему?

то что нормальный гуй на таком построен не будет

относительно чего?


на каком?
о чем речь?

Что вы заладили с этими шаблонами? Отключайте moc, подключайте свою систему сигнал-слотов и вперед, творить, так сказать! Все что решается в рамках Qt - надо решать в рамках Qt. Если это не подходит, то сраные Q_OBJECT отключаются, и начинается любимый хардкор. 

так и делаю.
потому и говорю, что кути нинужно.