Russian Qt Forum

Здравствуйте, уважаемые коллеги.
Не с целью холивара, а в поисках истины.
Планирую писать приложение-замену существующему (писалось с 1999 года на Visual Studio 6).
Пишу, естественно, на Qt. Но загвоздка в выборе парадигмы для Gui: то ли взять виджеты (с ними есть определенный опыт), то ли Qml (с ним опыта очень мало, и не в продакшене).
Виджеты понятны, они мне нравились, но потом я поразбирался с Qml и осознал, что его концепция мне намного ближе (описание интерфейса, динамическая загрузка из файлов любых элементов, JavaScript).
Бэкэнд (модели) будут по-любому на плюсах.
Поэтому сейчас хочу для себя понять: можно ли использовать Qml в продакшене для десктопа, и если да, то что именно применять (Quick Controls или Quick controls 2)?
Приложение хотелось бы делать не совсем уж хипстерским (для хим. лабораторий), т.е. нужны и традиционные элементы (меню хотя бы)).
Очень интересуют мнения людей, которые делали на Qml реальные законченные приложения и, желательно, "не в стол"))
Спасибо.

QML хорош, когда ВЕСЬ проект написан на нём. Когда у тебя половина API на С++, то начинаются такие извращения, что мало не покажется.

QML хорош и в использовании с моделями на плюсах, если проект спроектирован без ляпов.
Вел один относительно крупный проект (для десктопа) с регулярными обновлениями 3 года (или даже больше). UIная часть делалась полностью мной и с нуля. Проект жив по сей день, просто я им уже не занимаюсь. Работало все на парке довольно устаревших машин, пролагиваний по вине QtQuick не случалось никогда.
Никаких проблем за это время с QML не обнаружил. Наоборот, он показал себя крайне гибким, из плюсов:
- Снижение трудозатрат, уменьшение времени выпуска обновлений
- Абсолютная гибкость, отсутствие каких-либо ограничений в реализации тех или иных идей
- Простота создания адаптивного дизайна, нативная поддержка сенсорных экранов и прочих плюшек.
- Возможность быстрого создания рабочих прототипов с целью их тестирования на userfrendly, абстрация UIной части от "бекенд"-логики, что позволяет вести разработку и отладку куда более удобно и эффективно.
- Полная асинхронность/eventloop и js. В современном мире без них никуда.
Среди контролов конечно же стоит выбрать вторые, хотя лично я предпочитаю пилить свои, адаптированные под нужды конкретного приложения, благо это не занимает много времени.

Спасибо.
Я хочу ВЕСЬ API на С++ и весь GUI на QML. Для меня как раз важно, чтобы четкое разделение этих двух частей, тогда "поменять цвет кнопок" смогут другие люди.

Спасибо. Сейчас как раз займусь прототипированием)

Ох, а я бы не использовал QML для десктопа, если это не приложение типа WinAmp-а
(где красивые кнопочки и анимашки) и прочее.

ИМХО, на виджетах гибче все. Но на QML хорошо получаются всякие-там интрумент-кластеры
(со стрелочками, приборчиками, прочими градусниками с мудреной анимацией).

Какие операционки и какие машины были?
ПС. У меня стояла на машине Joxi, лагала и выпендривалась.
С тех пор QML возненавидел.
И я понят, что стабильнее виджетной технологии пока ничего нету.

Просто замечательно, подтянулись люди с другой стороны. Это очень важно.
На виджетах я делал прошлое приложение. Сравнивая с QML, не могу так сразу выделить: в чем проявляется гибкость.

Венда и линукс. Проблемы были только со старыми атомами, графика которых не умела OpenGL выше 1.1. Исключительно на старых версиях квика, где софтверного рендеринга не было.
Это не так. Все, что можно сделать на виджетах - можно сделать и на QML. А вот наоборот - увы.

тоже недавно освоил QML, до этого тоже был опыт с Qt без QML.
Сейчас сделал выбор в пользу QML.
controls 2 говорит за себя сам, для лабораторных целей там по моему вообще всё идеально, регуляторы всякие и тд...

Лично я просто не хочу переходить на Qt5. Все практически то же, только вес больше и заморочек поболя.

Я тоже так думал, но узнал (через боль и страдания), что в Qt4 регулярные выражения (QRegExp) оказались очень обрезанными, и тогда уже точно решил, что пора переходить. Прошу заметить, что это был embedded проект, а уж на десктопе все еще очевиднее.

Здесь (http://blog.qt.io/blog/2016/06/10/qt-quick-controls-2-0-a-new-beginning/#comment-1197843) можно глянуть наиболее развернутый ответ от J-P Nurmi (a senior software engineer at The Qt Company).

В 1м квиве есть несколько критических багов, которые уже никогда не будут исправлены.

Всё что можно сделать на виджетах, можно сделать на QML - вранье :D

Я бы так не утверждал. Перехватите-ка мне отрисовку фреймов/пиксмапов на QML да так чтобы оно бы работало...  :P

может можно перетащить регекспы?

Примеры в студию.
Ну это уже слабо относится к самому qml. Тут речь уже об OpenGL и его реализации в Qt. Я в этом не силен.

Ооо, холиварчик разгоняет, как я смотрю)))
Печалька, но в новом проекте буду на виджетах, ибо времени\желания писать свой Table(Tree)View (или использовать из QC1) нет. Поэтому буду писать по-старинке и ждать Qt5.9, там, может, и появится в QC2 то, что мне нужно.
Но тему можно (нужно) оставить, посмотрим кто как будет топить за свою технологию))

Я вот сколько не пытался сделать что-нибудь на QML сталкиваюсь всегда с одной проблемой (один и тот же код на двух разных машинах - Вин7 и ВинХП) - тормоза при первом старте и жуткие тормоза при попытке делать интерфейс в Дизайнере Креатора (при любом редактировании в дизайнере Креатор подвисает секунд на 10-30!!!).

Кроме того Дизайнере Креатора не все QML открываются, он часто выдаёт сообщение, что данный QML не поддерживается (хотя всегда использовал для QML-проектов свежую версию Креатора).

По этому мне даже не понятно, как люди создают программы с использованием QML.

В своих проектах использую динамическую загрузку UI (*.ui) форм + JavaScript.
Вся бизнес логика в скриптах.

без графического редактора  :)

Интересный вариант. А не могли бы вы чуть детальнее раскрыть?
Спасибо.

Потому что писать нужно руками, дизайнер creator-а эт изврат.

Работы на 10 минут.
Но не советую. Tree View это ужас с точки зрения UX. В 2017м стоит избегать подобных вещей.

Что-то мне кажется на счет "работы на 10 минут" вы погорячились, прямо вот за 10 можно сделать весь интерфейс для связи с моделью?
И если бы было на 10 минут, то вряд ли бы TableView был в планах версии 5.9 (самое раннее - июнь 2017), а уже был бы зарелизен.
Хотя на счет вашего тезиса по поводу "писать руками" я полностью согласен, все так логично, что редактора абсолютно достаточно.

10 минут - только на вью, без стайлинга. Грубо говоря, ректанглы с текстом. Нужна всего лишь рекурсия + anchors.leftMargin, зависящий от "глубины".
Делать что-то под конкретный проект проще/быстрее чем делать контролы, которые в идеале должны учитывать интересы всех проектов, иметь кучу настроек и так далее.

10 минут на вью - эт вы лишка хватили. Вы еёщ скажите что оптимизация автоматическая будет, работа с большими объемами данных встроенная.
10 минут - это натыкать "ректанглы с текстом".
Сделать View - это работа на неделю минимум.

И по поводу всё что можно - достаньте мне отрисовку QML. Не стандартизированный ректангл, а свою отрисовку. С попиксельным контролем :D

Почему я никак не могу понять QML - потому что нет контроля происходящего. Вообще.
Ну это как если бы на С++ имелись бы только event'овые функции, аля mouseMove/mouseClick и прочие.

Можете рисовать на OpenGL что вашей душе угодно в QQuickFramebufferObject (http://doc.qt.io/qt-5/qquickframebufferobject.html) и помещать это в существующую сцену. Или создавать элементы со своей отрисовкой: "Scene Graph - Custom Geometry (http://doc.qt.io/qt-5/qtquick-scenegraph-customgeometry-example.html)".

Мб я неправильно выразился?
Не qml-джет для рисования.
Не проброс C++ отрисовки в QML.
Не отрисовку OpenGL на сцене.
А именно отрисовку QML.

Я бы порекомендовал бы Вам более точно/профессионально формулировать свои вопросы.
Это ложь. Кстати, view никак не определяет отрисовку делегатов, так что технически - без разницы, ректанглы там с текстом или полноценно сдизайненый компонент. По определению это разные вещи, учите матчасть.
Здесь явно перепутаны причина и следствие.

А такое тоже можно?
http://www.devmachines.com/qtitandatagrid-overview.html
Есть примеры, пусть и платные? Я не в смысле подколоть, мне на самом деле интересно. Для меня вообще существенная десктоп приложений ассоциируется именно с наворочанным DBGrid. Как вы с этим в QML мире живете, или для вас этот контрол не актуален?

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

Qt Quick Examples - Canvas (http://doc.qt.io/qt-5/qtquick-canvas-example.html), то что надо?

В качестве JavaScript движка пока задействован QScriptEngine.
В нём зарегистрированы функции создания виджетов по имени класса, работой с БД и корбой.
Реализован на базе QUiLoader свой загрузчик форм и создатель виджетов/лэйаутов с регистрацией фабрики кастомных виджетов.
Загрузчик при загрузке форм делает QScriptEngine::evaluate() соответствующего *.js с установкой "this" на загруженный виджет.
И уже в скрипте коннектимся к сигналам и дёргаем слоты или Q_INVOKABLE методы либо пропертя.
Но, на всю эту обвязку, конечно, пришлось потратить n-ое количество времени.

Всё шутите... Грид подобного уровня нативным способом без заморочек...
С группировкой, фильтрацией, обобщенными строками, кастомными редакторами в ячейках, многострочными заголовками, быстрым поиском, режимом превью для строк, фиксированными колонками. Про "мелочи" в виде сортировок, автоподбора ширины и высоты ячеек, и прочих режимах cardview я и не вспоминаю.
Если уж это не userfrendly, то я тогда и не знаю что для вас userfrendly. Примитивный ListView а-ля список контактов в Telegram?
Как вы с БД вообще работаете из QML? Как на экран выводите хотя бы 200 записей? Как их редактируете? Есть хотя бы один скриншот реального QLM приложения, рассчитанного на работу с БД в классическом десктопном понимании этого слова?
Несколько раз уже порывался было нырнуть в эту QML пучину - всегда отсутствие хоть какого-нибудь сколь угодно разумного грида останавливало.

Давайте уже определимся. View - это view, и ничего больше.
Конечно на весь этот функционал придется затратить достаточное количество времени, но это время будет гарантированно меньше затраченного на реализацию аналогичного виджета. Так что в минус данной технологии это явно не засчитаешь.

Все, что выглядит достаточно просто с точки зрения пользователя и не заставляет его браться за голову от огромного количества информации на экране.

Без проблем. 200 записей - не так уж и много. Если их больше - вам явно нужны какие-то категории/пейджи/навигация/нечто подобное. Не заставляйте пользователя искать нужную ему информацию среди кучи ненужной.

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

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

Есть как минимум 3 способа получить нормальный разумный грид.

Включу режим зануды.

Неубедительно и бездоказательно. Отсутствие скриншотов практических реализаций тому явный пример. Хотите доказать обратное - скриншот в студию.

Скриншот в студию.

В excel тоже вы тоже файлы размером >200 строк не отображете? И в word документы размером больше 3-х страниц не смотрите?

Так и вижу excel, в котором для редактирования каждой ячейки нужно отдельную форму открывать. Это ведь так удобно, всего два-три лишних клика мышкой на каждую строку! А ещё можно в notepad для каждого изменения символа (ладно, упрощу - для каждой отдельной строки) отдельную форму открывать. А чего, будет работать!

Скриншот - коммерческая тайна? Да ладно вам. Даже комментировать не буду, просто смешно. Заблюрьте уж содержимое своего грида если уж там настолько всё страшно. Или у вас сам интерфейс КТ?

Какие же? Тоже "коммерческая тайна"? Озвучьте уже их, а лучше скриншоты, на словах я тоже много чего могу.

Мне без разницы. Я сюда не доказывать свои скилзы пришел, а пользу приносить. Не нравятся разумные аргументы - оставайтесь при своем мнении.
Excel и word - это классические примеры отсутствия автоматизации. Я же занимаюсь автоматизацией бизнес-процессов. И ни в одном адекватном приложении ты не найдешь такой ситуации, когда пользователь будет вынужден ежедневно вносить/редактировать кучи данных. Если у тебя так - значит ты где-то облажался и чего-то недоавтоматизировал, можешь пилить любой дизайн, т.к. твое решение попросту никто не купит)
Это действительно удобно, для пользователя. По вашей аналогии бухгалтерам стоит работать напрямую с SQL, ведь нахера им UI, долбанул запрос - и вот тебе любой готовый отчет.

Скриншот - нет, дизайн - да.
Зачем тебе именно мой? Погугли себе книжек по UI, посмотри как это реализовано в хороших софтинах.

GridView, Row+Column+Flickable, ListView+Column||Row, Component.createObject + делаем все что угодно ручками.
Зависит от потребностей.

Ещё в QML мне не нравится каша из дизайна и кода. Сколько лет назад такое было в UI формах? Хотя даже в формах такого не было, т.к. там просто подключался отдельный ui.h файл, в котором и писался код. Потом уже это разделили полностью и стали делать формы через агрегацию указателя. В QML же всё в куче.

Потом ещё оказывается, что до сих пор разметка формы пишется вручную, потому что QML/Quick настолько крут, что дизайнер его до сих пор не пор поддерживает на стабильном уровне - постоянно что-то глючит и не работает, ползёт вёрстка и т.п.

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

Вот сейчас все пользователи бухгалтерских программ вздрогнули. А программисты SAP, 1C, Axapta и прочих систем автоматизации масштаба ERP срочно начали писать заявления об увольнении.

В Qt Creator тоже каждую строку кода в отдельной форме редактируешь? А чего, удобно же! ПКМ -> "вставить for" -> в появившемся окне поля "тип переменной", "начальное значение", "условие выхода", "итерация"...

Дизайн UI - КТ? Мир сошел с ума.
 
Где я говорил, что нужен именно твой? Покажи мне любой, разумный грид на QML.

Я прекрасно знаю как это реализовано в хороших софтинах. Именно поэтому и хочу посмотреть хоть на одну хорошую реализацию именно на QML. Но почему-то не могу найти таких. Или они тоже все КТ?

Итого: продвинутые UI для отображения наворочанных табличных данных для десктопа, возможно, существуют, но они настолько секретны, что даже скриншот UI является коммерческой тайной. У меня  больше вопросов нет.

А в чем проблема отобразить 200 записей? Да хоть миллион - не проблема.

Javascript
import QtQuick 2.5
import QtQuick.Window 2.2
import QtQuick.Controls 1.4
 
Window {
    visible: true
    width: 640
    height: 480
    title: qsTr("Test Lines")
 
    ScrollView {
        anchors.fill: parent
        ListView {
            id: listView
            anchors.fill: parent
            model: 1000000
 
            delegate: Text {
                width: listView.width
                height: 20
                text: qsTr("Item: %1").arg(index + 1)
            }
        }
    }
}
 

Весь проект во вложении.

Я надеюсь в этой теме вы прочли больше, чем один конкретно этот пост. Хотелось бы увидеть как на QML потом с этими записями работают, а именно:

Читал конечно, но я намеренно процитировал именно фразу про 200 строк. Так в чем может быть проблема именно с 200 и более строками и в то же время с 50 или 150 будет все нормально?

А насчет перечисленных фич. Не являясь спецом по UI для баз данных, могу сказать, что фильтрация и сортировка делается не в QML, а в С++ бэкенде через навешивания на основную модель данных QSortFilterProxyModel или наследника QAbstractProxyModel. Редактирование прямо в ячейке - это разве проблема? Даже не знаю что-то тут комментировать. Автоподбор ширины и высоты ячеек: читайте про implicitWidth и implicitHeight. Группировка - ListView.section - не оно? В общем, при желании и достаточных навыках можно сделать все что угодно. Но, (возможно) сделать UI на виджетах будет быстрее и проще, особенно если нет достаточного опыта работы с QtQuick.

Подождите пожалуйста полтора года, на рынке будет новый смартфон, интерфейс оного полностью запилен на QML. Делают наши пацаны из Нижнего Новгорода, а деньги вкладывают зарубежные партнеры.

Так никто и не спорит, что банальные интерфейсы на QML делать можно, и возможно даже проще, чем на виджетах. Речь идёт о сложных интерфейсах.

По поводу канваса - я к сожалению не совсем пойму, там есть возможность попиксельного доступа? Или там всё на кривых?

Смартфон это куцый огрызок экрана с таким же куцым интерфейсом. Там на экране дай боже 20 записей нормальным шрифтом и с доп информацией поместиться.
Вы ратуете "виджеты отстой", а виджеты сделаны для монитора. Для полноценного интерфейса с полноценной работой с ним, а не тап-тап с одним пальцем :D

PS пока не видел в этой теме ни одной картинки QML интерфейса. Мб мне глаза надо закапать?

Вы название топика читали? Тут про десктоп обсуждение...

Сказали же "коммерческая тайна". Ну шо тут неясного? )