[РЕШЕНО] Программная разработка доски Судоку

[gil9red]

ufna, красиво выглядит
groupbox полно=) если не ошибаюсь и для поля игры тоже groupbox используется)
точнее, поле игры внутри groupbox находится)
и поле создается через переопределенный paintEvent?)

[Igors]

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

[gil9red]

Igors, и размещать эти самые виджеты с помощью layout?

[gil9red]

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

[ufna]

ufna, красиво выглядит
groupbox полно=) если не ошибаюсь и для поля игры тоже groupbox используется)
точнее, поле игры внутри groupbox находится)
и поле создается через переопределенный paintEvent?)

поле игры рисуется целиком вручную в пейнт эвенте, включая "рамочку". Групбоксы там только для меню.

[gil9red]

Понятно, но если делать вручную судоку то при рисовании поля проблем не возникнет, зато далее будет очень весело: нажатую ячейку нужно выделить, для этого поле разделяем в виде сетки, отлавливаем куда тыкнул пользователь, зная координаты, выясняем на какую ячейку он попал, потом можно и нужно для ячейки подобрать значение (в судоку каждая ячейка имеет значение от 1-9), значит тоже самое что и с определением ячейки по координатам. Если мы захотим изменить размер окна, тут будет проще - используя метод scale() рисовальщика, и зная ширину/высоту окна, можем это осуществить
Но я не сторонник самоистезаний, если есть другой путь, хотя и сам не уверен, что другой путь приведет к цели, но этот способ гарантирует полный контроль над полем и возможность сделать на нем все что придумается

[ufna]

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

а так есть еще GVC 

но на самом деле.. см. ответ Igors. делай виджеты, накидай их на лейаут и все. Самый быстрый и грубый путь.

[Igors]

Igors, и размещать эти самые виджеты с помощью layout?

А чего нет?

..зато далее будет очень весело: нажатую ячейку нужно выделить, для этого ..

Да, есть такие заботы, но они не так уж велики, рисовать все одном paint имеет свои преимущества.

[Bepec]

Блин >.<

Какие все умные. Вроде и QPainter с полной отрисовкой приплели.
Да ещё и посоветовали виджетов накидать тупо(штук 200/300 получится).

Вот этого я не понимаю. Чем плох TableView?

По отрисовке - тот же самый QPainter.
По скорости изменения (допустим перемещение ячеек и прочая) гораздо быстрее и удобнее самописного паинтера.
200-300 виджетов - а памяти у вас мало скушается? Или много? Или без разницы?

Помоему View (любой) как раз подходит для этих целей. Вручную отрисовывать конечно хорошо, но... В любом случае у вас получится model-view, который будет брать данные  и отрисовывать в соответствии.

И тут уже вопрос гибкости встаёт. Камбала же вроде за гибкость (по теме "MoveToThread" сужу).
Гибкости со своим Паинтером - никакой. Каждая правка - правка всей структуры. К тому времени уже запутанной.
А придёт всё к чему? К разделению отрисовки и данных. Вот и model-view.

PS

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

- Ответь Igors пожалуйста на вопрос, что лучше - 200-300 виджетов в группе, или 1 model-View?

[kambala]

Камбала же вроде за гибкость (по теме "MoveToThread" сужу).

я в темах про потоки вообще не пишу (или в этой писал?..). а тут я за таблицу как за доступное решение "из коробки".

[ufna]

9х9 вроде как 81 виджет, откуда 200-300?

отрисовка в пеинтере имеет свои плюсы, не всегда модел/вью "встроенные" подходят. Но это уже для отдельной темы разговор.

[Bepec]

2ufna - Для познавательной работы с Qt нужен и painter и model-View.

К сожалению я про судоку знаю мало. Там разве поле не может быть больше?

В последнее время появились модификации большего размера, чем 9 на 9 клеток. Например, существуют судоку с размерами 12×12 или даже 16×16, предназначенные для опытных игроков.

Table гибче и манёвреннее. Можно на лету менять. И самое то на таком примере изучить Model-View. А уж потом оно точно пригодится

[Krysk]

Я помню на Qt3 текстовый редактор делал каждую буковку сам отрисовывал, а также: выделение, подсветка синтаксиса и п.р... собственный QTextEdit;)

Сейчас я предпочитаю использовать qml + QGraphicsScene жаль что нокиа тормозят c qt ведь кодить на qml в 100500 раз дешевле и проще чем с хмл + java в том же андроид

[Igors]

Ответь Igors пожалуйста на вопрос, что лучше - 200-300 виджетов в группе, или 1 model-View?

Model-view это всего лишь разделение UI и структур данных. Это можно обеспечить и с массивом виджетов и с рисованием в paint. Не вижу что выигрывается при таблице если данные статичны - наоборот, забот только больше. Хотя впрочем - дело вкуса

[Bepec]

Я как то попробовал создать таблицу в 400 на 400 ячеек и групбокс 400 на 400 label. Лейблы тормозили ужасно. Таблица спокойно работала.
Model-View не только разделение ui. Там получается 1 виджет (ну пусть 3), с параметрами отображения. А 200-300 виджетов со всеми их параметрами и характеристиками и ненужными в данном случае возможностями проигрывают во всём. Скорости отображения, занимаемой памяти и прочему.

Я бы сказал, что выбор у автора (если он хочет) есть между painter'ом и Model-View. И в том, и в этом случае получится model-View. В 1 случае рукописная. Во 2 случае уже готовая, "из коробки".