QGraphicsScene and QGraphicsWidget (reusable and embeddable)

[wysota]

it is just about the graphical representation, the piece (the qobject you are proposing) itself will take care of the logic and of updating this "pawn" within the manager

It should work the other way round. The manager knows the logic of the game, it can delegate some of its resposibility to another object (which can happen to be the visual item drawn on the board but it doesn't have to be) but still the manager is in control of everything. If we continue with the chess parallel - if you want to add a new type of piece to the game then of course the logic of the piece can be tied to the component implementing the looks of the piece but it is still the game engine that asks a particular piece for possible destinations, determines the legality of each of them in the current game state and finally asks the piece to make the move. If you decentralize the logic (as if I correctly understand that that's what you propose) then you have dozens of places that you have to coordinate, dozens of places where something can go wrong, etc. Even if we consider your approach as a sort of an "agent-like" solution then there still has to be an agent controlling the game logic and the agent would be the manager.

How?

In general through QGraphicsLayoutItem API.

QGraphicsWidget *w = new QGraphicsWidget;
QGraphicsGridLayout *l1 = new QGraphicsGridLayout;
w->setLayout(l1);
QGraphicsGridLayout *l2 = new QGraphicsGridLayout;
l1->addItem(l2, 0, 0);
// ...
QGraphicsWidget *w2 = new QGraphicsWidget;
QGraphicsGridLayout *l21 = new QGraphicsGridLayout;
w2->setLayout(l21);
QGraphicsGridLayout *l22 = new QGraphicsGridLayout;
l21->addItem(l22, 0, 0);
// ...

QGraphicsWidget *w = new QGraphicsWidget;
QGraphicsGridLayout *l1 = new QGraphicsGridLayout;
w->setLayout(l1);
QGraphicsGridLayout *l2 = new QGraphicsGridLayout;
l1->addItem(l2, 0, 0);
// ...
QGraphicsWidget *w2 = new QGraphicsWidget;
QGraphicsGridLayout *l21 = new QGraphicsGridLayout;
w2->setLayout(l21);
QGraphicsGridLayout *l22 = new QGraphicsGridLayout;
l21->addItem(l22, 0, 0);
// ...

To copy to clipboard, switch view to plain text mode 

[OriginalCopy]

It should work the other way round. The manager knows the logic of the game, it can delegate some of its resposibility to another object
[/code]

Yes, this "another object" is the one I want to implement and make reusable.

[wysota]

The API of this "another object" is strictly tied to the logic of the game. It will be different for chess and different for say... civilization clone.

For chess I would define something like:

class ChessPieceLogic {
public:
  virtual ~ChessPieceLogic(){}
  virtual QList<QPoint> possibleMoves(const QPoint &from, const BoardState &state) const = 0;
  virtual QList<QPoint>attackedFields(const QPoint &from, const BoardState &state) const = 0;
  virtual isValidMove(const QPoint &from, const QPoint &to, const BoardState &state) const = 0;
  virtual bool isUnderAttackBy(const QPoint &source, const QPoint &target) const; // to check for check/mate
  virtual QList<QPair<QPoint,QPoint> > makeMove(const QPoint &from, const QPoint &to, const BoardState &state) const = 0; // to allow en passant and castles
  virtual void commitMove(const QPoint &from, const QPoint &to) = 0;
};

class ChessPieceLogic {
public:
  virtual ~ChessPieceLogic(){}
  virtual QList<QPoint> possibleMoves(const QPoint &from, const BoardState &state) const = 0;
  virtual QList<QPoint>attackedFields(const QPoint &from, const BoardState &state) const = 0;
  virtual isValidMove(const QPoint &from, const QPoint &to, const BoardState &state) const = 0;
  virtual bool isUnderAttackBy(const QPoint &source, const QPoint &target) const; // to check for check/mate
  virtual QList<QPair<QPoint,QPoint> > makeMove(const QPoint &from, const QPoint &to, const BoardState &state) const = 0; // to allow en passant and castles
  virtual void commitMove(const QPoint &from, const QPoint &to) = 0;
};

To copy to clipboard, switch view to plain text mode 

[OriginalCopy]

Yes, but drawing this "other object" and the objects inside it, manipulating those visual representations, reacting to UI events, will be handled (and forwarded) by this "other object". This "other object" is "the grid" i was talking about in post #1, and needs to have the features I've mentioned.

Now, have we cleared up any misunderstanding?

Do you (finally) have a real, constructive suggestion about THIS specific issue, without walking me through all the irrelevant things about this entire gaming platform? Because frankly, my problem is a QT issue, and not an overall design issue.

It would be great if you could help me with that, instead of divagating.

I do appreciate your input so far, but I would appreciate even more an on-topic discussion.

[wysota]

Because frankly, my problem is a QT issue, and not an overall design issue.

Frankly your problem is a design issue and not Qt issue. If you had a clear design, you'd immediately know how to implement it. So far either you don't have a clear design of what you want to do or you can't present/explain the design because you still haven't answered the question how your grid differs from QGraphicsGridLayout. It seems you have some general ideas but no specifics.

I do appreciate your input so far, but I would appreciate even more an on-topic discussion.

I think what I'm saying is as much on-topic as you can get.

Let's go through what you have written again:

drawing this "other object" and the objects inside it

When it comes to Graphics View then: 1) items draw themselves and 2) the "scene" has no visual representation. You're trying to force the "grid" to be an item where clearly there are many cases where it is either not desired or not possible.

, manipulating those visual representations,

If by that you mean scaling/rotating then the scene takes care of that, possibly supported by the animation framework and QGraphicsTransform if needed.

reacting to UI events,

This is already in the graphics view framework as well.

will be handled (and forwarded) by this "other object".

So far this "other object" seems like the scene to me.

This "other object" is "the grid" i was talking about in post #1, and needs to have the features I've mentioned.

It's already in the framework and works out of the box as you'd expect it. The scene captures events for the items and forwards them to the items so that they can handle them, the scene can layout items in a grid (or whatever else structure you want), it can visually transform them and it delegates painting to the items. So what's exactly wrong with this behaviour that you wish to change it?