Комментарии 191
НЛО прилетело и опубликовало эту надпись здесь
Digia просто огромные молодцы и я надеюсь что они возродят Qt Ambassador's Program, как и обещали.
Безусловно Digia делает очень много для развития Qt.
Но надо понимать, что цели у Digia совершенно другие, чем например были у Nokia.
Nokia торговала телефонами, она зарабатывала продажей телефонов, Qt был нужен ей, как основа экосистемы для привлечения разработчиков под платформу. Еще раз — Nokia нуждалась в огромном количестве лояльных разработчиков под платформу, она делала все для этого — программы поощерений, сертификации, конкурсы, семинары, конференции, централизованное коммунити и т.д.
Digia не продает телефоны, Digia продает время своих специалистов. Она зарабатывает разработкой софта. Qt для Digia это инструмент. Именно поэтому в Digia развивают поддержку новых платформ, именно поэтому появился cloud-сервис, именно поэтому появляются прокты типа boot to Qt — новые платформы это новые потенциальные клиенты. Но обратная сторона медали в том, что Digia не испытывает большой потребности в коммунити разработчиков, чтобы они не говорили они могли бы обойтись и своими силами, но если совсем прекратить общественную деятельность, то это вызовет потерю интереса к фреймворку, поэтому они держат среднюю позицию — показывают что заинтересованны в сообществе, но на деле ничего не меняется, уже два с половиной года Qt принадлежит Digia. Программы Ambassador нет, программа сертификации не обновляется и находится в стагнации на уровне Qt 4. Сайт Developer Network — не развивается, он просто есть и минимально обслуживается. Появляется все больше коммерческих решений на Qt от Digia, которые не доcтупны в OpenSource и т. д.
Выводы делайте сами.
Но надо понимать, что цели у Digia совершенно другие, чем например были у Nokia.
Nokia торговала телефонами, она зарабатывала продажей телефонов, Qt был нужен ей, как основа экосистемы для привлечения разработчиков под платформу. Еще раз — Nokia нуждалась в огромном количестве лояльных разработчиков под платформу, она делала все для этого — программы поощерений, сертификации, конкурсы, семинары, конференции, централизованное коммунити и т.д.
Digia не продает телефоны, Digia продает время своих специалистов. Она зарабатывает разработкой софта. Qt для Digia это инструмент. Именно поэтому в Digia развивают поддержку новых платформ, именно поэтому появился cloud-сервис, именно поэтому появляются прокты типа boot to Qt — новые платформы это новые потенциальные клиенты. Но обратная сторона медали в том, что Digia не испытывает большой потребности в коммунити разработчиков, чтобы они не говорили они могли бы обойтись и своими силами, но если совсем прекратить общественную деятельность, то это вызовет потерю интереса к фреймворку, поэтому они держат среднюю позицию — показывают что заинтересованны в сообществе, но на деле ничего не меняется, уже два с половиной года Qt принадлежит Digia. Программы Ambassador нет, программа сертификации не обновляется и находится в стагнации на уровне Qt 4. Сайт Developer Network — не развивается, он просто есть и минимально обслуживается. Появляется все больше коммерческих решений на Qt от Digia, которые не доcтупны в OpenSource и т. д.
Выводы делайте сами.
И хотелось бы почитать про их облачные сервисы
Забыли про QPA, позволяющую запускать один и тот же код на любой платформе, написав соответствующие плагины для общения Qt с OS.
Про вкусный-превкусный MVC я бы поспорил. Он неплох, когда задачи простые, но сделать тот же paging или асинхронный lazy loading не так-то просто.
paging отлично делается через свою прокси модель, а lazy laoding через модель с поддержкой fetch more, тут как раз никаких проблем нет.
Через прокси не пробовал делать paging, не подскажите, где почитать можно?
fetchMore хорошо работает, когда данные просто считал и вывел, а вот с асинхронной выдачей могут появиться проблемы. А уж если хочется добавить сортировку и фильтрацию, то тут тем более приходится усложнять. Я просто сравниваю с тем же SmartGWT, где подобные вещи делаются гораздо проще.
Тут тоже можно сделать свою реализацию, но каждый раз велосипедить нужно.
fetchMore хорошо работает, когда данные просто считал и вывел, а вот с асинхронной выдачей могут появиться проблемы. А уж если хочется добавить сортировку и фильтрацию, то тут тем более приходится усложнять. Я просто сравниваю с тем же SmartGWT, где подобные вещи делаются гораздо проще.
Тут тоже можно сделать свою реализацию, но каждый раз велосипедить нужно.
Не знаю, где почитать. Сам делал. Если нет иерархии, то можно использовать вообще просто SortFilter модель, где определять, показывать ли строку, в зависимости от того, попадает ли ее номер (index.row) в нужный диапазон.
Фильтрация и сортировка никак не влияют, их надо навешивать отдельными слоями прокси, составляя цепочку, в которой каждая модель делает только одно действие.
Именно асинхронную подгрузку я не делал, но на запрос canFetchMore в общем случае можете ответить true, при вызове fetchMore сразу добавить строку с текстом (иконкой, специальным фалогм) «Загружаюсь», запустить запрос, по получении ответа удалить строку «Загружаюсь» и вставить данные. Что вас смущает?
Фильтрация и сортировка никак не влияют, их надо навешивать отдельными слоями прокси, составляя цепочку, в которой каждая модель делает только одно действие.
Именно асинхронную подгрузку я не делал, но на запрос canFetchMore в общем случае можете ответить true, при вызове fetchMore сразу добавить строку с текстом (иконкой, специальным фалогм) «Загружаюсь», запустить запрос, по получении ответа удалить строку «Загружаюсь» и вставить данные. Что вас смущает?
просто SortFilter модельесли вы про стандартную QSortFilterProxyModel, то лучше не надо. На большом количестве данных она просто умирает. Ну тысячу строк в нее можно засунуть, не больше.
Начать надо с того, что он не MVC, а MV. Контроллер придется писать самому.
Во-вторых, готовые модели подходят только для довольно скромных размеров данных и простых задач. Надо чуть больше — извольте писать сами.
В третьих, QSqlDatabase и драйверы сделаны опять же только под простые задачи. Нет например управления уровнем изоляции транзакций.
Ну а в остальном — да, из коробки в принципе многое доступно.
Во-вторых, готовые модели подходят только для довольно скромных размеров данных и простых задач. Надо чуть больше — извольте писать сами.
В третьих, QSqlDatabase и драйверы сделаны опять же только под простые задачи. Нет например управления уровнем изоляции транзакций.
Ну а в остальном — да, из коробки в принципе многое доступно.
Я ожидал в статье не этого. Хотел увидеть именно опровержения всех ложных высказываний на тему Qt. Коих реально много. Особенно бесят люди, говорящие о тормознутости Qt. Например о тормознутости QTableWidget, напихивая в нее мильоны итемов в секунду. Хотя для этого нужно использовать QTableView, а QTableWidget вообще для этого не предназначен… хотя и его не умеют использовать правильно.
А так статья представляет собой капитанские высказывания про Qt, которые всем известны. «я наверное напишу об этом статью на днях.» — а вот этого очень жду.
А так статья представляет собой капитанские высказывания про Qt, которые всем известны. «я наверное напишу об этом статью на днях.» — а вот этого очень жду.
Если честно, после прочтения статьи в таком фанатичненьком лол-тадамц стиле, да еще и состоящей из маркетинговых слоганов чуть менее чем полностью — остается негативное послевкусие. И это при том, что Qt я люблю, и стараюсь использовать на всех доступных платформах.
Не знаю как вам, но для меня это бесполезный пост. Не то, чтобы конкретно этот призыв писать, используя Qt-фреймворк, плох (что тоже имеет место быть), скорее писать на C++/Qt это плохо, хуже, нежели писать на C#/Java. Почему и все так знают — язык программирования должен быть удобный и простой, не требовать больших затрат труда. Да этого придумывают новые и более удобные языки, ведь так? Ладно с ним, с С++ этим, Qt как-то пытается исправить эту плачевную ситуацию, но почему бы не посмотреть на WPF, например (если нужна кроссплатформенная поддержка, то можно подобрать что-то в Java)? Можно же разрабатывать, радоваться жизни, нюхать цветочки. Но некоторые С++-программисты, к сожалению, слепы, они будут продолжать писать, зарабатывая себе проблемы. Печально.
Пост конечно не очень полезный, но по факту с автором соглашусь — кьюти няшечка. Очень удобный фреймворк, кросс-платформенный, быстрый код… очень большой набор библиотек, + Кьюти расширяет си++, добавляя туда сигналы-слоты, что позволяет писать гуи без этой вереницы зависимостей, просто высылая и принимая сигналы.
Ня!
Вон, бедного rejjin какие-то люди заминусовали, не разобравшись в теме.
Qt — это как глоток свежего воздуха после MFC и VCL. Пятая версия вообще бомба (черт, QML просто потрясающая штука!). Но все же, блин, ребят, при всей крутости Qt, меня уже достало писать на C++. На дворе уже 2014 год, на свете есть множество языков, таких как Java, и мой любимый C#. Некоторые даже пишут на JS под десктопы например, и ничего.
Прости Qt, но есть WPF+C#. Сейчас на меня набросятся, мол «Оно же не кроссплатформенно», «Оно же не опенсорс», «Да это же творение M$ и злого Билли» (такое только школьники пишут, надеюсь на хабре таких минимум :) )".
Да, я знаю, что WPF только под винду. Я знаю, что WPF довольно долго (два года как) не обновляется.
Я знаю, что у WPF есть множество недостатков (голый WPF по асфальту не поедет, нужно с десяток велосипедов каждый раз изобретать, тот же MVVM). В противовес всему этому скажу — количество плюшек у WPF просто зашкаливает. Технология уже достаточно зрелая, в интернете очень много информации, написано достаточно качественной литературы. На том же StackOverflow сколько впфшников сидит. Ну и для винды она как-никак самая родная.
Опять же, если вы матерый C++ программист, не признающий остальные языки — Qt ваш выбор. Но хотя бы попробуйте разок в жизни C# или Java. Если вам нужно писать кроссплатформенные приложения, то попробуйте JavaFX. Очень похожая на WPF технология, только для Java. Есть еще FireMokey для олдскульных дельфистов, но Delphi уже как давно загнулся :)
Qt — это как глоток свежего воздуха после MFC и VCL. Пятая версия вообще бомба (черт, QML просто потрясающая штука!). Но все же, блин, ребят, при всей крутости Qt, меня уже достало писать на C++. На дворе уже 2014 год, на свете есть множество языков, таких как Java, и мой любимый C#. Некоторые даже пишут на JS под десктопы например, и ничего.
Прости Qt, но есть WPF+C#. Сейчас на меня набросятся, мол «Оно же не кроссплатформенно», «Оно же не опенсорс», «Да это же творение M$ и злого Билли» (такое только школьники пишут, надеюсь на хабре таких минимум :) )".
Да, я знаю, что WPF только под винду. Я знаю, что WPF довольно долго (два года как) не обновляется.
Я знаю, что у WPF есть множество недостатков (голый WPF по асфальту не поедет, нужно с десяток велосипедов каждый раз изобретать, тот же MVVM). В противовес всему этому скажу — количество плюшек у WPF просто зашкаливает. Технология уже достаточно зрелая, в интернете очень много информации, написано достаточно качественной литературы. На том же StackOverflow сколько впфшников сидит. Ну и для винды она как-никак самая родная.
Опять же, если вы матерый C++ программист, не признающий остальные языки — Qt ваш выбор. Но хотя бы попробуйте разок в жизни C# или Java. Если вам нужно писать кроссплатформенные приложения, то попробуйте JavaFX. Очень похожая на WPF технология, только для Java. Есть еще FireMokey для олдскульных дельфистов, но Delphi уже как давно загнулся :)
матерый C++ программист, не признающий остальные языки — Qt ваш выборА вот по моему наблюдению матерые программисты С++ достаточно прохладно к Qt относятся.
--но есть WPF+C#.
вы меня извините, но почему 8-ядерная машина с GT680 нещадно тормозит и еле ползает в дизайнере форм?
вы меня извините, но почему 8-ядерная машина с GT680 нещадно тормозит и еле ползает в дизайнере форм?
такое только школьники пишут, надеюсь на хабре таких минимум
Включая ТС :)
попробуйте разок в жизни C#
Делаем сейчас один проект, который является развитием старого кода написанного на C++ / MFC. Тоже вот нашлись, хм, энтузиасты C# / WPF, запоровшие идею реализации проекта на Qt. Но огромную существующую базу алгоритмического кода переписывать на C# было заведомо дохлым вариантом. Решили в итоге, значит, сделать вычислительное ядро на С++, остальное — на C#. Благо что плюсы все равно значительно превосходят C# по производительности, а для нас это было критично.
Ну что… написали мы этот гибрид. Получился откровенный отстой. UI написан хрен знает как, поддерживать его может только пара человек, которые сами этот код и писали, C# код представляет из себя жуткую кашу, которую нормально читать невозможно. Нет я знаю конечно что те же люди и на C++ / MFC воротили хреновый код, но даже там его было легче читать и менять. А на C# / WPF те же товарищи наворотили вообще нечто трудновыразимое — и это в простеньком в общем-то по UI приложении! Я уверен что был бы там Qt — код был бы на порядок читабельнее, там очень сложно писать UI плохо. Посмотрел я на это дело и что-то ни малейшего желания использовать C# у меня после этого не возникло. Да, там прикольная библиотека. Да, прикольные языковые возможности. Но библиотек и на C++ хороших много (и Qt — одна из лучших), а эти языковые возможности на практике были густо использованы для того чтобы намешать черти какой код. Ну и нафига мне C#? Если я умею писать код, то на C++ он получается не хуже по читаемости, надежности и скорости написания чем код на C#. А если некоторые мои коллеги пишут код абы как, то и на C# они создают непонятную и заполненную багами хрень. Приплюсуйте сюда разнообразные трудноразрешимые баги которые вылезают в проекте из-за совмещения C++ и C#. Особенно рельефно это все смотрится на фоне того что плюсовое ядро мы капитально переписали на совершенно новую технологию — и после создания своей библиотечки работать с высоконагруженым параллельным кодом работающим в реал-тайме в плюсах — одно удовольствие. Работает быстро, практически без багов (две штуки… и ни одного из них специфичного для C++), код красивый.
В общем, надо на C++ уметь работать — и тогда никакого желания на C# переходить не возникнет.
Хотя для простеньких проектов C# может и неплох — если, как Вы сами же пишете, таскать с собой с десяток велосипедов.
Но мне в таких проектах тоже проще с Qt работать, там и велосипедов тащить не нужно.
Из вашего комментария, к сожалению, не понять в чем заключается проект. Я не могу и не буду гадать о том кто виноват: C# или те полтора энтузиаста, которые отвечали за UI.
Но судя по данному фрагменту:
>>UI написан хрен знает как, поддерживать его может только пара человек, которые сами этот код и писали, C# код представляет из себя жуткую кашу, которую нормально читать невозможно.
Склоняюсь больше к последнему.
>>В общем, надо на C++ уметь работать — и тогда никакого желания на C# переходить не возникнет.
Поменяем C# и C++ местами и вуаля! Поменяем C# на %язык% и вуаля!
>>В общем, надо на C++ уметь работать — и тогда никакого желания на Python переходить не возникнет.
>>В общем, надо на C++ уметь работать — и тогда никакого желания на Java переходить не возникнет.
>>В общем, надо на C++ уметь работать — и тогда никакого желания на PHP (O_o) переходить не возникнет.
Но судя по данному фрагменту:
>>UI написан хрен знает как, поддерживать его может только пара человек, которые сами этот код и писали, C# код представляет из себя жуткую кашу, которую нормально читать невозможно.
Склоняюсь больше к последнему.
>>В общем, надо на C++ уметь работать — и тогда никакого желания на C# переходить не возникнет.
Поменяем C# и C++ местами и вуаля! Поменяем C# на %язык% и вуаля!
>>В общем, надо на C++ уметь работать — и тогда никакого желания на Python переходить не возникнет.
>>В общем, надо на C++ уметь работать — и тогда никакого желания на Java переходить не возникнет.
>>В общем, надо на C++ уметь работать — и тогда никакого желания на PHP (O_o) переходить не возникнет.
Проект — 3D сканер и CAD система к нему. И что до UI то я безусловно согласен что проблема там не в C#, а в энтузиастах, которые решили его применить. Да, звезд они с неба не хватают, хотя код они выдают вполне рабочий. Я просто не понимаю какой толк от использования C#/WPF? С квалифицированными специалистами на C++ результат будет лучше — C# не имеет в квалифицированных руках преимуществ перед С++. Я предполагал что от C# будет толк хотя бы в плане того что на нём менее квалифицированные товарищи смогут приличный UI быстро сделать. Как оказалось — тоже нефига, те кто говнокод на C++ пишут, на C# генерят еще более страшный говнокод. Где тогда ниша у C# и WPF, в чем преимущества этой технологии?
Вот я смотрю на наш проект и думаю: два человека работали над UI почти год. UI пока сводится, по сути, к двум десяткам кнопок и менюшек, которые надо оформить согласно дизайн-макету. На C# / WPF два средней руки специалиста сгенерили под это дело монструозный код который — при всей простоте функционала! — мало кто может понять. На мой взгляд это — EPIC FAIL технологии. Если бы те же двое пользовались Qt, они сгенерили бы за тот же срок чуть лучший по качеству проект, который было бы намного легче понять и в котором не было бы геморроя с интеграцией C# + C++. Если бы на месте эти двоих был один отличный специалист, то он реализовал бы на порядок лучший код на Qt за два месяца. Может отличный специалист и на WPF выдал бы отличный код за два месяца — но выгоды-то все равно не было бы. Вот с MFC было бы хуже, да — там 6 месяцев ушло бы у отличного специалиста, а те двое вообще непонятно что бы выдали. Но так трудно придумать что-то страшнее чем MFC.
В какой-то степени да. На плюсах можно писать все что угодно. Но для некоторых проектов некоторые специально заточенные под такие проекты языки дают какую-то выгоду.
К Python у меня смешанные чувства. Он удобен для простеньких скриптов и управления, но качество кода, по крайней мере у нас, хромает в результате скоростной разработки на обе ноги. Как только python разрастается в что-то большее — получается сложная в поддержке и отладке хреновина. Плюсы хуже подходят для мелочи, но они масштабируются до сколь угодно больших проектов без потери качества и понятности кода.
На PHP писал код когда-то ооочень давно и этот язык оставил смешанное впечатление. Тогда я был новичком и мне он показался удобным (пишем в плюс: подходит для малоквалифицированных персонажей), плюс интеграция с веб-сервером куда удобнее чем в плюсах. Но сейчас я подобного качества код мне писать будет стыдно, а как его на PHP улучшить я не представляю. Может и можно, впрочем — не рискну судить, очень давно не занимался. В высоконагруженных проектах, впрочем, как я слышал, он дохнет — не случайно google на плюсах и JS свои веб-сервисы пишет. Я конечно понимаю что сегодня модно просто поставить дохрена серваков на которые нагрузку будет разбрасывать C++-код написанный гораздо более профессиональными ребятами :D, но я не люблю подобных решений.
С Java дел не имел, ничего не скажу. Коллеги, впрочем, как-то сталкивались с героями, замутившими лет восемь назад на Java огромную enterprise-систему. Говорят сделано все было по коду очень красиво, но тормозило и память жрало совершенно безбожно. Но я так понимаю что производительность Явы с тех времен заметно шагнула вперед, так что сейчас, вероятно, для каких-то проектов типа «красивого интерфейса к БД» это очень правильный выбор.
А вот для C#/WPF я нишу что-то не вижу. Для работы с БД думаю Java будет лучше. Для производительных десктопных приложений — лучше C++/Qt (и это не только наш 3D сканер и прочие AutoCAD-ы, но и такие приложения как Word и Excel). Для высокопроизводительных серверных приложений лучше голый C++, если вопрос производительности менее приоритетен чем скорость разработки — то какой-нибудь специализированный язык, хоть бы и PHP. Разве что нативные shareware приложения под винду делать, чтобы look&feel был аутентично микрософтовским и библиотеки не надо было в инсталляторе таскать.
Вот я смотрю на наш проект и думаю: два человека работали над UI почти год. UI пока сводится, по сути, к двум десяткам кнопок и менюшек, которые надо оформить согласно дизайн-макету. На C# / WPF два средней руки специалиста сгенерили под это дело монструозный код который — при всей простоте функционала! — мало кто может понять. На мой взгляд это — EPIC FAIL технологии. Если бы те же двое пользовались Qt, они сгенерили бы за тот же срок чуть лучший по качеству проект, который было бы намного легче понять и в котором не было бы геморроя с интеграцией C# + C++. Если бы на месте эти двоих был один отличный специалист, то он реализовал бы на порядок лучший код на Qt за два месяца. Может отличный специалист и на WPF выдал бы отличный код за два месяца — но выгоды-то все равно не было бы. Вот с MFC было бы хуже, да — там 6 месяцев ушло бы у отличного специалиста, а те двое вообще непонятно что бы выдали. Но так трудно придумать что-то страшнее чем MFC.
Поменяем C# на %язык% и вуаля!
В какой-то степени да. На плюсах можно писать все что угодно. Но для некоторых проектов некоторые специально заточенные под такие проекты языки дают какую-то выгоду.
К Python у меня смешанные чувства. Он удобен для простеньких скриптов и управления, но качество кода, по крайней мере у нас, хромает в результате скоростной разработки на обе ноги. Как только python разрастается в что-то большее — получается сложная в поддержке и отладке хреновина. Плюсы хуже подходят для мелочи, но они масштабируются до сколь угодно больших проектов без потери качества и понятности кода.
На PHP писал код когда-то ооочень давно и этот язык оставил смешанное впечатление. Тогда я был новичком и мне он показался удобным (пишем в плюс: подходит для малоквалифицированных персонажей), плюс интеграция с веб-сервером куда удобнее чем в плюсах. Но сейчас я подобного качества код мне писать будет стыдно, а как его на PHP улучшить я не представляю. Может и можно, впрочем — не рискну судить, очень давно не занимался. В высоконагруженных проектах, впрочем, как я слышал, он дохнет — не случайно google на плюсах и JS свои веб-сервисы пишет. Я конечно понимаю что сегодня модно просто поставить дохрена серваков на которые нагрузку будет разбрасывать C++-код написанный гораздо более профессиональными ребятами :D, но я не люблю подобных решений.
С Java дел не имел, ничего не скажу. Коллеги, впрочем, как-то сталкивались с героями, замутившими лет восемь назад на Java огромную enterprise-систему. Говорят сделано все было по коду очень красиво, но тормозило и память жрало совершенно безбожно. Но я так понимаю что производительность Явы с тех времен заметно шагнула вперед, так что сейчас, вероятно, для каких-то проектов типа «красивого интерфейса к БД» это очень правильный выбор.
А вот для C#/WPF я нишу что-то не вижу. Для работы с БД думаю Java будет лучше. Для производительных десктопных приложений — лучше C++/Qt (и это не только наш 3D сканер и прочие AutoCAD-ы, но и такие приложения как Word и Excel). Для высокопроизводительных серверных приложений лучше голый C++, если вопрос производительности менее приоритетен чем скорость разработки — то какой-нибудь специализированный язык, хоть бы и PHP. Разве что нативные shareware приложения под винду делать, чтобы look&feel был аутентично микрософтовским и библиотеки не надо было в инсталляторе таскать.
Имхо в C# есть 3 вещи которые к сожалению C++ пока не снились и которые очень сильно ускоряют разработку:
1) Нормальный туллинг (Отличный отладчик в VS и ReSharper + NuGet). Ничего подобного уровня в C++ просто не существует. Блин я 2014 году экосистема у которой нет управления зависимостями — это полный… (и не надо мне говорить про CMAKE например — тот еще ужос)
2) Языковые возможности которые дают писать, предсказуемый и читабельный код (Async-Await, Generics, LINQ). Этого крайне не хватает.
3) Библиотеки. Я промолчу про стандартную библиотеку. Но без Autofac, WCF, WPF, MEF и еще череды отлично задизайненых и сделанных библиотек разработка оказывается очень тяжелой. Да у C++ есть boost — но лучше бы его не было. В этой мешанине классов, подходов и темплейтов очень сложно разобраться. Имхо единственная логичная библиотека на C++ это stl. Но в ней очень маленький набор примитивов.
В это месте вы можете вернутся по тексту назад и поменять C# на Java. Результат будет практически тот-же (поменяются названия библиотек и языковые возможности).
Эта фраза мне напоминает — вобщем надо уметь водить тогда с 9ки на BWM желаниея пересесть не возникнет.
Это далеко не так. (Я при это не сравниваю С++ с 9кой а C# с BMW, просто хочу показать на некорректность вашей фразы)
1) Нормальный туллинг (Отличный отладчик в VS и ReSharper + NuGet). Ничего подобного уровня в C++ просто не существует. Блин я 2014 году экосистема у которой нет управления зависимостями — это полный… (и не надо мне говорить про CMAKE например — тот еще ужос)
2) Языковые возможности которые дают писать, предсказуемый и читабельный код (Async-Await, Generics, LINQ). Этого крайне не хватает.
3) Библиотеки. Я промолчу про стандартную библиотеку. Но без Autofac, WCF, WPF, MEF и еще череды отлично задизайненых и сделанных библиотек разработка оказывается очень тяжелой. Да у C++ есть boost — но лучше бы его не было. В этой мешанине классов, подходов и темплейтов очень сложно разобраться. Имхо единственная логичная библиотека на C++ это stl. Но в ней очень маленький набор примитивов.
В это месте вы можете вернутся по тексту назад и поменять C# на Java. Результат будет практически тот-же (поменяются названия библиотек и языковые возможности).
В общем, надо на C++ уметь работать — и тогда никакого желания на C# переходить не возникнет.
Эта фраза мне напоминает — вобщем надо уметь водить тогда с 9ки на BWM желаниея пересесть не возникнет.
Это далеко не так. (Я при это не сравниваю С++ с 9кой а C# с BMW, просто хочу показать на некорректность вашей фразы)
Эта фраза мне напоминает — вобщем надо уметь водить тогда с 9ки на BWM желаниея пересесть не возникнет.
Давайте все же подбирать адекватные примеры. «Надо уметь водить, тогда с BMW на механике желания пересаживаться на Хонду с автоматом не возникнет». C++ имеет ведь крупные преимущества, особенно в скорости? Имеет. Вот и давайте смотреть на ситуацию где вождение требует определенной квалификации но окупается уровнем этого вождения, а остальные детали отличаются не столь сильно. Лично я умею ездить на механике — и желания перелезать на менее быструю и менее управляемую машину у меня не возникает, а вот скажем, супруга не умеет — и для неё автомат получается на порядок удобнее :).
Теперь по остальным пунктам
1) Тулинг у C# лучше, согласен. Но грамотно настроенный C++ немногим хуже. Лично мне, честно говоря, вообще хватает большинства дефолтных возможностей студии, но если есть желание подтащить фичи ближе к уровню C#, то просто ставится Visual Assist
1.1) Управление зависимостями — да, согласен, одно из самых слабых мест. Сложно, требует привыкания, подвержено багам. Но по моим впечатлениям и C# там неидеален. У нас в сборке как я писал есть C# код, причем он растащен по нескольким солюшенам и часть кода импортирует что-то из других солюшнов. Когда время от времени объем импортируемого меняют а другой солюшн обновить забывают, то Студия выдает совершенно безумные сообщения об ошибках импорта, из которых совершенно неясно как их исправлять. Просто вот мол есть объект такой-то, а откуда он вообще берется, где объявлен, где ищется — загадка. Из космоса, видимо, приходит. Где-то глубоко в настройках проекта прописан HintPath, вот только по нему и можно, считай, догадаться, где должно лежать недостающее. В плюсах подобные ошибки выдают гораздо более понятное сообщение. Впрочем возможно это дело привычки.
2.1. Async-Await дали у нас откровенно хреново читаемый код. Вот предсказуемый — это да, ибо копи-паст. Но в целом по крайней мере у нас он дал плохой код. Лучше чем то что бы сделал для решения той же задачи на C++ новичок, но намного хуже того, как можно было бы реализовать код нормально
2.2. Generics — это же официально недотемплейты, вроде :)?
2.3. С LINQ и вообще в целом с БД дел не имел, так что верю на слово что удобно :)
3. У C++ есть Qt и в паре с boost ом из «библиотек на все случаи жизни» больше просто ничего не надо. Специализированные библиотеки на все случаи жизни на C++ вообще найти проще, на C/C++ профессионального кода написано гораздо больше чем на C#.
3.1. boost это вообще-то очень разнородная коллекция. Там есть конечно зубодробительные темплейты, но большая часть библиотеки вообще-то как раз очень понятна и логична. Особенно удивительно слышать о том что «boost слишком сложно задизайнен» на фоне того что «stl единственная нормальная библиотека»: STL, особенно микрософтовский, как раз очень сложно устроен «внутри», да и головоломных решений типа codecvt и locale там хватает.
C++ имеет ведь крупные преимущества, особенно в скорости?
Раз уж пошли машинные аналогии, то какой суперкар самый быстрый, если ездить в центре Москвы? :) К слову, в шарпе с нативной компиляцией что-то там мутят, поддержку SIMD почти родили и т.п. Понятно, что не плюсы, но тоже движется.
если есть желание подтащить фичи ближе к уровню C#, то просто ставится Visual Assist
Проблема в том, что мощностью решарпера даже не пахнет.
В плюсах подобные ошибки выдают гораздо более понятное сообщение.
Это вы, конечно, тонко пошутили про вменяемые сообщения об ошибках в плюсах. :) Ладно, пусть в данном конкретном случае в плюсах ошибки более содержательные, но как насчёт тех же ошибок в шаблонах?
Специализированные библиотеки на все случаи жизни на C++ вообще найти проще, на C/C++ профессионального кода написано гораздо больше чем на C#.
Здесь плюсы — бесспорный победитель. По-моему, из мейнстримовых языков у плюсов самое огромное наследие кода. Шарпу такое не снилось.
Простите, а что именно вы делаете с MEF? По мне так простого он тяжеловат, для сложного — много ограничений. Я так и не могу понять куда б его можно…
MEF — это готовая библиотека для написания плагинов к приложениям, которая позволяет отлично делает service discovery, dynamic library loading и прочие не очень тривиальные штуки, для которых раньше надо было изобретать свои велосипеды. Вместе с Autofac — делает встраивание плагинов в ваше приложение совсем прозрачным и требующим минисального количества усилий.
Использовать его как основной DI фреймворк имхо — не разумно, хотя лично видел и такие решения. Причем они неплохо работали.
Использовать его как основной DI фреймворк имхо — не разумно, хотя лично видел и такие решения. Причем они неплохо работали.
Ну давайте взгляд наоборот: я переходил с C++ на C#
1) Жесть со стилем во всех полях. Многое приходится гуглить и тупо запоминать. Шаг вправо шаг влево — расстрел. Показательный пример: чтоб разобраться как ИСПОЛЬЗОВАТЬ биндинги мне пришлось перелопатить код Mono. Даже с QDbus такого не было. Кстати, после разбора, ни
1.1) Жестокая жесть в операторая сравнения, копирования со свистопляской ссылчно\не-ссылочный тип. Где простая замена ключевого слова class на struct может убить производительность в разы.
2) Жесть с передачей сигналов между потоками. Что-то подобного удобнейшим сигналам-слотам из Qt нет. В контроллах есть метод Invoke, а как быть, если я хочу сделать что-то подобное но уже в
2.1) Async\Awiat ничем не лучше, а местами и хуже, чем QtConcurent.
3) Жесть с WPF — QML гораздо проще, понятнее и гибче.
4) Жесть с Generic, требование, чтоб код компилировался на момент написания, а не в момент инстанцирования убивает последние остатки мощи.
5) Жесть эта жизнь без слоев в Windows Forms
I. Крайне удобная серриализация. Вот это конкретно спасает от головняка. В принципе ее можно сгородить и с помощью Qt, вроде ив буст что-то есть, но до удобства C# как до Луны
WCF не пользовался, но врядли это удобнее QDBus, до плагинов я не добрался в шарпах, в Qt есть класс для работы с ними.
LINQ — впринципе удобно, но использовал один раз и где там грабли лежат — пока не знаю.
И если вам не нравится cmake, то предлагаю использовать qbs. Но интеграция qmake и QtCreator помогает подключать завивисимости ничуть не сложнее чем в шарпах в студии
1) Жесть со стилем во всех полях. Многое приходится гуглить и тупо запоминать. Шаг вправо шаг влево — расстрел. Показательный пример: чтоб разобраться как ИСПОЛЬЗОВАТЬ биндинги мне пришлось перелопатить код Mono. Даже с QDbus такого не было. Кстати, после разбора, ни
1.1) Жестокая жесть в операторая сравнения, копирования со свистопляской ссылчно\не-ссылочный тип. Где простая замена ключевого слова class на struct может убить производительность в разы.
2) Жесть с передачей сигналов между потоками. Что-то подобного удобнейшим сигналам-слотам из Qt нет. В контроллах есть метод Invoke, а как быть, если я хочу сделать что-то подобное но уже в
2.1) Async\Awiat ничем не лучше, а местами и хуже, чем QtConcurent.
3) Жесть с WPF — QML гораздо проще, понятнее и гибче.
4) Жесть с Generic, требование, чтоб код компилировался на момент написания, а не в момент инстанцирования убивает последние остатки мощи.
5) Жесть эта жизнь без слоев в Windows Forms
I. Крайне удобная серриализация. Вот это конкретно спасает от головняка. В принципе ее можно сгородить и с помощью Qt, вроде ив буст что-то есть, но до удобства C# как до Луны
WCF не пользовался, но врядли это удобнее QDBus, до плагинов я не добрался в шарпах, в Qt есть класс для работы с ними.
LINQ — впринципе удобно, но использовал один раз и где там грабли лежат — пока не знаю.
И если вам не нравится cmake, то предлагаю использовать qbs. Но интеграция qmake и QtCreator помогает подключать завивисимости ничуть не сложнее чем в шарпах в студии
> Да, я знаю, что WPF только под винду.
и позже:
> В противовес всему этому скажу — количество плюшек у WPF просто зашкаливает.
Вот интересно прямо, как количество плюшек поможет мне решить проблему кроссплатформенности?
и позже:
> В противовес всему этому скажу — количество плюшек у WPF просто зашкаливает.
Вот интересно прямо, как количество плюшек поможет мне решить проблему кроссплатформенности?
Есть ещё Lazarus с lcl (он кстати и через Qt умеет, и не только) и он явно не загибается и кросплатформенность вполне удовлетворительная. Да и delphi от Embarcadero далёк от загиба что бы тут не писали (вышла xe10, всё живёт и продаётся, 23 го еду на семинар в Бохуме (Германия). Не стоит ассоциировать Delphi только с продуктами от Embarcadero или кому их там опять перепродали. Опенсоурсные Lazarus и Free Pascal вполне достойны внимания и работоспособны.
что позволяет писать гуи без этой вереницы зависимостей, просто высылая и принимая сигналыПравда это иногда приводит к совершенно непрозрачным связям между объектами, если разработчик «поведется» на обманчивую простоту этого механизма.
Почему и все так знают — язык программирования должен быть удобный и простой, не требовать больших затрат труда.
Вы когда-нибудь пользовались мультимедийной системой на аэрофлотовских 330-х Эйрбасах?
Писать гуи на С++ ну как-то совсем неохота. Сейчас полно динамических скриптовых языков, в разы меньше кода получается.
Оптимальный вариант — это когда скриптовыми биндингами только создаются объекты, обработчики, лэйаут, а рантайм — это фреймворк, написанный на чем-нибудь производительном (С++). В таком ключе производительность останется та же, ну может время инициализации или загрузки увеличится, но это будет сложно заметить.
Да я знаю, что у Qt полно биндингов. Сам использовал питоновый PySide.
Может не для всех приложений это подходит, но есть, например, Autodesk Maya — трехмерный редактор, интерфейс у него на Qt. Гуи общается с ядром на их собственном скриптовом языке MEL. Собсно, само ядро можно просто из консоли использовать. Так же там был замечен PyQt — для кастомных плагинов с гуи. Скорее всего и некоторые встроенные окошечки на питоне сделаны.
Оптимальный вариант — это когда скриптовыми биндингами только создаются объекты, обработчики, лэйаут, а рантайм — это фреймворк, написанный на чем-нибудь производительном (С++). В таком ключе производительность останется та же, ну может время инициализации или загрузки увеличится, но это будет сложно заметить.
Да я знаю, что у Qt полно биндингов. Сам использовал питоновый PySide.
Может не для всех приложений это подходит, но есть, например, Autodesk Maya — трехмерный редактор, интерфейс у него на Qt. Гуи общается с ядром на их собственном скриптовом языке MEL. Собсно, само ядро можно просто из консоли использовать. Так же там был замечен PyQt — для кастомных плагинов с гуи. Скорее всего и некоторые встроенные окошечки на питоне сделаны.
Не знаю как вам, но я лично не понимаю при чем тут язык. Я довольно неплохо владею тем же C#, хорошо знаю платформу .NET… И хорошо знаю проблемы с «умным» сборщиком мусора, который очищает память, когда ему удобнее, а не тогда когда удобно вам. А теперь представим себе задачи по обработке изображения, например с ограничением по памяти, и конечно не забываем про скорость отклика. Вспомним про стандартные тормознутые контролы .NET, такие как DataGridView. Конечно есть альтернатива как контролы DevExpress, которые нормально обработают 10 тысяч строк и не захлебнуться. Конечно можно подумать, что дело в неправильном проектировании самого приложения и не нужно отображать столько строк за раз — но, задумайтесь, не ограничения ли это самой среды? Вам остается либо смириться с этим и что лучше так просто не делать, либо попытаться написать свой контрол… И сложность последнего уже не в языке, хоть вы его будете писать на C#, хоть на C++.
А теперь я скажу чем мне именно нравиться Qt — его гибкостью. На Qt писать GUI так же быстро (если хорошо его знать), как и на C# .NET. Да и WPF — со своими приколами, единственное это порог вхождения.
Напомню что язык должен выбираться от типа и сложности задачи, и не всегда от личных предпочтений. Вспомним что Qt — это не только GUI, и что есть, например, портирование на Python — PyQt.
Так же в защиту всемогущего языка C++, самого гибкого языка. И когда вам будет нужна такая гибкость, окажется что и выбора то и нет. И в приложении, где в центре не GUI и готовые решения, а уникальный алгоритм или производительность — то Qt для пользовательской красивой мордашки вам в помощь.
Я не в коем случае не навязываю, я просто расширяю угол обзора. А такие вещи как C++/CLI или новомодный C++/CX, со своими тонкостями и проблемами — это близко, но не то.
Такого моего субъективное мнение — Qt среди остального C++ мира пожалуй самый «милый» :)
А теперь я скажу чем мне именно нравиться Qt — его гибкостью. На Qt писать GUI так же быстро (если хорошо его знать), как и на C# .NET. Да и WPF — со своими приколами, единственное это порог вхождения.
Напомню что язык должен выбираться от типа и сложности задачи, и не всегда от личных предпочтений. Вспомним что Qt — это не только GUI, и что есть, например, портирование на Python — PyQt.
Так же в защиту всемогущего языка C++, самого гибкого языка. И когда вам будет нужна такая гибкость, окажется что и выбора то и нет. И в приложении, где в центре не GUI и готовые решения, а уникальный алгоритм или производительность — то Qt для пользовательской красивой мордашки вам в помощь.
Я не в коем случае не навязываю, я просто расширяю угол обзора. А такие вещи как C++/CLI или новомодный C++/CX, со своими тонкостями и проблемами — это близко, но не то.
Такого моего субъективное мнение — Qt среди остального C++ мира пожалуй самый «милый» :)
Конечно можно подумать, что дело в неправильном проектировании самого приложения и не нужно отображать столько строк за раз — но, задумайтесь, не ограничения ли это самой среды?
Вам 10 000 строк, вообще говоря, для чего? Если вы пишете стандартный бэкенд стандартного корпоративного приложения в стиле «х**к, х**к и в продакшн», то да, гриды на 10 000 строк (и 100 столбцов) рулят. Но вот «х**к, х**к и в продакшн» как раз в дотнете удобнее, потому что меньше головной боли. И остаётся время, чтобы сделать чуть более человеческий интерфейс. :)
И в приложении, где в центре не GUI и готовые решения, а уникальный алгоритм или производительность — то Qt для пользовательской красивой мордашки вам в помощь.
Если гуй сбоку, то выбор WPF или Qt вообще не стоит, потому что в большинстве случаев удобнее не смешивать разные технологии.
А такие вещи как C++/CLI или новомодный C++/CX, со своими тонкостями и проблемами — это близко, но не то.
C++/CLI — не язык, а костыль. На нём не программируют, на нём лепят костыли. :)
C++/CLI — не язык, а костыль. На нём не программируют, на нём лепят костыли. :)
C++/CLI — я и не называл языком. И честно говоря совершенно не понимаю зачем нужна подобная «вещь».
Написал на нем одну обертку и понял что обычный P/Invoke проще и удобнее.
Вам 10 000 строк, вообще говоря, для чего?
Это был просто пример, может быть не совсем удачный. Я просто вспомнил случай в жизни когда данных стало резко больше и стандартные контролы стали нещадно тупить. А мысль была что не стандартные вещи делаются тяжело на любом языке.
Если гуй сбоку, то выбор WPF или Qt вообще не стоит, потому что в большинстве случаев удобнее не смешивать разные технологии.
Согласен.
C++/CLI для случаев сложного костылестроения интеропа: когда классы, а не голые сишные функции, когда нужно вызывать сотни разных функций при простом внешнем интерфейсе, когда весь код в шаблонах и т.п. P/Invoke на плюсовых классах и шаблонах не очень работает, оборачивать сотни функций муторно и т.п. Но в большинстве случаев его хватает, да.
Но ведь в случае с наследованием — можно обозначить класс
Я не спорю, что есть свои ограничения и в таком случае. И в итоге безопасный и главное стабильный P/Invoke совсем не удобен. Написание связующего кода конечно муторно, но не так уж долго.
Но честно говоря проблем с наследованием у меня действительно нет, единственное не удобно конкретизировать класс в шарпной среде.
А так я честно стремился писать костыли на предназначенном для этого CLI, но как то не срослось :) Информации о нем мне показалось мало, и далеко не все получилось… Если посоветуете про CLI книгу или полезную статью буду очень признателен)
В итоге я сейчас просто экспортирую структуру с статическими методами, которые ничего не возвращают и отдают только через указатели. Зато теперь при изменении параметров — меняется и наименование точки входа; в отличии от простых сишных функций.
То есть есть класс ILayer с потомком VectorLayer, то я пишу соответствующее структуры ILayerExport, VectorLayerExport — запечатанные в cpp'шках. Вроде действительно этого хватает.
А так, например GDAL использует SWIG.
__declspec(dllexport) атрибутом, а затем отнаследоваться от него. Я не спорю, что есть свои ограничения и в таком случае. И в итоге безопасный и главное стабильный P/Invoke совсем не удобен. Написание связующего кода конечно муторно, но не так уж долго.
Но честно говоря проблем с наследованием у меня действительно нет, единственное не удобно конкретизировать класс в шарпной среде.
А так я честно стремился писать костыли на предназначенном для этого CLI, но как то не срослось :) Информации о нем мне показалось мало, и далеко не все получилось… Если посоветуете про CLI книгу или полезную статью буду очень признателен)
В итоге я сейчас просто экспортирую структуру с статическими методами, которые ничего не возвращают и отдают только через указатели. Зато теперь при изменении параметров — меняется и наименование точки входа; в отличии от простых сишных функций.
То есть есть класс ILayer с потомком VectorLayer, то я пишу соответствующее структуры ILayerExport, VectorLayerExport — запечатанные в cpp'шках. Вроде действительно этого хватает.
А так, например GDAL использует SWIG.
Странный пост, если честно. По стилю больше для личного бложика «мимими какой классный котик».
Вы хотели сравнить C++ с другими языками или Qt с другими каркасами? Тогда возможно уместен стиль как в этом посте? В этом случае нужен соответствующий опыт промышленной разработки с применением всех сравниваемых технологий. Я например сомневаюсь, что можно писать одновременно на C++, Java, Obj-C и т.д., пользуясь всем стеком технологий.
Возможно вы хотели поделиться своим опытом использования Qt в реальных проектах, рассказать о найденных преимуществах и недостатках по сравнению с другими технологиями? Этого я тоже не увидел. Примеры оторванные от контекста ничего не стоят, как и HelloWorld'ы. Безусловно в Qt удобный строковый класс и контейнеры… по сравнению с STL. Но как это относится к статье?
Сам использую Qt и нахожу эту библиотеку удобной, но этот пост оставил какое-то негативное впечатление.
Вы хотели сравнить C++ с другими языками или Qt с другими каркасами? Тогда возможно уместен стиль как в этом посте? В этом случае нужен соответствующий опыт промышленной разработки с применением всех сравниваемых технологий. Я например сомневаюсь, что можно писать одновременно на C++, Java, Obj-C и т.д., пользуясь всем стеком технологий.
Возможно вы хотели поделиться своим опытом использования Qt в реальных проектах, рассказать о найденных преимуществах и недостатках по сравнению с другими технологиями? Этого я тоже не увидел. Примеры оторванные от контекста ничего не стоят, как и HelloWorld'ы. Безусловно в Qt удобный строковый класс и контейнеры… по сравнению с STL. Но как это относится к статье?
Сам использую Qt и нахожу эту библиотеку удобной, но этот пост оставил какое-то негативное впечатление.
Ну что поделать, если Qt действительно мимими и неплохой котик? :)
Какой самый крутой проект вы на нем сделали?
Я еще слишком молод, чтобы делать серьезные проекты, поверьте. Тем не менее, у меня есть немало наработок, компонентов. А для real case application сойдет 2ГИС.
Не, я сам 3 года проект на нем делал с командой. Коммерческий. Кучу денег потратили, но таки закончили. Я многое про Qt могу рассказать ;)
Интересно было о вашем личном опыте услышать, а не всем известные тезисы.
Интересно было о вашем личном опыте услышать, а не всем известные тезисы.
Мой опыт в том, что очень много вещей делаются быстро, но бывают реальные места — пробки, в которых обходные пути (нет, не костыли) весьме нетривиальны и занимают много времени. В целом, я получаю от Qt только удовольствие, но в реальных задачах таких пробок может быть достаточно много.
Digia считает, что они могут устранить эти пробки!
Digia считает, что они могут устранить эти пробки!
А я хочу, чтобы проект QtJambi ожил! Ибо Qt как просто графический фронт-энд ИМХО уделывает все SWT, Swingи и JavaFXы. Защищу диплом — попробую помочь проекту.
QML как графический фронтенд уделывает Qt, который уделывал «все SWT, Swingи и JavaFX». Так что раз уж и оживлять стюардессу, то только как делают go-qml для Go, только для Java.
Don't drink too much kool-aid
1. Контейнеры в Qt очень ограничены. Просто попробуйте добавить в QHash произвольный класс в качестве ключа. COW ведет себя иногда (чаще всего, когда дело касается многопоточности) совсем не так, как хотелось бы.
2. MVC не так уж и хорош. Система мощная, но иерархическое представление данных прилеплено к ней с боку.
3. Уже сделали QML компоненты с родным стилем для десктопа? Давно не смотрел, но раньше их не было в стандартном наборе. Или по прежнему только квадратики рисовать можно?
4. Сообщество: stackoverflow: Qt — 30,788, wpf — 83,528, swing — 41,126, winforms — 48,610. По личным ощущениям оттуда, помощь в Qt вопросах могут оказать совсем немного человек.
5. QtCreator — неплохая IDE, но совсем не Idea или Visual studio. Для С++, правда, вообще с IDE все плохо, но и Creator не слишком хорош. В сложных случаях не работает автодополнение, например. Да и текстовый редактор там не очень (нескольких курсоров так и нет) Ребята не смогли сделать рефакторинг сигналов/слотов, что раздражает.
1. Контейнеры в Qt очень ограничены. Просто попробуйте добавить в QHash произвольный класс в качестве ключа. COW ведет себя иногда (чаще всего, когда дело касается многопоточности) совсем не так, как хотелось бы.
2. MVC не так уж и хорош. Система мощная, но иерархическое представление данных прилеплено к ней с боку.
3. Уже сделали QML компоненты с родным стилем для десктопа? Давно не смотрел, но раньше их не было в стандартном наборе. Или по прежнему только квадратики рисовать можно?
4. Сообщество: stackoverflow: Qt — 30,788, wpf — 83,528, swing — 41,126, winforms — 48,610. По личным ощущениям оттуда, помощь в Qt вопросах могут оказать совсем немного человек.
5. QtCreator — неплохая IDE, но совсем не Idea или Visual studio. Для С++, правда, вообще с IDE все плохо, но и Creator не слишком хорош. В сложных случаях не работает автодополнение, например. Да и текстовый редактор там не очень (нескольких курсоров так и нет) Ребята не смогли сделать рефакторинг сигналов/слотов, что раздражает.
1. Насколько я знаю, чтобы добавить произвольный классо-ключ, нужно зарегестрировать этот класс как Meta type и переопределить пачку опереторов. Если это сделать корректно — все работает, как часы.
2. Действительно. Тем не менее, это MVC приятно привязано к GUI, что не может не радовать.
3. Да, есть QML Desktop Components, они активно разрабатываются и уже на достойном уровне.
4. Дак у Qt есть свои Qt Project Forums — там всегда отвечают. На стэке я очень редко по кьюту что-то спрашиваю — чуть менее чем никогда.
5. Нету кроссплатформенной IDE для плюсов лучше, чем Qt Creator — это факт. Автодополнение в последних версиях криейтора работает даже в сложных template-случаях (они усовершенствовали парсер). Но зачем рефакторить сигналы/слоты, если есть QSignalSpy?
2. Действительно. Тем не менее, это MVC приятно привязано к GUI, что не может не радовать.
3. Да, есть QML Desktop Components, они активно разрабатываются и уже на достойном уровне.
4. Дак у Qt есть свои Qt Project Forums — там всегда отвечают. На стэке я очень редко по кьюту что-то спрашиваю — чуть менее чем никогда.
5. Нету кроссплатформенной IDE для плюсов лучше, чем Qt Creator — это факт. Автодополнение в последних версиях криейтора работает даже в сложных template-случаях (они усовершенствовали парсер). Но зачем рефакторить сигналы/слоты, если есть QSignalSpy?
Автодополнение в QtCreator в сложных случаях не всегда работает, например:
Если мы захотим получить список методов для «sharedPtrToSomeObject», то мы его не получим. У меня creator 3.1.0, qt 5.3.0 и open suse.
До выхода creator 3.1.0 были забавные недоразумения с выравниванием кода в относительно сложных случаях с шаблонными классами. Но надо отдать должное разработчикам, они пофиксили все что я зарепортил.
auto sharedPtrToSomeObject = make(/*parameters*/);
Если мы захотим получить список методов для «sharedPtrToSomeObject», то мы его не получим. У меня creator 3.1.0, qt 5.3.0 и open suse.
До выхода creator 3.1.0 были забавные недоразумения с выравниванием кода в относительно сложных случаях с шаблонными классами. Но надо отдать должное разработчикам, они пофиксили все что я зарепортил.
Для корректной работы автодополнения необходимо включить clang в модулях, а затем в параметрах -> c++ -> модель кода
И все работает (если я правильно понял ваш пример):
И все работает (если я правильно понял ваш пример):
Спасибо за наводку, не знал, что можно адекватно переключиться на clang. Надо сказать, что работает очень медленно — ждать приходится больше секунды, но это всё равно лучше чем ничего. Особенно порадовала правильная обработка точки и -> у итераторов и смарт-поинтеров, объявленных с auto. Это чуть ли не единственный случай, когда я использую auto, и очень бесило, что подсказчик не работал.
Насчет 5ого пункта соглашусь, но под мак он регулярно падает. Особенно когда работаешь с дизайнером из него, прокрутка работает через раз, падает каждый второй от лишнего движения.
проверил, действительно, видимо компилятор поправили и теперь с QHash стало попроще. На старых name lookup что ли не работал, функция qHash не подхватывалась. Тем не менее, в целом, до стандартных контейнеров еще есть куда расти.
У msdn тоже есть свои форумы. Но проанализировать все форумы в мире несколько сложно, поэтому можно взять один, на котором большое количество тем обсуждается. И вот результат.
На счет последнего, могу сказать что можно остановиться на «Нету кроссплатформенной IDE для плюсов». Когда в IDE что-то не работает — это раздражает. Лучше уж я vim буду использовать тогда. Он хотя бы работает в рамках того, что от него ждешь.
Рефакторить сигналы/слоты приходится, как и любой код. И есть ведь функция переименования сигналов/слотов в IDE, вот только она может в половине мест использования название не изменить. И ведь ошибки компиляции не будет. А потом думай, что это сигнал не срабатывает.
У msdn тоже есть свои форумы. Но проанализировать все форумы в мире несколько сложно, поэтому можно взять один, на котором большое количество тем обсуждается. И вот результат.
На счет последнего, могу сказать что можно остановиться на «Нету кроссплатформенной IDE для плюсов». Когда в IDE что-то не работает — это раздражает. Лучше уж я vim буду использовать тогда. Он хотя бы работает в рамках того, что от него ждешь.
Рефакторить сигналы/слоты приходится, как и любой код. И есть ведь функция переименования сигналов/слотов в IDE, вот только она может в половине мест использования название не изменить. И ведь ошибки компиляции не будет. А потом думай, что это сигнал не срабатывает.
Да и текстовый редактор там не очень (нескольких курсоров так и нет)В последней версии Qt Creator 3.2.0 уже добавили:
Блочное выделение поддерживает редактирование колонок, то есть теперь можно изменять текст одновременно в нескольких местах.
Я один не понимаю, для чего полезны эти multiple cursors? Они только для web нужны? Ни разу не смог придумать ситуации, когда они бы мне понадобились. Да, бывает когда нужно вставить/удалить в несколько строк подряд что-то одно, но мне для этого вполне хватает блочного выделения vim.
Для рефакторинга, для быстрого редактирования копипасты, да мало ли: www.youtube.com/watch?v=WXuBgSpLpK4
Обычно требуется не изменить несколько строк подряд, а изменить несколько строк по паттерну. При работе с кодом это такой нечеткий рефакторинг, когда меняется, например, оформление, или у функции добаился новый параметр и нужно поправить все места вызова — обычным рефакторингом (Creator-a) такое не сделать.
Но чаще я такую фишку использую все-таки при работе с текстом. Анализ логов, генерация файлов из файлов другого формата.
Но чаще я такую фишку использую все-таки при работе с текстом. Анализ логов, генерация файлов из файлов другого формата.
Все кто рассказывает про QtQuick/QML, всегда приводят пример в виде пары примитивов и простого обработчика onClick. Это очень похоже на рассказ про крутость/красоту C++ на примере пустого main() с std::cout << «hello world».
Вот самым большим плюсом Qt я всегда (еще со времен Qt2) считал кроссплатформенность. Написали раз код, пересобираем на всех платформах и получаем близкий к родному look&feel.
Очень хотелось бы посмотреть, как такого добиться в Qt5 и QtQuick. И тут все действительно грустно. Начинается все с того что сам по себе QtQuick — это по сути очень low-level штука в плане UI. Ну то есть ей можно нарисовать свой абсолютно уникальный UI, но сделать более-менее простое приложение, которое не выглядит притянутым за уши практически невозможно. Вот что сейчас поддерживается из платформ?
1. desktop. В 5.1 таки появились desktop components. Большое спасибо. Попробовать я их не успел.
2. Android/iOS. Родных компонент для какого-нибудь банального диалога с парой кнопок попросту нет. Я лично занимался ерундой по сборке компонент с Meego. Сейчас таки можно использовать Qt Quick Controls. Но выгдядят они совсем не системно.
3. Blackberry 10. Вообще ничего нет (может таки можно взять те же Qt Quick Controls из 5.2, не проверял). Зато есть родной тулкит «cascades» от RIM, использующий вместо QtQuick на порядок более high-level надстройку над QML из Qt 4. C нормальными нативными контролами, но без примитивов вроде линий/прямоугольников.
Вот я бы очень хотел увидеть пример чего-нибудь простого в плане функционала и нормально выглядящего везде приложения. Например какой-нибудь простой аналог Notes: табличка с датой и строчкой текста заметки и кнопками добавить/удалить.
Вот самым большим плюсом Qt я всегда (еще со времен Qt2) считал кроссплатформенность. Написали раз код, пересобираем на всех платформах и получаем близкий к родному look&feel.
Очень хотелось бы посмотреть, как такого добиться в Qt5 и QtQuick. И тут все действительно грустно. Начинается все с того что сам по себе QtQuick — это по сути очень low-level штука в плане UI. Ну то есть ей можно нарисовать свой абсолютно уникальный UI, но сделать более-менее простое приложение, которое не выглядит притянутым за уши практически невозможно. Вот что сейчас поддерживается из платформ?
1. desktop. В 5.1 таки появились desktop components. Большое спасибо. Попробовать я их не успел.
2. Android/iOS. Родных компонент для какого-нибудь банального диалога с парой кнопок попросту нет. Я лично занимался ерундой по сборке компонент с Meego. Сейчас таки можно использовать Qt Quick Controls. Но выгдядят они совсем не системно.
3. Blackberry 10. Вообще ничего нет (может таки можно взять те же Qt Quick Controls из 5.2, не проверял). Зато есть родной тулкит «cascades» от RIM, использующий вместо QtQuick на порядок более high-level надстройку над QML из Qt 4. C нормальными нативными контролами, но без примитивов вроде линий/прямоугольников.
Вот я бы очень хотел увидеть пример чего-нибудь простого в плане функционала и нормально выглядящего везде приложения. Например какой-нибудь простой аналог Notes: табличка с датой и строчкой текста заметки и кнопками добавить/удалить.
play.google.com/store/apps/details?id=com.digia.Qt5Everywhere
play.google.com/store/apps/details?id=org.qtproject.quickforecast
^ на Qt Developer Days '13 я видел первое приложение на всех платформах, в том числе и на iPad.
play.google.com/store/apps/details?id=org.qtproject.quickforecast
^ на Qt Developer Days '13 я видел первое приложение на всех платформах, в том числе и на iPad.
У меня нет сейчас возможности установить их. Гляну после праздников, спасибо.
Если смотреть на скриншоты: там кастомный UI, одинаковый для всех платформ (но не сильно заметно, т.к. большинство скринов больше под жанр 'игрушки' подходят).
А теперь если сравнить с Qt4 под desktop (или Qt5 с виджетами):
— на linux использует KDE-ную тему (я в курсе про то что нужно за это спасибо KDE-никам говорить). Плюс есть пара стандартных стилей
— на windows использует родную тему
— на mac os x пытается использовать родную тему. Плюс использует системный menu bar.
— где можно, используются родные файловые диалоги и т.д.
Т.е. пишется 1 раз, собирается и приложение хотя бы пытается выглядеть как родное. Сейчас цель 'пишется один раз' можно сказать что достигнута, но выглядит при этом оно везде одинаково.
PS. Я не пытаюсь высказать мнение что это плохо. Видимо я просто ожидаю от кроссплатформенности Qt немного другое. Для написания игрушек или чего-то в 'корпоративном sexy UI' стиле оно таки подходит. Но вот написать какую-нибудь утилитку вроде тех же заметок, которые будут выглядеть «нативно» с таким подходом не выйдет.
Если смотреть на скриншоты: там кастомный UI, одинаковый для всех платформ (но не сильно заметно, т.к. большинство скринов больше под жанр 'игрушки' подходят).
А теперь если сравнить с Qt4 под desktop (или Qt5 с виджетами):
— на linux использует KDE-ную тему (я в курсе про то что нужно за это спасибо KDE-никам говорить). Плюс есть пара стандартных стилей
— на windows использует родную тему
— на mac os x пытается использовать родную тему. Плюс использует системный menu bar.
— где можно, используются родные файловые диалоги и т.д.
Т.е. пишется 1 раз, собирается и приложение хотя бы пытается выглядеть как родное. Сейчас цель 'пишется один раз' можно сказать что достигнута, но выглядит при этом оно везде одинаково.
PS. Я не пытаюсь высказать мнение что это плохо. Видимо я просто ожидаю от кроссплатформенности Qt немного другое. Для написания игрушек или чего-то в 'корпоративном sexy UI' стиле оно таки подходит. Но вот написать какую-нибудь утилитку вроде тех же заметок, которые будут выглядеть «нативно» с таким подходом не выйдет.
По поводу Qt на Android — есть, например, ДубльГИС — производительность, по ощущениям, уступает нативным приложениям. Также есть предчувствие, что для написания приложения в соответствии со всеми гайдлайнами придется потанцевать. Едва ли кто-то реализовал тот же ActionBar со всеми нюансами его поведения.
НЛО прилетело и опубликовало эту надпись здесь
Также есть предчувствие, что для написания приложения в соответствии со всеми гайдлайнами придется потанцевать.
Вы совершенно правы, потанцевать придётся. Digia делает прекрасную работу, это бесспорно, но фундаментальная идея, заложенная в Qt, мол, один раз код написал и потом разворачивай на всех поддерживаемых платформах — это, к сожалению, пока иллюзия. Например, если говорить о Mac OS X, то нативные Cocoa-приложения всегда опережают Qt-приложения, как по внешнему виду, так и по производительности. Изменится ли это в будущем — не знаю. Но на сегодняшний день дела обстоят именно так.
Мой любимый вопрос, можно конкретики по внешнему виду? Да, действительно, напильник иногда нужен, но не так чтобы критично.
… можно конкретики по внешнему виду?
Можно. Qt-приложения на Mac не выглядят как родные. Он похожи на родные, но разница всегда видна. И не мне одному, поверьте.
Конкретика — это конкретные контролы, которые работают не так, ведут себя не так, выглядят не так. Раз уж разница всегда видна, вам не составит труда ее показать.
Вот например приложение ласт.фм
Думаю заметно, что надписи у чекбоксов сдвинуты вверх, так-же как и содержимое комбобокса, а различие между заголовками вкладок видно даже с метрового расстояния. Конечно это мелочи, но глаз цепляется за это и чувствует что ему подсовывают суррогат.
Скрытый текст
И для сравнения похожее окно нативного приложения 
Скрытый текст
Думаю заметно, что надписи у чекбоксов сдвинуты вверх, так-же как и содержимое комбобокса, а различие между заголовками вкладок видно даже с метрового расстояния. Конечно это мелочи, но глаз цепляется за это и чувствует что ему подсовывают суррогат.
Стандартный оконный интерфейс VLC вроде бы тоже на Qt написан. Или это что-то другое?
VLC под OS X не использует Qt для интерфейса, вот тут это видно в исходниках
Для интереса сделал схожий интерфейс, сдвигов не увидел. Вкладки действительно выглядят немного по-другому, для нативности придется задать их через стиль/картинку.
Скрытый текст
Никогда не писал на C++/Qt, но встречал уже достаточно много проектов на подобном стеке. В принципе пост лишь о том, как сильно Qt тронула автора. И, безусловно, он имеет право на существование (пост), я лишь не соглашусь с тем, что, как указал автор, эта статья — повод переехать с C#/Java/… Я люблю Java, люблю Intellij IDEA, Spring и пр. и с таким же успехом могу утверждать, что это повод забыть о C++, хотя бы даже из-за GC.
В C++ есть GC. Вот.
Знаете, я на собеседованиях спрашивал у всех разработчиков, уверяющих что они хорошо знают технологию Х, о недостатках этой технологии. И знаете, наверное 2 из десяти могли сказать что-то вразумительное об этом. А ведь специалист в технологии просто обязан знать её недостатки.
А вы расскажете нам, что же не так в Qt? ;)
А вы расскажете нам, что же не так в Qt? ;)
Он, он, он — совершенен. А если серьезно, то вы меня подловили — ничего структурированно и цельно я вам не сформулирую…
Давайте я попробую :)
1. Набившее оскомину «А что ж он зараза так много весит», кстати, недостаток с оговорками, как правило под продакшн можно минимизировать количество необходимых библиотек, ну а тем кто знаком с утилитой strip еще и уменьшить их размер.
2. Недостаток не для всех, но для определенной категории адептов исключений существенный — отсутствие этих самых исключений, т.е. фреймвор не пользуется ими, совсем.
3. Ворох всяких предкомпиляторов: lupdate, lrelease, uic, rcc, и конечно же moc. Обо всем этом надо знать, помнить и представлять как оно работает и взаимодействует между собой.
4. Более локальные проблемы — это переусложненный API компонентов на основе MV паттерна (я говорю еще о виджетах) при явной недостаточности вариантов простой реализации (т.е. очень сложно представить проект серьезнее домашнего наброска в котором можно обойтись QTableWidget и не городить свою модель и модификации QTableView (утрированно)). Касательно Qt5 на мой взгляд переусложненная процедура создания своих элементов на основе QQuickItem.
Можно наверное накопать еще, но это первое что пришло в голову.
1. Набившее оскомину «А что ж он зараза так много весит», кстати, недостаток с оговорками, как правило под продакшн можно минимизировать количество необходимых библиотек, ну а тем кто знаком с утилитой strip еще и уменьшить их размер.
2. Недостаток не для всех, но для определенной категории адептов исключений существенный — отсутствие этих самых исключений, т.е. фреймвор не пользуется ими, совсем.
3. Ворох всяких предкомпиляторов: lupdate, lrelease, uic, rcc, и конечно же moc. Обо всем этом надо знать, помнить и представлять как оно работает и взаимодействует между собой.
4. Более локальные проблемы — это переусложненный API компонентов на основе MV паттерна (я говорю еще о виджетах) при явной недостаточности вариантов простой реализации (т.е. очень сложно представить проект серьезнее домашнего наброска в котором можно обойтись QTableWidget и не городить свою модель и модификации QTableView (утрированно)). Касательно Qt5 на мой взгляд переусложненная процедура создания своих элементов на основе QQuickItem.
Можно наверное накопать еще, но это первое что пришло в голову.
Немного добавлю, как тезис для обсуждения.
Плюс QT — простота и стройность библиотеки, он же минус. Возможности библиотеки более скудные чем в том же .Net, например, нет много из того, что есть в WCF, и уж тем более нет плагино-стройки MEF. Но эти вещи, имхо, нужны для совсем уж энтерпрайз разработок.
Плюс QT — C++, и он же минус. Если основной акцент проекта на скорость алгоритмов которые написаны на C/C++, вроде приведенного примера 3D сканер + средне-масштабная CAD-система, или же что-то из image processing — QT в самый раз. В HPC, вообще все на C (еще можно на фортране) — MPI, OpenMP, CUDA/OpenCL. Поэтому GUI на C++ — весьма к месту.
Но безусловно, динамические языки и GC облегчают разработку GUI и бизнес логики. Поэтому, если акцент на бизнес-логике, транзакциях, сервис-ориентированности — C++ скорее минус и тогда Java/C#, а в каких-то ситуациях и 1С.
Плюс QT — простота и стройность библиотеки, он же минус. Возможности библиотеки более скудные чем в том же .Net, например, нет много из того, что есть в WCF, и уж тем более нет плагино-стройки MEF. Но эти вещи, имхо, нужны для совсем уж энтерпрайз разработок.
Плюс QT — C++, и он же минус. Если основной акцент проекта на скорость алгоритмов которые написаны на C/C++, вроде приведенного примера 3D сканер + средне-масштабная CAD-система, или же что-то из image processing — QT в самый раз. В HPC, вообще все на C (еще можно на фортране) — MPI, OpenMP, CUDA/OpenCL. Поэтому GUI на C++ — весьма к месту.
Но безусловно, динамические языки и GC облегчают разработку GUI и бизнес логики. Поэтому, если акцент на бизнес-логике, транзакциях, сервис-ориентированности — C++ скорее минус и тогда Java/C#, а в каких-то ситуациях и 1С.
Ответ из трёх букв: MOC
А мне вот QML совсем не понравился, при очень большой любви к Qt
Достаточно много намешано на мой взгляд в эту гущу, код на QML выглядит стремно. Сталкивался с ним для программирования под Sailfish OS — так уж мне понравилась идея выстроить ОС на Qt.
Достаточно много намешано на мой взгляд в эту гущу, код на QML выглядит стремно. Сталкивался с ним для программирования под Sailfish OS — так уж мне понравилась идея выстроить ОС на Qt.
реквестирую обещанное опровержение всех ложных высказываний о QT (как человек который рассматривает QT как потенциальную платформу для переезда)
Среди критичных высказываний о Qt есть много ложных, но есть и правдивые.
В своё время я нашёл пару объяснений (на Stackoverflow) насчёт того, почему Qt проигрывает Cocoa (речь была именно о Mac OS X). Так вот я не поверил этим объяснениями на слово, ведь Qt уже была моей основной платформой. И это моё недоверие стоило мне 8 месяцев работы, выброшенной в итоге в корзину. Почему? Потому что когда я сделал Cocoa-аналог моего приложения, а потом сравнил его с Qt-вариантом — я всё понял. Сразу. И мне уже не нужно было никаких доводов. Cocoa-версия значительно быстрее запускалась, ощутимо быстрее работала и выглядела лучше.
Так я убедился в том, что на сегодняшний день Cocoa-приложения на голову выше, чем Qt-приложения. Про Windows и Linux не говорю, это отдельный разговор.
В своё время я нашёл пару объяснений (на Stackoverflow) насчёт того, почему Qt проигрывает Cocoa (речь была именно о Mac OS X). Так вот я не поверил этим объяснениями на слово, ведь Qt уже была моей основной платформой. И это моё недоверие стоило мне 8 месяцев работы, выброшенной в итоге в корзину. Почему? Потому что когда я сделал Cocoa-аналог моего приложения, а потом сравнил его с Qt-вариантом — я всё понял. Сразу. И мне уже не нужно было никаких доводов. Cocoa-версия значительно быстрее запускалась, ощутимо быстрее работала и выглядела лучше.
Так я убедился в том, что на сегодняшний день Cocoa-приложения на голову выше, чем Qt-приложения. Про Windows и Linux не говорю, это отдельный разговор.
Если говорить о мне, то я работаю с Qt относительно мало — всего 5 лет. Qt проводит ежегодные мероприятия — Qt Developer Days и Qt Contributors' Summit. Я был на каждом из них по одному разу, в прошлом году
Судя по предыдущим постам ТС'а в прошлом году он учился в 8 классе...Qt Developer Days проходил в Сан Франциско, а Qt Contributors' Summit в Бильбао… Ниче так школьники пошли, посещающие девелоперские конференции по всему миру… да и опыт работы с Qt с 3 класса тоже немного удивляет О_о
Автор, похоже, просто троллит, во-первых, стиль, во-вторых извечная тема, что «это лучше этого».
Моё субъективное мнение (пишу на C++, полгода назад был в течение полугода на проекте на Qt5, пару лет назад немного трогал c#):
Отдельно пару слов про API: действительно хорош, вообще чувствуется закономерность во всех модулях, довольно удобно. В некоторых случаях бывают недочёты, но жить можно.
Далее по пунктам:
— Core — строки, файлы, асинхронность, метасистема.
— Qt MVVM — QAbstractItemModel
— GUI — QtQuick, Widget, стили, сюдя же локализацая
— Всякие дополнительные модули — работа с сетью, xml, json, базы данных.
— Документация
— Исходники
— Сообщество
— Открытый исходный код и обзоры.
Core: довольно много вспомогательных методов (core), которые в каждом C++ проекте приходится либо откуда-то тянуть, либо делать свои. Если сравнить с boost, то в целом и тут и там присутствует одинаковый функционал. C++11 скорее дополняет, что boost, что Qt.
C#/.NET в этом плане не то что не уступает, а во многом получше.
6+ баллов (по 5 бальной шкале).
Qt MVVM — QAbstractItemModel: после приобретения небольшого опыта кажется очень удобной. Стандартные реализации кроме абстрактной прокси надо забыть, так как они, как уже упоминалось в комментариях только для совсем простых, может даже только демонстрационных, приложений. Все получается и хорошо вписывается в стиль Qt. У нас была и асинхронная загрузка как самих элементов, и их частей, DRY на хорошем уровне, просто выстраивали цепочки из проксей, при этом ничего не тормозило.
К сожалению мало опыта с c#, подскажите, есть ли там нечто подобное, особенно в WPF?
5 баллов.
GUI: QtQuick — может быть это конечно удобно для андроида, но для десктопа очень много негативных впечатлений. Была небольшая путаница в версиях, выяснять зависимость — большой геморрой (уж простите, не припоминается слово лучше), размер, работа на разных системах (это в общем-то к зависимостям). Не так уж и много стандартных контролов, зато можно заанимировать с десятком всяких эффектов что угодно, но мне как пользователю нужна функциональность на привычных элементах, а не анимация, а как программисту не хочется ковыряться в 1000 строчных чужих бажных компонентах, чтобы родить свой, который на мой взгляд должен быть из коробки. Не всегда легко, если вообще можно, поменять/перегрузить что-нибудь «унаследовавшись» от уже готовых компонентов. Читабельность кода весьма сомнительна. В общем все были очень счастливы, когда это дело полностью заменили QtWidget'ами.
Стили в целом неплохи, но всегда чувствовались небольшие проблемы. Я так понимаю, что сейчас модный QML это направления затмил и лучше не станет.
Локализация на наш взгляд показалась немного поломанной, в частности id-based, и усложняется сборка из-за дополнительных lupdate, lrelease, сгенерированные файлы постоянно маячат в гите.
WPF — тоже не идеал, все равно многое надо делать руками. Субъективно в сравнение с Qt значительно лучше.
3 балла. Положительная оценка только из-за виджетов и все таки оно работает.
Всякие дополнительные модули: потихоньку развиваются, есть пара мест где можно улучшить API. Иногда имеет смысл посмотреть что-нибудь стороннее. В любом случае иногда приходится чуть ли не полностью обернуть.
3 балла.
Документация в сравнении с boost получше, в сравнении с C# думаю, что немного похуже.
4 балла.
Исходники: очень хорошо читаемые, boost и товарищи тоже читаемые, но тут субъективно все значительно проще. Про C# ничего не могу сказать.
4 балла.
Сообщество: что-то находилось в интернете, было удобно вначале, потом исходники и отладка внутренностей стали помогать значительно больше и быстрее.
На баг-репорты отвечают быстро, иногда ведётся небольшая дискуссия, присваивают приоритет, но не фиксят. Двоякие чувства, с одной стороны чувствуется активность, но с другой стороны результат не очень быстро появляется.
Сложно оценить.
Некоторые полезные фичи (причем, работающие) висят уже два года, но их никак не включат. Я лично ничего не посылал, но мне показалось, что ревьюверы не всегда хорошо видят картину. Мне, например, никак не понятно, почему лучше иметь только один статический глобальный объект, чем иметь дополнительную возможность его заинджектить.
Динамика развития проекта:
Проект развивается, периодически выходят релизы, иногда с задержками, но впечатления положительные, посмотрим.
Разработка под андроид выглядит очень вкусной. Тут я в качестве диванного теоретика хочу сказать, что на мой взгляд пока ещё сыровата как в реализации, так и в концепции, как это должно быть.
Итог, для модели можно обойтись и без Qt, графику может лучше сделать на чем-нибудь, что ближе к телу целевой платформы. Можно и на Qt, но никто точно не *должен* на него мигрировать.
Моё субъективное мнение (пишу на C++, полгода назад был в течение полугода на проекте на Qt5, пару лет назад немного трогал c#):
Отдельно пару слов про API: действительно хорош, вообще чувствуется закономерность во всех модулях, довольно удобно. В некоторых случаях бывают недочёты, но жить можно.
Далее по пунктам:
— Core — строки, файлы, асинхронность, метасистема.
— Qt MVVM — QAbstractItemModel
— GUI — QtQuick, Widget, стили, сюдя же локализацая
— Всякие дополнительные модули — работа с сетью, xml, json, базы данных.
— Документация
— Исходники
— Сообщество
— Открытый исходный код и обзоры.
Core: довольно много вспомогательных методов (core), которые в каждом C++ проекте приходится либо откуда-то тянуть, либо делать свои. Если сравнить с boost, то в целом и тут и там присутствует одинаковый функционал. C++11 скорее дополняет, что boost, что Qt.
C#/.NET в этом плане не то что не уступает, а во многом получше.
6+ баллов (по 5 бальной шкале).
Qt MVVM — QAbstractItemModel: после приобретения небольшого опыта кажется очень удобной. Стандартные реализации кроме абстрактной прокси надо забыть, так как они, как уже упоминалось в комментариях только для совсем простых, может даже только демонстрационных, приложений. Все получается и хорошо вписывается в стиль Qt. У нас была и асинхронная загрузка как самих элементов, и их частей, DRY на хорошем уровне, просто выстраивали цепочки из проксей, при этом ничего не тормозило.
К сожалению мало опыта с c#, подскажите, есть ли там нечто подобное, особенно в WPF?
5 баллов.
GUI: QtQuick — может быть это конечно удобно для андроида, но для десктопа очень много негативных впечатлений. Была небольшая путаница в версиях, выяснять зависимость — большой геморрой (уж простите, не припоминается слово лучше), размер, работа на разных системах (это в общем-то к зависимостям). Не так уж и много стандартных контролов, зато можно заанимировать с десятком всяких эффектов что угодно, но мне как пользователю нужна функциональность на привычных элементах, а не анимация, а как программисту не хочется ковыряться в 1000 строчных чужих бажных компонентах, чтобы родить свой, который на мой взгляд должен быть из коробки. Не всегда легко, если вообще можно, поменять/перегрузить что-нибудь «унаследовавшись» от уже готовых компонентов. Читабельность кода весьма сомнительна. В общем все были очень счастливы, когда это дело полностью заменили QtWidget'ами.
Стили в целом неплохи, но всегда чувствовались небольшие проблемы. Я так понимаю, что сейчас модный QML это направления затмил и лучше не станет.
Локализация на наш взгляд показалась немного поломанной, в частности id-based, и усложняется сборка из-за дополнительных lupdate, lrelease, сгенерированные файлы постоянно маячат в гите.
WPF — тоже не идеал, все равно многое надо делать руками. Субъективно в сравнение с Qt значительно лучше.
3 балла. Положительная оценка только из-за виджетов и все таки оно работает.
Всякие дополнительные модули: потихоньку развиваются, есть пара мест где можно улучшить API. Иногда имеет смысл посмотреть что-нибудь стороннее. В любом случае иногда приходится чуть ли не полностью обернуть.
3 балла.
Документация в сравнении с boost получше, в сравнении с C# думаю, что немного похуже.
4 балла.
Исходники: очень хорошо читаемые, boost и товарищи тоже читаемые, но тут субъективно все значительно проще. Про C# ничего не могу сказать.
4 балла.
Сообщество: что-то находилось в интернете, было удобно вначале, потом исходники и отладка внутренностей стали помогать значительно больше и быстрее.
На баг-репорты отвечают быстро, иногда ведётся небольшая дискуссия, присваивают приоритет, но не фиксят. Двоякие чувства, с одной стороны чувствуется активность, но с другой стороны результат не очень быстро появляется.
Сложно оценить.
Некоторые полезные фичи (причем, работающие) висят уже два года, но их никак не включат. Я лично ничего не посылал, но мне показалось, что ревьюверы не всегда хорошо видят картину. Мне, например, никак не понятно, почему лучше иметь только один статический глобальный объект, чем иметь дополнительную возможность его заинджектить.
Динамика развития проекта:
Проект развивается, периодически выходят релизы, иногда с задержками, но впечатления положительные, посмотрим.
Разработка под андроид выглядит очень вкусной. Тут я в качестве диванного теоретика хочу сказать, что на мой взгляд пока ещё сыровата как в реализации, так и в концепции, как это должно быть.
Итог, для модели можно обойтись и без Qt, графику может лучше сделать на чем-нибудь, что ближе к телу целевой платформы. Можно и на Qt, но никто точно не *должен* на него мигрировать.
Полностью разделяю фанатизм автора! Имел удовольствие много работать с Qt. Кросплатформенность и простота сборки кода через крос-компайл тулз — самый главный бонус этого, имхо. Кроме того, очень удобная IDE. Кажется, это самая яркая и удобная пачка либ для C++, которую придумывали когда-либо.
В январском видео конференции linux.conf.au мэйнтейнер Subsurface рассказывает о миграции с GTK на Qt. Упоминает Qt Creator, дружелюбное сообщество и различные тонкости перехода и использования фреймворка, плюсы и минусы в сравнении с GTK. Интересное видео:
Если кого интересует конференция, на том же канале можно найти всё снятое видео. Я хотел было сделать пост, но материала слишком много.
Если кого интересует конференция, на том же канале можно найти всё снятое видео. Я хотел было сделать пост, но материала слишком много.
НЛО прилетело и опубликовало эту надпись здесь
Skype :D VLC плеер еще. И вроде как VirtualBox и какие-то продукты Autodesk
НЛО прилетело и опубликовало эту надпись здесь
Avidemux. И вообще, en.wikipedia.org/wiki/Category:Software_that_uses_Qt
он не на qt
Ну да, core там в основном на сишке, но как минимум часть интерфейса использует Qt :) Вообще, более-менее крупные проекты редко держатся одного-единственного языка и фреймворка
iStodo под OS X.
Неудачный пример. Я не говорю, что этот интерфейс плох, вовсе нет, но от него буквально веет чужеродностью…
Веет чужеродностью… Хорошо, что скажете об этом продукте?
Любопытный интерфейс, но с родным OS X интерфейсом (требования к которому прописаны в Apple HIG) он не имеет ничего общего.
Это топовое приложение в Mac App Store, написано на Cocoa, причем держится в топе уже несколько лет. Вот другое, тоже родное, но уже из области образования, опять чужеродность?
Нет, вот второй пример — это родное приложение, это чувствуется с первого взгляда. А вот первое — чужеродное. Опять-таки, чужеродное с точки зрения Apple HIG (говорю так потому, что в своё время я подробно изучил его требования).
Единственные родные элементы — это верхняя панель и checkbox, возможно виджет времени, остальное — например combobox, выглядит где-то близко к стандарту, но однозначно кастомизировано. Вы обвиняете в таком подходе Qt (часто необоснованно), но тут с первого взгляда увидели родное приложение.
Вы совершенно правы! С первого взгляда я увидел родное приложение. Потому что это чувствуется.
Вот, например, взгляните: mac.github.com/. Некоторые элементы этого GUI отличаются от канонических Apple HIG-овских, но это родное приложение. Это ощущается с первых секунд. И сделать такое на Qt не получится.
Вот, например, взгляните: mac.github.com/. Некоторые элементы этого GUI отличаются от канонических Apple HIG-овских, но это родное приложение. Это ощущается с первых секунд. И сделать такое на Qt не получится.
Что конкретно не получится?
Не получится сделать интерфейс, который ощущался бы как родной Mac-овский. А если даже и получится, то только со множеством родных Cocoa-вставок в C++-код, а в этом случае идея кроссплатформенности уже теряется…
Дело в том, что большинство Mac-пользователей привыкли к этому ощущению нативности. Можно считать это хоть фанатизмом, хоть перфекционизмом — но это факт. И именно поэтому существует очень мало коммерческих Qt-приложений, которые были бы успешны в мире Mac.
Я пользуюсь OS X уже больше двух лет, и отлично вижу, когда приложения выглядят чужеродно. Для того, чтобы это увидеть, не нужно ничего сверхъестественного, различия лежат не в области неких ощущений, все лежит на поверхности. Можно выделить нетипичную компоновку виджетов, поведение, внешний вид, все это отлично видно на примере Java-приложений. С другой стороны, неиспользование стандартных элементов ничуть не отпугивает пользователей, просто зайдите в топ категории финансы, посмотрите на оформления, которые нравятся пользователям.
mixxx.org — что об этом скажете?)
Первая мысль была: «Боже, что это?...»
Не поленился, поставил себе это приложение. Сразу видно: сделано в Qt4, даже не в 5. Не соблюдены элементарные требования Apple HIG:
— Полноэкранный режим сделан неправильно.
— Окно «Сведения о Mixxx» максимизируется.
— Пункт «Выйти» в меню «Файл» и «Сведения о программе» в меню «Справка» — это вообще из мира Windows.
— Часть пунктов меню на русском, часть на английском, то же касается и интерактивных подсказок.
Вы скажете, мол, это мелочи. Да, это действительно мелочи. Но именно из таких мелочей складывается ощущение нативности/чужеродности.
— Полноэкранный режим сделан неправильно.
— Окно «Сведения о Mixxx» максимизируется.
— Пункт «Выйти» в меню «Файл» и «Сведения о программе» в меню «Справка» — это вообще из мира Windows.
— Часть пунктов меню на русском, часть на английском, то же касается и интерактивных подсказок.
Вы скажете, мол, это мелочи. Да, это действительно мелочи. Но именно из таких мелочей складывается ощущение нативности/чужеродности.
namespace, что-то я так и не понял, почему я должен пересесть со своей Java на Qt C++ ;)
Юношеский максимализм в статье и дальше просто прет из всех щелей.
Писал на qt много и гуя и бэкэнда (для упрощения архитектуры и уменьшения кода). Пришел к мысли, что основная проблема фреймворка — язык. Ребята, 2014 год на дворе, прикладуху на плюсах писать нужно в 1 случае из 100. Уж сколько холиваров по этому поводу было, а кресты все там же /_-
Писал на qt много и гуя и бэкэнда (для упрощения архитектуры и уменьшения кода). Пришел к мысли, что основная проблема фреймворка — язык. Ребята, 2014 год на дворе, прикладуху на плюсах писать нужно в 1 случае из 100. Уж сколько холиваров по этому поводу было, а кресты все там же /_-
Просто зашел сюда, чтобы написать «нет, не поехали!»
Незавершённый гугль транслейт с олбанского?
лол рулит пешиесчё ойтишнеги любйад четать интереснае но с лулзами и нячшечкаме.
Тема интересная, юмор приветствуется, но хорошо бы больше юмора и меньше лулзиков с няшечками, имхо. Мне кажется лучше шахматы и монашки, чем няшки.
лол рулит пешиесчё ойтишнеги любйад четать интереснае но с лулзами и нячшечкаме.
Тема интересная, юмор приветствуется, но хорошо бы больше юмора и меньше лулзиков с няшечками, имхо. Мне кажется лучше шахматы и монашки, чем няшки.
Окей, я пожалуй тоже поделюсь своими весьма субъективными впечатлениями о Qt.
Решил я значит написать простое приложение, поставил qt. Захожу в QtCreator, создаю пустой проект, нажимаю Build — и получаю гору ДИЧАЙШИХ ошибок компиляции.
Два дня я потратил на гуглинг и тему в сообществе qt. Безрезультатно. Проблема решилась сменой компилятора на miniGw (а был — от вижуал студии).
Соответственно, такой старт оставляет очень неприятный осадок. Почему в visual studio я создаю пустой проект и он просто сразу компилируется? Без танцев с бубном?
А еще, скомпилированный студией экзешник можно запустить и он запуститься. Скомпилированный в QtCreator'e — ругается на отсутствие Qt. Т.е. запускать его можно только через отладку в QtCreator. Я пока еще не разбирался, почему так, но это тоже оставляет неприятный осадок. Что с Qt обяхательно нужны танцы с бубном, даже для каких-то элементарных вещей совершенно.
Решил я значит написать простое приложение, поставил qt. Захожу в QtCreator, создаю пустой проект, нажимаю Build — и получаю гору ДИЧАЙШИХ ошибок компиляции.
Два дня я потратил на гуглинг и тему в сообществе qt. Безрезультатно. Проблема решилась сменой компилятора на miniGw (а был — от вижуал студии).
Соответственно, такой старт оставляет очень неприятный осадок. Почему в visual studio я создаю пустой проект и он просто сразу компилируется? Без танцев с бубном?
А еще, скомпилированный студией экзешник можно запустить и он запуститься. Скомпилированный в QtCreator'e — ругается на отсутствие Qt. Т.е. запускать его можно только через отладку в QtCreator. Я пока еще не разбирался, почему так, но это тоже оставляет неприятный осадок. Что с Qt обяхательно нужны танцы с бубном, даже для каких-то элементарных вещей совершенно.
Помню времена, когда в VS стандартные примеры тоже ошибки вызывали. И по сравнению с Delphi 7 это было просто невообразимо.
Мда. Послушаешь такие комментарии и задумаешься, стоило ли Qt создавать Qt Creator :-/.
Все-таки когда Qt надо было ставить как обычную библиотеку это требовало некоторой минимальной квалификации от её пользователя.
Все-таки когда Qt надо было ставить как обычную библиотеку это требовало некоторой минимальной квалификации от её пользователя.
Мне хочется верить, что минимальная квалификация у меня все-таки есть. Но согласитесь, гораздо приятнее иметь дело с чем-то работающим «из коробки».
Ох. Давайте пройдемся вначале по тезису «из коробки».
Во-первых, имеет смысл разделять два разных продукта: Qt Creator (IDE) и собственно Qt (библиотеки). Это две совершенно разных сущности. Хотя Creator и создавался теми же людьми и для облегчения разработки с Qt, но все же судить по нему о Qt-как-библиотеке, тем более в выражениях «Qt требует танцев с бубном» было изначально плохой идеей.
Во-вторых, «из коробки», насколько я помню, Qt Creator идет с MinGW. Собственно именно как обертка для GCC / GDB он и создавался, ИМХО. Кросс-платформенный же продукт. GCC-то есть везде, а MSVC — только под виндой, естественно что для Creator это не основной поддерживаемый вариант. А под MinGW, насколько я понимаю, Qt Creator у Вас прекрасно встал сразу.
В-третьих, Qt + MSVS обычно подразумевает что в качестве IDE используется MSVS, причем это долгое время был «платный» вариант, не знаю как сейчас. Qt Creator + MS compiler — это довольно необычное сочетание и с позиции разработчиков Creator-а было подвигом вообще сделать соответствующую поддержку. Сейчас правда в списке скачиваемых версий есть специальные сборки под VS 2010 / 2012, но я их не пробовал и не знаю как они работают. Вы хотя бы такую сборку использовали или что-то другое? Если что-то другое, то довольно странно было ожидать что там все заработает без настройки :).
Теперь пройдемся по поводу «квалификации».
Начнем с двух общих фактов:
1) Qt — это библиотека
2) Qt Creator — это IDE подключающаяся к стороннему компилятору / отладчику
Из первого факта вытекает что
1) библиотеки должны быть совместимы с runtime библиотеками используемыми в программе и линкером которым эта программа собирается. Т.е. если проект собирается в MSVS, использующим свой способ линковки и подлинковывающим микрософтовский рантайм (который еще и разный для разных версий Студии), то библиотеки Qt должны быть собраны в MS-совместимом формате и желательно — той же самой версией Студии. Это общая проблема для любых библиотек подключаемых к MS-компилируемому софту и скорее всего у Вас были проблемы именно с этим пунктом.
2) Вы можете использовать динамическую или статическую линковку. Статическая линковка подразумевает для MS-компилируемого софта опять же специальную версию библиотеки (ибо у MS статически-линкуемые и динамически-линкуемые библиотеки различаются). Qt по умолчанию идет в динамическом варианте, который подразумевает что код Qt не запихивается непосредственно в генерируемый .exe файл, а лежит себе отдельно в виде динамической библиотечки (DLL) подгружаемой в момент загрузки. Если .exe не может найти эту DLL-ку — то он, странное дело, сообщит об этом — причем довольно внятным сообщением. Догадываетесь к чему я клоню? Это опять же очень общий момент, с ним сталкивался любой, кто хотя бы какие-то сторонние библиотеки хоть раз подключал.
2.1.) У пункта 2 есть ньюанс: эти библиотеки, в принципе, можно прописать где-нибудь в системных путях, чтобы они находились виндой автоматически. и для Qt это без проблем тоже делается вручную за две минуты. Почему это не реализуется «из коробки»? А потому что это не очень хорошая практика, так как возникают проблемы с конфликтом разных версий этих библиотек aka DLL hell. MS из этой проблемы выкручивается тем что поставляет разные библиотеки для разных версий Студии, причем пара-тройка разных (!) версий этих библиотек включается в комплект поставки операционной системы (!). Однако как я уже писал в (1), такой подход приводит к тому что приходится собирать специальные версии всех сторонних библиотек (включая Qt) раздельно для любой версии студии (для 2010 — свои, для 2012 — свои...) а когда выходит 2013 студия то, сюрприз-сюрприз — сборок многих библиотек под эту студию просто не оказывается. Qt следует более юниксовым подходом и обеспечивает возможность работать с несколькими версиями Qt тем что просит явно указывать путь к библиотекам которые предполагается использовать — и в Creator это прекрасно обыграно, там это делается в два клика с автодетектированием. Я понимаю что когда на компьютере стоит лишь одна версия Qt то это выглядит «лишней работой», но эта работа невелика, а на мой взгляд, «Qt way» в отношении поддержки разных версий библиотек правильнее чем «MS way».
3) При этом если Вы бы занимались созданием инсталляторов, то Вы бы знали, что нужные MS библиотеки на компьютере тоже штатно бывают не всегда (особенно когда у пользователя из ОС стоит что-то старенькое типа Windows XP) — и то что «из коробки» (tm) работает на Вашей машине может ВНЕЗАПНО сообщить что ему не хватает какого-нибудь MSVCR110.dll на компьютере Вашего пользователя. Вам-то его инсталлятор студии поставил, а пользователю уже как повезет, включил эту библиотеку в ОС микрософт или нет. Qt в этом отношении где-то честнее, отладили на своей машине и приложили все нужные DLL-ки — работать будет везде. А с MS вечно думаешь, включать ли ms redistributable в инсталлятор или нет.
Из второго же факта вытекает что
4) Qt Creator-у нужно указать где и какими тулами пользоваться и сделать эти тулы для него доступными. Что подразумевает какую-никакую но все же настройку
Я вообще прошу прощения за слова про квалификацию, это было грубовато с моей стороны. Но Вам, право слово, не стоило писать тезисы типа
С учетом вышеизложенного — понимаете почему?
Во-первых, имеет смысл разделять два разных продукта: Qt Creator (IDE) и собственно Qt (библиотеки). Это две совершенно разных сущности. Хотя Creator и создавался теми же людьми и для облегчения разработки с Qt, но все же судить по нему о Qt-как-библиотеке, тем более в выражениях «Qt требует танцев с бубном» было изначально плохой идеей.
Во-вторых, «из коробки», насколько я помню, Qt Creator идет с MinGW. Собственно именно как обертка для GCC / GDB он и создавался, ИМХО. Кросс-платформенный же продукт. GCC-то есть везде, а MSVC — только под виндой, естественно что для Creator это не основной поддерживаемый вариант. А под MinGW, насколько я понимаю, Qt Creator у Вас прекрасно встал сразу.
В-третьих, Qt + MSVS обычно подразумевает что в качестве IDE используется MSVS, причем это долгое время был «платный» вариант, не знаю как сейчас. Qt Creator + MS compiler — это довольно необычное сочетание и с позиции разработчиков Creator-а было подвигом вообще сделать соответствующую поддержку. Сейчас правда в списке скачиваемых версий есть специальные сборки под VS 2010 / 2012, но я их не пробовал и не знаю как они работают. Вы хотя бы такую сборку использовали или что-то другое? Если что-то другое, то довольно странно было ожидать что там все заработает без настройки :).
Теперь пройдемся по поводу «квалификации».
Начнем с двух общих фактов:
1) Qt — это библиотека
2) Qt Creator — это IDE подключающаяся к стороннему компилятору / отладчику
Из первого факта вытекает что
1) библиотеки должны быть совместимы с runtime библиотеками используемыми в программе и линкером которым эта программа собирается. Т.е. если проект собирается в MSVS, использующим свой способ линковки и подлинковывающим микрософтовский рантайм (который еще и разный для разных версий Студии), то библиотеки Qt должны быть собраны в MS-совместимом формате и желательно — той же самой версией Студии. Это общая проблема для любых библиотек подключаемых к MS-компилируемому софту и скорее всего у Вас были проблемы именно с этим пунктом.
2) Вы можете использовать динамическую или статическую линковку. Статическая линковка подразумевает для MS-компилируемого софта опять же специальную версию библиотеки (ибо у MS статически-линкуемые и динамически-линкуемые библиотеки различаются). Qt по умолчанию идет в динамическом варианте, который подразумевает что код Qt не запихивается непосредственно в генерируемый .exe файл, а лежит себе отдельно в виде динамической библиотечки (DLL) подгружаемой в момент загрузки. Если .exe не может найти эту DLL-ку — то он, странное дело, сообщит об этом — причем довольно внятным сообщением. Догадываетесь к чему я клоню? Это опять же очень общий момент, с ним сталкивался любой, кто хотя бы какие-то сторонние библиотеки хоть раз подключал.
2.1.) У пункта 2 есть ньюанс: эти библиотеки, в принципе, можно прописать где-нибудь в системных путях, чтобы они находились виндой автоматически. и для Qt это без проблем тоже делается вручную за две минуты. Почему это не реализуется «из коробки»? А потому что это не очень хорошая практика, так как возникают проблемы с конфликтом разных версий этих библиотек aka DLL hell. MS из этой проблемы выкручивается тем что поставляет разные библиотеки для разных версий Студии, причем пара-тройка разных (!) версий этих библиотек включается в комплект поставки операционной системы (!). Однако как я уже писал в (1), такой подход приводит к тому что приходится собирать специальные версии всех сторонних библиотек (включая Qt) раздельно для любой версии студии (для 2010 — свои, для 2012 — свои...) а когда выходит 2013 студия то, сюрприз-сюрприз — сборок многих библиотек под эту студию просто не оказывается. Qt следует более юниксовым подходом и обеспечивает возможность работать с несколькими версиями Qt тем что просит явно указывать путь к библиотекам которые предполагается использовать — и в Creator это прекрасно обыграно, там это делается в два клика с автодетектированием. Я понимаю что когда на компьютере стоит лишь одна версия Qt то это выглядит «лишней работой», но эта работа невелика, а на мой взгляд, «Qt way» в отношении поддержки разных версий библиотек правильнее чем «MS way».
3) При этом если Вы бы занимались созданием инсталляторов, то Вы бы знали, что нужные MS библиотеки на компьютере тоже штатно бывают не всегда (особенно когда у пользователя из ОС стоит что-то старенькое типа Windows XP) — и то что «из коробки» (tm) работает на Вашей машине может ВНЕЗАПНО сообщить что ему не хватает какого-нибудь MSVCR110.dll на компьютере Вашего пользователя. Вам-то его инсталлятор студии поставил, а пользователю уже как повезет, включил эту библиотеку в ОС микрософт или нет. Qt в этом отношении где-то честнее, отладили на своей машине и приложили все нужные DLL-ки — работать будет везде. А с MS вечно думаешь, включать ли ms redistributable в инсталлятор или нет.
Из второго же факта вытекает что
4) Qt Creator-у нужно указать где и какими тулами пользоваться и сделать эти тулы для него доступными. Что подразумевает какую-никакую но все же настройку
Я вообще прошу прощения за слова про квалификацию, это было грубовато с моей стороны. Но Вам, право слово, не стоило писать тезисы типа
А еще, скомпилированный студией экзешник можно запустить и он запуститься. Скомпилированный в QtCreator'e — ругается на отсутствие Qt. Т.е. запускать его можно только через отладку в QtCreator. Я пока еще не разбирался, почему так, но это тоже оставляет неприятный осадок. Что с Qt обяхательно нужны танцы с бубном, даже для каких-то элементарных вещей совершенно.
С учетом вышеизложенного — понимаете почему?
Вынужден признать, моя квалификация действительно недостаточна.
Тем не менее, отвечу по пунктам:
0) Действительно, мои негативные впечатления связаны с QtCreator, а не с Qt, тут вы полностью правы.
1) Да, я пытался использовать сборку Qt для MSVS. Просто потому, что в прошлый раз у меня она заработала сразу.
2) Я сейчас не могу с уверенностью ответить (т.к. сижу за другим компом), но вроде бы все возможные пути к либам qt были мною прописаны в переменные окружения.
3) Никогда не занимался созданием инсталляторов и вообще представления о динамической линковке у меня не очень четкие. Постараюсь этот пробел заполнить.
4) Проблема была в том, что все возможные настройки (как мне казалось) были сделаны, но студийный компилятор ругался:
Моих знаний действительно недостаточно, чтобы понять, какого, так сказать, черта он ругался.
Да, я полный нуб в разработке под windows (о чем мне следовало бы написать в комментарии выше), но о том, что это субьективные впечатления — я предупредил.
Тем не менее, отвечу по пунктам:
0) Действительно, мои негативные впечатления связаны с QtCreator, а не с Qt, тут вы полностью правы.
1) Да, я пытался использовать сборку Qt для MSVS. Просто потому, что в прошлый раз у меня она заработала сразу.
2) Я сейчас не могу с уверенностью ответить (т.к. сижу за другим компом), но вроде бы все возможные пути к либам qt были мною прописаны в переменные окружения.
3) Никогда не занимался созданием инсталляторов и вообще представления о динамической линковке у меня не очень четкие. Постараюсь этот пробел заполнить.
4) Проблема была в том, что все возможные настройки (как мне казалось) были сделаны, но студийный компилятор ругался:
MSVCRTD.lib(crtexew.obj) : error LNK2019: unresolved external symbol __imp__EncodePointer@4 referenced in function _pre_c_initМоих знаний действительно недостаточно, чтобы понять, какого, так сказать, черта он ругался.
Да, я полный нуб в разработке под windows (о чем мне следовало бы написать в комментарии выше), но о том, что это субьективные впечатления — я предупредил.
2) Было бы прописано — наверняка бы работало :). Для проверки можете записать имя файла запрошенного приложением, поиском отыскать этот файл, кинуть к нему в папочку какой-нибудь экзешник (скажем переименовать notepad.exe в test.exe) и попробовать из папочки приложения этот экзешник по имени позвать.
2.1) Иногда бывает что после прописывания новых environment variables нужно перезапустить приложение, т.к. уже запущенное использует старые env
4) Похоже на баг связанный с апгрейдом студии со старой на новую (2008->2010), но если дело не в апгрейде или не лечится выбором правильной версии студии в Qt, то пофиксить подобное тяжело, согласен. Возможно здесь косяк Qt Creator, но иногда у самой Студии бывают такие глюки, однажды в компании с похожим сталкивались
2.1) Иногда бывает что после прописывания новых environment variables нужно перезапустить приложение, т.к. уже запущенное использует старые env
4) Похоже на баг связанный с апгрейдом студии со старой на новую (2008->2010), но если дело не в апгрейде или не лечится выбором правильной версии студии в Qt, то пофиксить подобное тяжело, согласен. Возможно здесь косяк Qt Creator, но иногда у самой Студии бывают такие глюки, однажды в компании с похожим сталкивались
Подправлю или дополню первый пункт. Чтоб dll скомпилированным одним компилятором были скушаны другим нужно, чтоб ABI у обоих был одинаков или явно задан.
Ситуация с C — если явно указано соглашение о вызове, то любой компилятор должен съесть. А вот C++ — тут все гораздо хуже и компиляторы должны иметь один и тот же ABI. Если вернуться к gcc, то Qt, скомпилированная версией 4.3 не подойдет для версии 4.7, в тоже время версия 4.7 спокойно заработает с версией 4.8.
.
Ситуация с C — если явно указано соглашение о вызове, то любой компилятор должен съесть. А вот C++ — тут все гораздо хуже и компиляторы должны иметь один и тот же ABI. Если вернуться к gcc, то Qt, скомпилированная версией 4.3 не подойдет для версии 4.7, в тоже время версия 4.7 спокойно заработает с версией 4.8.
.
А посоветуйте какую-нибудь современную книжку по qt, желательно на русском
А подскажите новичку-любителю в Qt, вот выпускаю я приложение, весит оно 500кб, но требует ~80Мб либ рядом с собой в папке. С линуксом все понятно, установил один раз Qt и работаешь, а вот для винды я такого не нашел. Статически собирать не особо хочу, ведь в случае апдейта пользователю нужно качать много больше 500кб.
Может быть существует какая-то сборка рантайма для винды, чтоб дать пользователю один раз его поставить, как это происходило с .NET и уже голова не болит и приложение запускается как положено?
Может быть существует какая-то сборка рантайма для винды, чтоб дать пользователю один раз его поставить, как это происходило с .NET и уже голова не болит и приложение запускается как положено?
А 80 мегабайт это конкретная цифра, или взятая с потолка? У нас, например, приложение со статической линковкой ужимается до ~6 мб. А по теме, я вижу два варианта: либо писать свой велосипед с автоапдейтом, который подтягивает только сам бинарник, либо собрать отдельный установщик либ — на том же Inno Setup, это делается буквально как далее-далее-готово.
Наврал, сейчас глянул 47Мб либы все занимают.
Вот думал вдруг велосипед не нужен и есть уже готовые рантайм паки подобные.
Подозреваю что при статической сборке там половина выкинется и результат будет еще меньше. Правда статическая сборка судя по всему тоже не двумя кликами делается, да еще и лицензию нарушает :))
Вот думал вдруг велосипед не нужен и есть уже готовые рантайм паки подобные.
Подозреваю что при статической сборке там половина выкинется и результат будет еще меньше. Правда статическая сборка судя по всему тоже не двумя кликами делается, да еще и лицензию нарушает :))
^ классненький Qt Creator, в котором можно творить чудеса и тебе за это ничего не будет.
Вот тут можно сильно поспорить. Если Вы говорите непосредственно о c++, то с Вами можно согласиться. Если же это один из аргументов в пользу c++ в сравнении с другими IDE для других языков программирования, то Qt Creator начисто проигрывает Intellij Idea и Visual Studio (+ReSharper).
Я правильно понимаю, или вы бросаетесь в опен-сорсную легковесную кросс-платформенную free software IDE для С++/Qt какашками со стороны проприетарной IDE, которую разработывает Microsoft икслючительно для Windows за немаленькие деньги?
namespace, а об Intellij Idea умолчал… :)
Она не исключительно для Windows, частично open source (community edition). По поводу легковесности — ну да, qt creator легче, но ивозможностей у него, грубо говоря, на порядок меньше. Вот выйдет ide для плюсов от jetbrains, вот тогда суровые плюсники заживут…
Она не исключительно для Windows, частично open source (community edition). По поводу легковесности — ну да, qt creator легче, но ивозможностей у него, грубо говоря, на порядок меньше. Вот выйдет ide для плюсов от jetbrains, вот тогда суровые плюсники заживут…
Зря Вы так. Не все библиотеки Microsoft c закрытым исходным кодом. Что касается самой операционной системы — да, а в исходниках .NET вы можете вполне покопаться. А если говорить о кроссплатформенности, то благодаря ребятам из Xamarin, это вполне возможно на любой популярной платформе.
По каким критериям проигрывает то? Кому-то и emacs/vim покажется удобней VS…
Потроллю вас немножко: попробуй напилить на Qt окно так, чтобы оно при ресайзе сохраняло соотношение сторон. Да так, чтобы без извращений с таймаутами и прочими хаками.
Понты вопрос же. Переоределяешь QWidget::resizeEvent(QResizeEvent*) и калибруешь расширяемость.
Увы, данное решение не работает.
Почему, работает. В ссылке на девнет, которую вы мне скинули, предлагалось использовать QWidget::heightForWidth(..) const, к тому же для виджета высшего уровеня.
Я же предлагаю перехватывать QResizeEvent и обойти это.
Я же предлагаю перехватывать QResizeEvent и обойти это.
Сразу в вопросе автор утверждает, что у него был stackoverflow.
Очевидно, что он просто что-то делал неправильно. У меня со всеми ивентами перехват получается делать всегда.
Я не поленился и попробовал на PyQt5 (Qt 5.2.0) под OSX 10.9.2
Не работает.
class Window(QWidget, object):
def resizeEvent(self, e):
e = QResizeEvent(QSize(e.size().width(), e.size().width() / 16 * 9), e.oldSize())
return super(Window, self).resizeEvent(e)
Не работает.
Как вариант что-то вроде
Есть только 1 минус-во избежании бесконечной рекурсии так делать не рекомендуется (написано в хелпе). Скорей всего есть более адекватный вариант, но этот у меня работает(без бесконечных рекурсий). =)
void MainWindow::resizeEvent(QResizeEvent *a){
setGeometry(geometry().x(),geometry().y(),a->size().width(),a->size().width()/16*9);
}
Есть только 1 минус-во избежании бесконечной рекурсии так делать не рекомендуется (написано в хелпе). Скорей всего есть более адекватный вариант, но этот у меня работает(без бесконечных рекурсий). =)
Я думаю тут зависит от содержимого виджета еще.
Но хотелось бы увидеть гарантированно рабочий вариант :)
Но хотелось бы увидеть гарантированно рабочий вариант :)
Ходят слухи, что рабочий вариант требует использование «виджета-обертки»
Ну можно костыли:
Так вроде делается. Этот вариант не тестил, если что можно в класс переменную запихнуть а не статиком. =)
PS За костыль сильно не пинайте =)
MainWindow::MainWindow(){
...
static bool resized=false;
...
}
void MainWindow::resizeEvent(QResizeEvent *a){
static bool resized;
if(!resized){
setGeometry(geometry().x(),geometry().y(),a->size().width(),a->size().width()/16*9);
resized=true;
}else{
resized=false;
}
}
Так вроде делается. Этот вариант не тестил, если что можно в класс переменную запихнуть а не статиком. =)
PS За костыль сильно не пинайте =)
А подскажите еще, как сделать чтоб интерфейс QML нормально реагировал на DPI устройства.
Типа аналог meta viewport в HTML. Пробовал
Но чото оно не слишком помогает
Типа аналог meta viewport в HTML. Пробовал
QQmlContext *context = new QQmlContext(engine.rootContext());
context->setContextProperty("screenPixelDensity", QGuiApplication::primaryScreen()->physicalDotsPerInch() * QGuiApplication::primaryScreen()->devicePixelRatio());
Но чото оно не слишком помогает
Ну давайте потролилм вас, за незнание гугла
stackoverflow.com/questions/452333/how-to-maintain-widgets-aspect-ratio-in-qt
stackoverflow.com/questions/452333/how-to-maintain-widgets-aspect-ratio-in-qt
Давайте потроллим вас за то, что вы даете ссылки не читая:
Это замечание справедливо и для оконной системы OSX, т.е. решение ниразу не кроссплатформенное (если предположить, что оно хоть где-то работает).
However, heightForWidth() doesn't work on toplevel windows on X11, since apparently the X11 protocol doesn't support that.
Это замечание справедливо и для оконной системы OSX, т.е. решение ниразу не кроссплатформенное (если предположить, что оно хоть где-то работает).
Я давал ссылку не на ответ, а на тему. А там, собственно сказано, что лучшее решение — это писать свой слой. Т.к. логика QtWidgets — задача виджета отрисовать элементы в том виде, в котором их нарисовал дизайнер. А вот их управлением занимается уже слой.
О каком слое идет речь? У окна нет родительского элемента, а вопрос как раз про окно, а не про виджет с родителем.
Зайдем с другой стороны. Зачем вам фиксированное соотношение сторон окна?
Просто в чем прикол, костыль, который предложили выше следует после прочтения доки(и всех сопутствующих ссылок). Я даже сам это делал, пока не переформулировал задачу.
А так работа с окнами — это пререгатива оконного менеджера. И если он не поддерживает это нативно, то вы обречены на написание костылей. А костыли в библиотеке грозят большими проблемами.
Иными словами, использование выскоуровневой либы\ЯП не означает, что вам не следует разбираться с низким уровнем.
Просто в чем прикол, костыль, который предложили выше следует после прочтения доки(и всех сопутствующих ссылок). Я даже сам это делал, пока не переформулировал задачу.
А так работа с окнами — это пререгатива оконного менеджера. И если он не поддерживает это нативно, то вы обречены на написание костылей. А костыли в библиотеке грозят большими проблемами.
Иными словами, использование выскоуровневой либы\ЯП не означает, что вам не следует разбираться с низким уровнем.
Я думал, статья о сраче GTK vs. Qt, а тут банальное описание, что нативщина лучше рантаймов…
Подскажите пожалуйста, а есть где то нативные компоненты под андройд или айос? квадратиками вручную рисовать ой как не хочется, а решение вроде как востребованное
Так это, почему, в итоге, я должен пересесть с ObjC на Qt? Кросс-платформенность для меня не настолько большой плюс, где список того, как Qt уделывает ObjC? Где обещанные опровержения мифов?
Стиль изложения — хороший, открыто декларирует в себе всякие дурашливые тени фанатизма… Не за что автору карму рубить.
Я всегда любил Qt, пользуюсь со времен версии 2.0. Великолепная библиотека. Была. С тех пор как проект пошел по рукам, библиотека с кодом и документацией state-of-the-art, которую всегда приводил в пример при сравнении, стала превращаться в кисель. Пик был где-то на версии 3.5-4.3. Потом код стал унывать, а документациия сначала перестала быть исчерпывающей, а потом и вовсе начала редеть. Каждый последующий владелец после trolltech по сути занимается переориентированием библиотеки, созданной для определенных целей, под свои нужды. В итоге чудо девелопмента начало превращаться в чудище со свистоперделками. Это, конечно, с одной стороны хорошо, проект обрастет новым кластером прльзователей, но те, кто пользовались им раньше, все больше разочаровываются, думаю. Сейчас моя версия 4.8. На 5.0 и выше не перейду ни за что.
> Используя декларативный язык QML (угадайте, где его придумали, лол)
А кстати, где его придумали? Попытался погуглить имена авторов и не нашел ((( Может быть Вы знаете?
А кстати, где его придумали? Попытался погуглить имена авторов и не нашел ((( Может быть Вы знаете?
(wrong level)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему я люблю Qt и вы все тоже должны его любить