Японские кроссворды на QtQuick

[Antervis]

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

[RPG18]

У меня возникли небольшие трудности с предметной областью, если пользоваться определением из вики

Изображения зашифрованы числами, расположенными слева от строк, а также сверху над столбцами.

Но выкрутится в принципе можно.

[Antervis]

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

[RPG18]

Сейчас понимаю, что можно сделать все через одну модель. Если буду делать не прототип, то сделаю через модель.

[QtRoS]

Добрый день, несколько замечаний по статье:
1. Обычно в статье присутствует вывод, общие впечатления и т.д.
2. Не очень эффективно делать так:

height: parent.height
width: parent.width

В данном случае это байндинги (кстати, оптимизируемые QV4 из-за простоты), anchors быстрее — для повторяющихся элементов и делегатов может быть важно.
3. Когда модель большая, очень полезно писать не просто имя свойства в модели (роли), а добавлять слово model, например «model.index» вместо «index». Так явно показывается, что данные берутся из модели, а не какой-то одноименной переменной в сущности.
4. Контрол подобный

Text {
                        text: qsTr("Author")
                        font.family: hanZiFont.name
                        font.pixelSize: view.labelFontPixelSize
                    }

Используется во многих местах, например 7 раз в Nonogram.qml. Было бы целесообразно выделить его в отдельный компонент, чтобы было легче поддерживать и не нарушать старый добрый DRY.

В целом получилось неплохо.

[RPG18]

Полностью с вами согласен, но пока производительность не беспокоит(если есть аппаратное ускорение OpenGL в драйверах видеокарты), но стал изучать QML Profiler. Это прототип и код еще не раз поменяется. Сейчас ставлю цели:

• завести на своём планшете с Arndoid;
• поиграться с версткой под ретиной;
• поковырять пресловутый material design в связке с Qt Labs Controls.

[BlackRaven86]

2. Не очень эффективно делать так:

height: parent.height
width: parent.width

В данном случае это байндинги (кстати, оптимизируемые QV4 из-за простоты), anchors быстрее — для повторяющихся элементов и делегатов может быть важно.

Кстати, не всегда. Если размеры должны часто меняться, то да. Например, для фона окна хорошо подходит (если размер окна можно менять, конечно). А вот размер itmTxt зависит от ceilSize и не меняется в процессе работы, так что тут позиционировать про помощи width, height, x и y совершенно нормально. Использование якорей создает дополнительные объекты, поэтому стоит их использовать тогда, когда размер элемента должен часто меняться. Документация.