Выпуск фреймворка Qt 5.5

[oYASo]

Очень вкусный релиз, молодцы ребята. За Qt Location отдельный большой респект!

[VioletGiraffe]

Поддержка Qt не внушает оптимизма. Мой серьёзный, но редкий баг на Mac OS уже 8 месяцев не чинят. Приходится собирать Мак-версию моего приложения с древней Qt 4.

[oYASo]

Тут вопрос — какая поддержка? Если платная, то печаль, а если Community, то ее как бы и нет же. Если кто-то захочет, то поправит, ну или поправьте сами.

[germn]

Вы этот баг зарепортили?

[VioletGiraffe]

Естественно.

[midday]

А можно ссылку на багрепорт? Ато ваши слова выглядят как некий очень «важный баг», исправление которого нужно только вам. Вы же ни рубля небось не заплатили за продукт. Если баг так важен для вас, то спокойно исправляйте и реквестируйте коммит, помогите другим. Qt довольно легко поддается исправлениям вручную =) все исходники довольно прозрачны и легко читаются.

[VioletGiraffe]

Я же сказал — редкий баг. Мне на форуме так и ответили: «Нам неинтересно его исправлять, мало голосов под репортом» (11 голосов уже, сколько же им нужно?). Насчёт легко читающихся исходников — хорошая шутка.

https://bugreports.qt.io/browse/QTBUG-43299

[midday]

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

[Wedmer]

Jolla?

[VioletGiraffe]

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

[midday]

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

[iroln]

Qt довольно легко поддается исправлениям вручную =) все исходники довольно прозрачны и легко читаются.

И что с того, если патч всё равно не примут или надо будет приложить очень серьёзные усилия, чтобы его приняли? Я когда-то делал багрепорт и патч для QGraphicsView Framework в 4 ветке, ну и никто баг так и не исправил. Держать и поддерживать свои локальные сборки со своими патчами? Мне такой подход не кажется правильным.

[BlackRaven86]

Если он исправляет баг и с ним нет никаких проблем, то почему же не примут? Мои патчи, по большей части, принимали.
Тут есть другой момент, что надо разобраться, как в Qt эти патчи слать, как работать с gerrit и т.п. Ну а в каких крупных проектах не так?

[midday]

Если и бывают такие проекты, где это не так, то заканчивается это все плачевно.
А еще же нужно прогнать тесты, может даже дописать тесты. Людям просто лень все это читать, разбираться и т.п. Одного не пойму, за что меня заминусовали, вроде все правильно сказал.

[BlackRaven86]

Так и есть. Самому бывает очень лень, когда отправляешь свой код, а тебе в ответ: «Все классно, но вот тесты бы еще...» :)

[crackedmind]

> Объявлены устаревшими Qt WebKit, Qt Quick 1 и Qt Script.
Дак и какая альтернатива Qt Script?

[EuroElessar]

QtQml, несмотря на название он не зависит от QtGui и в нем есть QJSEngine, который уже частично догнал по возможностям QtScript.

[e_asphyx]

Объясните, неужели QML удобнее для создания интерфейсов, чем традиционные виджеты?

[e_asphyx]

Та же фигня. Мне фактически C++ только для Qt и нужен. Я потому даже с STL особо глубоко не разбирался, в Qt всё равно всё своё.

[Renzo]

Долгое время использовал виджеты и вот недавно все-таки взялся за QML и начал писать интерфейсы на нем. Нет, он не удобнее, чем виджеты. Но результат при этом отличается на порядок — на QML можно сделать в несколько строк такие анимации, которые на Qt/C++ займут тонны кода

[tangro]

Значительно короче путь от «чистого листа» до «о, вот у меня уже по клику на кнопке из интернета загружается картинка и результат REST-запроса». Это привлекает новичков. При этом написание действительно сложного приложения рано или поздно приводит к граблям, которые на виджетах решить было бы проще.

[tzlom]

Смотря какие интерфейсы, анимации и сложные компоновки — гораздо легче. Если хорошо знаете как готовить MVC в Qt то всё становится вообще хорошо, если плохо — увы и ах, на чистых плюсах вам будет проще. QML гораздо проще для людей далёких от программирования. Но следует понимать что это отдельный язык и другая парадигма, если строить логику интерфейса как вы делаете это на С++ в QML можно пройтись по граблям.

[e_asphyx]

Это тот MVC, который QAbstractItemModel? Он же чудовищен. Особенно QAbstractItemView, применимость которого фактически ограничена табличными представлениями.

[tzlom]

Приблизительно это я и имел ввиду — если вы не разобрались как оно работает и зачем там что нужно — перебрасывать данные в QML прийдётся топорными способами которые могут доставить много проблем.
Он не чудовищный, он сложный и непонятно документированный (т.е. дока то на уровне Qt но вот прочтя её пользоваться этим не научишься)
Просто для затравки — QTreeView наследует QAbstractItemView, делайте выводы на сколько хорошо вы знаете Qt MVC :)

[e_asphyx]

Я изучал исходники Qt на эту тему. Мне однажды надо было сделать адресную книгу в стиле Outlook (карточки с полями). Поля — это в терминах Qt MVC столбцы, а карточки — строки. Выполнить отрисовку можно без проблем. Там были сложности с обработкой выделений. Выделения в MVC — это списки диапазонов, устроенные таким образом, что они получаются привязанными к прямоугольной сетке. Я детали забыл, к сожалению.

[Riateche]

Я много работал с Qt Model/View и делал на нем разные нетривиальные вещи. Чудовищным я бы его не назвал. Он достаточно сложен в понимании и требует вдумчивого чтения документации, но свою задачу — отделение представления от данных — в определенных рамках выполняет хорошо. Опять же, нужно понимать, что этот фрагмент Qt сделан не для глобальных универсальных применений Model/View, а для обеспечения возможности его применения в существующих виджетах (в том числе и табличных), предоставляемых Qt. Без этого отделить представление от данных было бы просто невозможно.

[BlackRaven86]

Зависит от того, какой интерфейс вам нужен. Если нужен классический десктопный интерфейс, чтобы выглядело «как на виджетах» и вело себя точно так же, то лучше на виджетах и писать, скорее всего :) А если требуемый вид отличается от стандартных виджетов или приложение пишется под мобильные платформы или это вообще игра — то на QML может быть сильно проще.

[QtRoS]

Пишу под мобильные платформы с использованием Qt\QML — да, легче. Притом намного. Научился получать довольно слабую связность компонентов, инкапсулировать логику в отдельные компоненты, получается неплохо)

[synacker]

По моему опыту, если есть красивый дизайн приложения, возможно с анимацией — конечно Qt Quick быстрее.
Если дизайна нет, и что то сам пытаешься сделать из стандартных контролов, то быстрее Qt Widgets.

[evocatus]

Прямо сзади от меня сидит коллега и пытается сделать GUI на Qt 5.2. Глядя на это всё действо я зарёкся связываться с этим фреймворком. Javascript который не Javascript, жутко тормознутые и большие приложения на выходе, корявые биндинги между C++ и QML, наличие альтернативного велосипеда практически для всего начиная со строк и массивов, судорожные попытки довести JS до ума и научить его хотя бы открывать файлы с диска и т.д.

По моим ощущениям у Qt 5.х плюс один — выглядит красиво. Всё остальное — один большой минус.

[Wedmer]

Похоже на рассуждения дорожного рабочего об инструментах ювелира.

[evocatus]

Конечно, раз я смею говорить о недостатках Qt я «дорожный рабочий». Он идеален, у него нет никаких проблем, на Qt надо перейти всем немедленно.

[Wedmer]

Просто, судя по вашему комментарию, предмет вы знаете, мягко говоря, поверхностно.

[midday]

Особенно порадовало «Javascript который не Javascript» =) Где это написано, что это не Javascript?