Комментарии 37
Очень вкусный релиз, молодцы ребята. За Qt Location отдельный большой респект!
+4
Поддержка Qt не внушает оптимизма. Мой серьёзный, но редкий баг на Mac OS уже 8 месяцев не чинят. Приходится собирать Мак-версию моего приложения с древней Qt 4.
+1
Тут вопрос — какая поддержка? Если платная, то печаль, а если Community, то ее как бы и нет же. Если кто-то захочет, то поправит, ну или поправьте сами.
+4
Вы этот баг зарепортили?
-3
А можно ссылку на багрепорт? Ато ваши слова выглядят как некий очень «важный баг», исправление которого нужно только вам. Вы же ни рубля небось не заплатили за продукт. Если баг так важен для вас, то спокойно исправляйте и реквестируйте коммит, помогите другим. Qt довольно легко поддается исправлениям вручную =) все исходники довольно прозрачны и легко читаются.
0
Я же сказал — редкий баг. Мне на форуме так и ответили: «Нам неинтересно его исправлять, мало голосов под репортом» (11 голосов уже, сколько же им нужно?). Насчёт легко читающихся исходников — хорошая шутка.
https://bugreports.qt.io/browse/QTBUG-43299
https://bugreports.qt.io/browse/QTBUG-43299
+1
Проголосовал тоже. Будем ждать исправления. Сталкивался с этим багом.
Вообще хороший был бы вариант, если подсадить на Qt какую-нибудь «взрослую» контору, которая бы была заинтересованно в развитии Qt и сталкивалась с багами на своем производстве. Но пока я не вижу такого и врятли это будет.
Вообще хороший был бы вариант, если подсадить на Qt какую-нибудь «взрослую» контору, которая бы была заинтересованно в развитии Qt и сталкивалась с багами на своем производстве. Но пока я не вижу такого и врятли это будет.
0
Jolla?
0
Спасибо.
Моя контора вполне взрослая, просто оочень маленькая :)
Мой друг работает в существенно более взрослой немецкой аутсорсинговой конторе с офисами по всей Европе, тоже используют Qt в некоторых проектах.
Моя контора вполне взрослая, просто оочень маленькая :)
Мой друг работает в существенно более взрослой немецкой аутсорсинговой конторе с офисами по всей Европе, тоже используют Qt в некоторых проектах.
0
НЛО прилетело и опубликовало эту надпись здесь
Qt довольно легко поддается исправлениям вручную =) все исходники довольно прозрачны и легко читаются.И что с того, если патч всё равно не примут или надо будет приложить очень серьёзные усилия, чтобы его приняли? Я когда-то делал багрепорт и патч для QGraphicsView Framework в 4 ветке, ну и никто баг так и не исправил. Держать и поддерживать свои локальные сборки со своими патчами? Мне такой подход не кажется правильным.
0
Если он исправляет баг и с ним нет никаких проблем, то почему же не примут? Мои патчи, по большей части, принимали.
Тут есть другой момент, что надо разобраться, как в Qt эти патчи слать, как работать с gerrit и т.п. Ну а в каких крупных проектах не так?
Тут есть другой момент, что надо разобраться, как в Qt эти патчи слать, как работать с gerrit и т.п. Ну а в каких крупных проектах не так?
+1
Если и бывают такие проекты, где это не так, то заканчивается это все плачевно.
А еще же нужно прогнать тесты, может даже дописать тесты. Людям просто лень все это читать, разбираться и т.п. Одного не пойму, за что меня заминусовали, вроде все правильно сказал.
А еще же нужно прогнать тесты, может даже дописать тесты. Людям просто лень все это читать, разбираться и т.п. Одного не пойму, за что меня заминусовали, вроде все правильно сказал.
+1
> Объявлены устаревшими Qt WebKit, Qt Quick 1 и Qt Script.
Дак и какая альтернатива Qt Script?
Дак и какая альтернатива Qt Script?
0
Объясните, неужели QML удобнее для создания интерфейсов, чем традиционные виджеты?
+2
НЛО прилетело и опубликовало эту надпись здесь
Долгое время использовал виджеты и вот недавно все-таки взялся за QML и начал писать интерфейсы на нем. Нет, он не удобнее, чем виджеты. Но результат при этом отличается на порядок — на QML можно сделать в несколько строк такие анимации, которые на Qt/C++ займут тонны кода
0
Значительно короче путь от «чистого листа» до «о, вот у меня уже по клику на кнопке из интернета загружается картинка и результат REST-запроса». Это привлекает новичков. При этом написание действительно сложного приложения рано или поздно приводит к граблям, которые на виджетах решить было бы проще.
0
Смотря какие интерфейсы, анимации и сложные компоновки — гораздо легче. Если хорошо знаете как готовить MVC в Qt то всё становится вообще хорошо, если плохо — увы и ах, на чистых плюсах вам будет проще. QML гораздо проще для людей далёких от программирования. Но следует понимать что это отдельный язык и другая парадигма, если строить логику интерфейса как вы делаете это на С++ в QML можно пройтись по граблям.
+1
Это тот MVC, который QAbstractItemModel? Он же чудовищен. Особенно QAbstractItemView, применимость которого фактически ограничена табличными представлениями.
0
Приблизительно это я и имел ввиду — если вы не разобрались как оно работает и зачем там что нужно — перебрасывать данные в QML прийдётся топорными способами которые могут доставить много проблем.
Он не чудовищный, он сложный и непонятно документированный (т.е. дока то на уровне Qt но вот прочтя её пользоваться этим не научишься)
Просто для затравки — QTreeView наследует QAbstractItemView, делайте выводы на сколько хорошо вы знаете Qt MVC :)
Он не чудовищный, он сложный и непонятно документированный (т.е. дока то на уровне Qt но вот прочтя её пользоваться этим не научишься)
Просто для затравки — QTreeView наследует QAbstractItemView, делайте выводы на сколько хорошо вы знаете Qt MVC :)
0
Я изучал исходники Qt на эту тему. Мне однажды надо было сделать адресную книгу в стиле Outlook (карточки с полями). Поля — это в терминах Qt MVC столбцы, а карточки — строки. Выполнить отрисовку можно без проблем. Там были сложности с обработкой выделений. Выделения в MVC — это списки диапазонов, устроенные таким образом, что они получаются привязанными к прямоугольной сетке. Я детали забыл, к сожалению.
0
Я много работал с Qt Model/View и делал на нем разные нетривиальные вещи. Чудовищным я бы его не назвал. Он достаточно сложен в понимании и требует вдумчивого чтения документации, но свою задачу — отделение представления от данных — в определенных рамках выполняет хорошо. Опять же, нужно понимать, что этот фрагмент Qt сделан не для глобальных универсальных применений Model/View, а для обеспечения возможности его применения в существующих виджетах (в том числе и табличных), предоставляемых Qt. Без этого отделить представление от данных было бы просто невозможно.
+2
Зависит от того, какой интерфейс вам нужен. Если нужен классический десктопный интерфейс, чтобы выглядело «как на виджетах» и вело себя точно так же, то лучше на виджетах и писать, скорее всего :) А если требуемый вид отличается от стандартных виджетов или приложение пишется под мобильные платформы или это вообще игра — то на QML может быть сильно проще.
0
Пишу под мобильные платформы с использованием Qt\QML — да, легче. Притом намного. Научился получать довольно слабую связность компонентов, инкапсулировать логику в отдельные компоненты, получается неплохо)
0
По моему опыту, если есть красивый дизайн приложения, возможно с анимацией — конечно Qt Quick быстрее.
Если дизайна нет, и что то сам пытаешься сделать из стандартных контролов, то быстрее Qt Widgets.
Если дизайна нет, и что то сам пытаешься сделать из стандартных контролов, то быстрее Qt Widgets.
0
НЛО прилетело и опубликовало эту надпись здесь
Прямо сзади от меня сидит коллега и пытается сделать GUI на Qt 5.2. Глядя на это всё действо я зарёкся связываться с этим фреймворком. Javascript который не Javascript, жутко тормознутые и большие приложения на выходе, корявые биндинги между C++ и QML, наличие альтернативного велосипеда практически для всего начиная со строк и массивов, судорожные попытки довести JS до ума и научить его хотя бы открывать файлы с диска и т.д.
По моим ощущениям у Qt 5.х плюс один — выглядит красиво. Всё остальное — один большой минус.
По моим ощущениям у Qt 5.х плюс один — выглядит красиво. Всё остальное — один большой минус.
-4
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Выпуск фреймворка Qt 5.5