QGraphicsScene and QGraphicsWidget (reusable and embeddable)

[OriginalCopy]

I should start by saying I've tried to look at this problem from all POVs. I've also asked on freenode and I was suggested some things, yet in the end it turned out those suggestions could not possibly work.

It looked to me as though those making suggestions don't really know how the class hierarchy and the concepts hierarchy looks like.

That being said, I haven't used Qt for years, so please bear with me.

What I want to make is a graphics item (QGraphicsWidget,...Item, whatever, I don't know what class it should inherit from) that can sit on the scenery QGraphicsScene.

Imagine you wanted to create a reusable component for grid-based games like battleship.

New objects (like a battleship) within this widget could be represented as bit matrices and created/inserted on the fly.

The building blocks themselves (filled QGraphicsRectItem or "empty" ones) inside it should be managed by a layout class. As a default could serve QGraphicsGridLayout, but it should allow plugging in a custom layout. This would allow new 2D layouts, like isometric.

Having a layout inside the widget would also simplify game development on top of this widget, as you'll have methods itemAt() and layers to organize the objects on the "grid".

And remember, the widget itself can sit inside the scenery.

So which concepts (grid widget, grid block, grid layout) should inherit from which qt4 (4.7.2) classes?

Note: already exiting classes/frameworks/whatever are also OK, but keep in mind I don't want to have to distribute libraries thicker than 3-4 Mb for windows users.

[wysota]

What's the rationale behind using QGraphicsScene in this case? To me it seems the grid based model-view approach seems suitable here. Of course you can merge the two or build your own model-view architecture on top of graphics view but maybe you don't have to. Tell us what exactly do you expect from this framework functionality-wise.

[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).