QGraphicsScene and QGraphicsWidget (reusable and embeddable)

[OriginalCopy]

I don't want to put limits on the end user (the game developer). Are you suggesting that the whole widget should best be a QGraphicsScene, and the user could hook in by either using signals and slots, or by subclassing?

Addendum: perhaps the grid itself is only one thing in the entire scenery. perhaps the scenery of the game he's developing requires more than one grid.

That's why I think the widget itself should be part of the scenery, not the scene itself.

[wysota]

QGraphicsScene is not a widget.

You say you don't want to put limits on game developers. But you need to expose some abstract API and this in turn will put limits on them whether you want it or not. So my question is what do you want to add to QGraphicsScene that it doesn't already have? If all you want is to add some kind of "layout" then subclass QGraphicsScene and add virtual methods similar to what QAbstractItemView has -- indexAt() and visualRect(). This will allow your users to implement custom mappings between indexes (i.e. the grid) and items in the scene. Although from the technical point of view this is not necessary as the scene coordinate system can already map grids by itself. How you display it afterwards is a different issue.

[OriginalCopy]

When I said "my grid should sit on the scenery" I ment the child-parent-relationship: my grid widget will have as parent the QGraphicsScene. It should not be a subclass of QGraphicsScene for the reasons I've mentioned above.

QGraphicsScene is not a widget.

I know and I have never said that.

[wysota]

my grid widget will have as parent the QGraphicsScene

Very unlikely as widgets can't have non-widgets as parents.

It should not be a subclass of QGraphicsScene for the reasons I've mentioned above.

Could you point out those reasons again? I don't see anything in what you have written so far that would make subclassing the scene a bad idea.

[OriginalCopy]

I've put it in the title because it's very important: "(reusable and embeddable)" - the grid should be a reusable widget, easy to embed into any scene, even in large number (one scene contains more "grids").

The natural way of working would be:

- create new QGraphicsScene
- create several new MyGrids
- create some new "objects" (they would be basically QObject subclasses, with some extra features) via bit matrices for each
- put those several new MyGrids on the scene

MyGrid would be the class representing the concept of "grid" I've talked about in post #1. It has as children some rectangles managed in turn by a layout (default: QGraphicsGridLayout) for the reasons I've also mentioned in post #1.

The question is just: What should MyGrid subclass, such that I can reuse as much as possible of the features already existing qt classes provide, to let the user (the real game developer) easily create and manipulate several MyGrid instances as his game requires.

I hope it's clear now.

[wysota]

I've put it in the title because it's very important: "(reusable and embeddable)" - the grid should be a reusable widget, easy to embed into any scene, even in large number (one scene contains more "grids").

So you don't want a widget but rather an item. Or maybe subclasses of QGraphicsLayout.

The question is just: What should MyGrid subclass, such that I can reuse as much as possible of the features already existing qt classes provide, to let the user (the real game developer) easily create and manipulate several MyGrid instances as his game requires.

QGraphicsLayout or one of its subclasses, most probably. Although I less and less see what would such grid be useful for and how would it differ from QGraphicsGridLayout.

[OriginalCopy]

First of all it must be a QGraphicsItem, because:

QGraphicsScene::addItem ( QGraphicsItem * item )

QGraphicsScene::addItem ( QGraphicsItem * item )

To copy to clipboard, switch view to plain text mode 

QGraphicsLayout does not seem to be a subclass of QGraphicsItem.

Although I less and less see what would such grid be useful for and how would it differ from QGraphicsGridLayout.

It's about the "little extra" I haven't dived into.

So, can anyone make a real,feasible suggestion, without throwing with classnames at me, please?

[wysota]

First of all it must be a QGraphicsItem, because:

QGraphicsScene::addItem ( QGraphicsItem * item )

QGraphicsScene::addItem ( QGraphicsItem * item )

To copy to clipboard, switch view to plain text mode 

QGraphicsWidget *w = new QGraphicsWidget;
w->setLayout(new MyGridLayout);

QGraphicsWidget *w = new QGraphicsWidget;
w->setLayout(new MyGridLayout);

To copy to clipboard, switch view to plain text mode 

So it doesn't have to be a QGraphicsItem.

It's about the "little extra" I haven't dived into.

Then maybe you shold dive into it first before you start thinking what class to derive from. There is a really simple question here which you have to answer - what is the thing you are designing to do that QGraphicsGridLayout doesn't already do?

[OriginalCopy]

QGraphicsWidget *w = new QGraphicsWidget;
w->setLayout(new MyGridLayout);

QGraphicsWidget *w = new QGraphicsWidget;
w->setLayout(new MyGridLayout);

To copy to clipboard, switch view to plain text mode 

So it doesn't have to be a QGraphicsItem.


Then maybe you shold dive into it first before you start thinking what class to derive from. There is a really simple question here which you have to answer - what is the thing you are designing to do that QGraphicsGridLayout doesn't already do?

Specifying objects inside the grid (e.g. a "battleship") via matrices, positioning/rotating those objects on the grid (which are graphically represented as a collection of rectangle objects), receiving signals from these objects (e.g. "battleship") instead of the individual reclangles battleships are made of.

So yeah, the grid layout looks like a good candidate, except ... you cannot put more of these on the scene.

The whole thing is for a gaming platform, so it's imperative to have one "widget" which can be manipulated as a standalone entity (friendliness for game developers, one unique API - at some point I may well want to expose this component to scripting languages like python, so it really has to be one object which can be put on the scene).

[wysota]

Specifying objects inside the grid (e.g. a "battleship") via matrices, positioning/rotating those objects on the grid (which are graphically represented as a collection of rectangle objects), receiving signals from these objects (e.g. "battleship") instead of the individual reclangles battleships are made of.

You can do that via any QObject, it doesn't have to be tied to QGraphicsScene in any way hence my original question - what is the rationale behind binding yourself with QGraphicsScene. The fact that a "battleship" is implemented using graphics items (or not) is completely irrelevant. What is relevant is that it emits some signals and has some slots. These will be different for each game so I don't see how your "grid" fits in here. Furthermore usually "pieces" are not standalone objects but are controlled by some kind of engine. Consider chess - you have a board which is a matrix of game pieces. You can move the pieces on the board and capture pieces with other pieces. Yet it is the board (the engine) that decides whether a particular move is legal, where each item is to be positioned, etc. Such items will not emit signals or contain slots as the whole logic is in the engine and not the item.

So yeah, the grid layout looks like a good candidate, except ... you cannot put more of these on the scene.

Hmm? You cannot put more of what on the scene? grid layouts? Why not? You can place as many of them as you want.

The whole thing is for a gaming platform, so it's imperative to have one "widget" which can be manipulated as a standalone entity (friendliness for game developers, one unique API - at some point I may well want to expose this component to scripting languages like python, so it really has to be one object which can be put on the scene).

According to my experience in games, boards and things like that, what you call a "widget" I would call a "manager" and I would not make it a visual item (widget, graphics item, whatever). It would just manipulate visual items. A game of chess is a game of chess regardless if you display the board somewhere or not. With what you are trying to do, you'd have to display the board, otherwise you wouldn't have the board at all. That's hardly a universal approach. In my opinion you are looking for something like this:

class BoardItem : public QObject {
  Q_OBJECT
public:
  BoardItem(BoardEngine *);
  virtual ~BoardItem() = 0;
  void setPos(const QPoint &);
  QPoint pos() const;
signals:
  void positionChanged(QPoint);
};
 
class BoardEngine : public QObject {
  Q_OBJECT
public:
  void setSize(int w, int h);
  void setItem(int x, int y, BoardItem *item);
signals:
  void itemPositionChanged(BoardItem*);
};

class BoardItem : public QObject {
  Q_OBJECT
public:
  BoardItem(BoardEngine *);
  virtual ~BoardItem() = 0;
  void setPos(const QPoint &);
  QPoint pos() const;
signals:
  void positionChanged(QPoint);
};

class BoardEngine : public QObject {
  Q_OBJECT
public:
  void setSize(int w, int h);
  void setItem(int x, int y, BoardItem *item);
signals:
  void itemPositionChanged(BoardItem*);
};

To copy to clipboard, switch view to plain text mode 

etc.

[OriginalCopy]

Yep, I do intend to sepparate game logic from game view. What I need to be reusable is this manager, as you call it, which should be able to manage "tiles" belonging together (let's call this aggregation of tiles a "pawn") - 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 (or rather, tell the manager update it - thus I think the best place for functions to graphically manipulate "pawns" in all kind of ways is in the manager).

Hmm? You cannot put more of what on the scene? grid layouts? Why not? You can place as many of them as you want.

How?

[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