История изменений
Исправление GPFault, (текущая версия) :
Для приложений средней-малой сложности: пишешь логику и view-модель приложения на C++, выставляешь свойства, слоты и сигналы как иерахически структурированные QObject, описывающие объекты предметной области. Всё состояние на 100% хрнится в С++-части.
С++логика и view-модель получается полностью инспектируемая, тривиально покрывается тестами без залезания в чёрный ящик, легко запускается в контексте тевтов без каког-либо GUI.
Но при этом в C++коде вообще ни одного упоминания ничего GUI-ного кроме пары строчек в main.
view объявляешь на qml, структуру виджетов (сбилдится один раз при старте приложения) и привязки к свойства типа выражений
text: Math.max(root_model.left.power_percent,
root_model.right.power_percent,
root_model.bottom.power_percent) + "%"
Диайнером не пользовался, писал qml руками.
Qt внутри подписывается на сигналы изменения свойств, причём на всех уровнях - то есть и на изменение свойства root_model.left
и на свойство root_model.left.power_percent
и тк для всех
Пересчитывает+перерисовывает только тот кусок, который соотвествует событиям изменения - при этом логике приложения достаточно изменить Qt-свойство в соотвествии его протоколом.
Я писал на QtQuick только одно приложение, запускал на Rpi3 1GB (linux + тачскрин 800x600). После запуска фигачило 60FPS, тормозов не было.
Минус был найден только один - довольно долгий старт, порядка 15 сек. Второй минус - некоторые вкусные компоненты не под LGPL. Кроме этих двух - минусов не увидел.
Плюсы:
- тестируемый и вообще отвязанный от GUI-классов код view-модели на С++
- Не содержащий бизнес-логики (говно)код на QML, который общается с view-моделью через строго определённое API, то же которое покрывается тестами. Он говнокод, но внутренние инварианты модели нарушить не сможет. И из-за отсутсвия во view состояния - воспроизводимость багов в говнокоде не зависят от предистории. Она визуализирует конкретную мдель или правильно или нет. В отличии от генерации виджетов в функции - нельзя по ошибке сгенрировать виджет только под if, а потом забыть сделать перевычисление списка виджетов, когда он нужен
- Сигналы об изменении свойств дают идеальную логику обновления:
- не надо явным оразом писать «GUI перечитай такое-то свойства, я тут что-то поменял» - такая подписка делается автоматом.
- и в GUIи в view-модели пересчитывается-перерисовыается ровно то что менялось, ничего другого. К свойствам, которые не менялись и обращений не будет.
- для обеспечения такого поведения количество танцев с бубном на уровне ситаксиса очень умеренно - достаточно аккуратно использовать Qt-Property (примитивная макро-шаблоно-магия над C++)
Вцелом - по соотношению сроки/количество_багов/удобство_использования_результата я остался очень доволен qt quick (по сравнению с QtWidgets, а также WPF и WinForms на винде).
Исправление GPFault, :
Для приложений средней-малой сложности: пишешь логику и view-модель приложения на C++, выставляешь свойства, слоты и сигналы как иерахически структурированные QObject, описывающие объекты предметной области. Всё состояние на 100% хрнится в С++-части.
С++логика и view-модель получается полностью инспектируемая, тривиально покрывается тестами без залезания в чёрный ящик, легко запускается в контексте тевтов без каког-либо GUI.
Но при этом в C++коде вообще ни одного упоминания ничего GUI-ного кроме пары строчек в main.
view объявляешь на qml, структуру виджетов (сбилдится один раз при старте приложения) и привязки к свойства типа выражений
text: Math.max(root_model.left.power_percent,
root_model.right.power_percent,
root_model.bottom.power_percent) + "%"
Диайнером не пользовался, писал qml руками.
Qt внутри подписывается на сигналы изменения свойств, причём на всех уровнях - то есть и на изменение свойства root_model.left
и на свойство root_model.left.power_percent
и тк для всех
Пересчитывает+перерисовывает только тот кусок, который соотвествует событиям изменения - при этом логике приложения достаточно изменить Qt-свойство в соотвествии его протоколом.
Я писал на QtQuick только одно приложение, запускал на Rpi3 1GB (linux + тачскрин 800x600). После запуска фигачило 60FPS, тормозов не было.
Минус был найден только один - довольно долгий старт, порядка 15 сек. Второй минус - некоторые вкусные компоненты не под LGPL. Кроме этих двух - минусов не увидел.
Плюсы:
- тестируемый и вообще отвязанный от GUI-классов код view-модели на С++
- Не содержащий бизнес-логики (говно)код на QML, который общается с view-моделью через строго определённое API, то же которое покрывается тестами. Он говнокод, но внутренние инварианты модели нарушить не сможет.
- Сигналы об изменении свойств дают идеальную логику обновления:
- не надо явным оразом писать «GUI перечитай такое-то свойства, я тут что-то поменял» - такая подписка делается автоматом.
- и в GUIи в view-модели пересчитывается-перерисовыается ровно то что менялось, ничего другого. К свойствам, которые не менялись и обращений не будет.
- для обеспечения такого поведения количество танцев с бубном на уровне ситаксиса очень умеренно - достаточно аккуратно использовать Qt-Property (примитивная макро-шаблоно-магия над C++)
Вцелом - по соотношению сроки/количество_багов/удобство_использования_результата я остался очень доволен qt quick (по сравнению с QtWidgets, а также WPF и WinForms на винде).
Исправление GPFault, :
Для приложений средней-малой сложности: пишешь логику и view-модель приложения на C++, выставляешь свойства, слоты и сигналы как иерахически структурированные QObject, описывающие объекты предметной области. Всё состояние на 100% хрнится в С++-части.
С++логика и view-модель получается полностью инспектируемая, тривиально покрывается тестами без залезания в чёрный ящик, легко запускается в контексте тевтов без каког-либо GUI.
Но при этом в C++коде вообще ни одного упоминания ничего GUI-ного кроме пары строчек в main.
view объявляешь на qml, структуру виджетов (сбилдится один раз при старте приложения) и привязки к свойства типа выражений
text: Math.max(root_model.left.power_percent,
root_model.right.power_percent,
root_model.bottom.power_percent) + "%"
Диайнером не пользовался, писал qml руками.
Qt внутри подписывается на сигналы изменения свойств, причём на всех уровнях - то есть и на изменение свойства root_model.left
и на свойство root_model.left.power_percent
и тк для всех
Пересчитывает+перерисовывает только тот кусок, который соотвествует событиям изменения - при этом логике приложения достаточно изменить Qt-свойство в соотвествии его протоколом.
Я писал на QtQuick только одно приложение, запускал на Rpi3 1GB (linux + тачскрин 800x600). После запуска фигачило 60FPS, тормозов не было.
Минус был найден только один - довольно долгий старт, порядка 15 сек. Второй минус - некоторые вкусные компоненты не под LGPL. Кроме этих двух - минусов не увидел.
Плюсы:
- тестируемый и вообще отвязанный от GUI-классов код view-модели на С++
- Не содержащий бизнес-логики (говно)код на QML, который общается с view-моделью через строго определённое API, то же которое покрывается тестами. Он говнокод, но внутренние инварианты модели нарушить не сможет.
- Сигналы об изменении свойств дают идеальную логику обновления: - не надо явным оразом писать «GUI перечитай такое-то свойства, я тут что-то поменял» - такая подписка делается автоматом. В GUI пересчитывается-перерисовыается ровно то что менялось, ничего другого для обеспечения такого поведения количество танцев с бубном очень умеренно - достаточно аккуратно использовать Qt-Property (примитивная макро-шаблоно-магия над C++)
Вцелом - по соотношению сроки/количество_багов/удобство_использования_результата я остался очень доволен qt quick (по сравнению с QtWidgets, а также WPF и WinForms на винде).
Исправление GPFault, :
Для приложений средней-малой сложности: пишешь логику и view-модель приложения на C++, выставляешь свойства, слоты и сигналы как иерахически структурированные QObject, описывающие объекты предметной области. Всё состояние на 100% хрнится в С++-части.
С++логика и view-модель получается полностью инспектируемая, тривиально покрывается тестами без залезания в чёрный ящик, легко запускается в контексте тевтов без каког-либо GUI.
Но при этом в C++коде вообще ни одного упоминания ничего GUI-ного кроме пары строчек в main.
view объявляешь на qml, структуру виджетов (сбилдится один раз при старте приложения) и привязки к свойства типа выражений
text: Math.max(root_model.left.power_percent,
root_model.right.power_percent,
root_model.bottom.power_percent) + "%"
Диайнером не пользовался, писал qml руками.
Qt внутри подписывается на сигналы изменения свойств, причём на всех уровнях - то есть и на изменение свойства root_model.left и на свойство root_model.left.power_percent. Пересчитывает+перерисовывает только тот кусок, который соотвествует событиям изменения - при этом логике приложения достаточно изменить Qt-свойство в соотвествии его протоколом.
Я писал на QtQuick только одно приложение, запускал на Rpi3 1GB (linux + тачскрин 800x600). После запуска фигачило 60FPS, тормозов не было.
Минус был найден только один - довольно долгий старт, порядка 15 сек. Второй минус - некоторые вкусные компоненты не под LGPL. Кроме этих двух - минусов не увидел.
Плюсы:
- тестируемый и вообще отвязанный от GUI-классов код view-модели на С++
- Не содержащий бизнес-логики (говно)код на QML, который общается с view-моделью через строго определённое API, то же которое покрывается тестами. Он говнокод, но внутренние инварианты модели нарушить не сможет.
- Сигналы об изменении свойств дают идеальную логику обновления: - не надо явным оразом писать «GUI перечитай такое-то свойства, я тут что-то поменял» - такая подписка делается автоматом. В GUI пересчитывается-перерисовыается ровно то что менялось, ничего другого для обеспечения такого поведения количество танцев с бубном очень умеренно - достаточно аккуратно использовать Qt-Property (примитивная макро-шаблоно-магия над C++)
Вцелом - по соотношению сроки/количество_багов/удобство_использования_результата я остался очень доволен qt quick (по сравнению с QtWidgets, а также WPF и WinForms на винде).
Исходная версия GPFault, :
Для приложений средней-малой сложности: пишешь логику и view-модель приложения на C++, выставляешь свойства, слоты и сигналы как иерахически структурированные QObject, описывающие объекты предметной области. Всё состояние на 100% хрнится в С++-части.
С++логика и view-модель получается полностью инспектируемая, тривиально покрывается тестами без залезания в чёрный ящик, легко запускается в контексте тевтов без каког-либо GUI.
Но при этом в C++коде вообще ни одного упоминания ничего GUI-ного кроме пары строчек в main.
view объявляешь на qml, структуру виджетов (сбилдится один раз при старте приложения) и привязки к свойства типа выражений
text: Math.max(root_model.left.power_percent,
root_model.right.power_percent,
root_model.bottom.power_percent) + "%"
Диайнером не пользовался, писал qml руками.
Qt внутри подписывается на сигналы изменения свойств, причём на всех уровнях - то есть и на изменение свойства root_model.left и на свойство root_model.left.power_percent. Пересчитывает+перерисовывает только тот кусок, который соотвествует событиям изменения - при этом логике приложения достаточно изменить Qt-свойство в соотвествии его протоколом.
Я писал на QtQuick только одно приложение, запускал на Rpi3 1GB (linux + тачскрин 800x600). После запуска фигачило 60FPS, тормозов не было.
Минус был найден только один - довольно долгий старт, порядка 15 сек. Второй минус - некоторые вкусные компоненты не под LGPL. Кроме этих двух - минусов не увидел.
Плюсы:
- тестируемый и отвязанный от вообще GUI-классов код на С++
- Не содержащий бизнес-логики (говно)код на QML, который общается с view-моделью через строго определённое API, то же которое покрывается тестами. Он говнокод, но внутренние инварианты модели нарушить не сможет.
- Сигналы об изменении свойств дают идеальную логику обновления: - не надо явным оразом писать «GUI перечитай такое-то свойства, я тут что-то поменял» - такая подписка делается автоматом. В GUI пересчитывается-перерисовыается ровно то что менялось, ничего другого для обеспечения такого поведения количество танцев с бубном очень умеренно - достаточно аккуратно использовать Qt-Property (примитивная макро-шаблоно-магия над C++)
Вцелом - по соотношению сроки/количество_багов/удобство_использования_результата я остался очень доволен qt quick (по сравнению с QtWidgets, а также WPF и WinForms на винде).