Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

QGraphicsScene/View interaction architecture



  • I have a question about how to architect a dependency between a QGraphicsScene and QGraphicsView. It does not help that I am little confused because QGraphicsScene is not just a "model" for standard model/view architecture, it has a lot of similar functions to GraphicsView but not all.

    The program has a single QGraphicsView onto the QGraphicsScene. The view knows about the scene, but the scene does not know about the view. The QGraphicsScene is saved to/restored from file (by my own code).

    I had to implement zooming, and this has to be done via the QGraphicsView::transform(). It has to be done that way, because although QGraphicsScene has many view-type methods like the view, it does not do transform.

    Now, for right or for wrong, the stakeholder has decided that the current zoom is to be saved/restored as part of the scene (a given saved scene will have an associated zoom level). My problem then is reading the zoom for save and restoring the zoom for load. That is happening in QGraphicsScene, which cannot call methods directly in my QGraphicsView.

    I can't use a signal from scene to get a result from view. I can use a signal from scene to inform view of something. So the only way I can see that I can architect is:

    1. In the QGraphicsView code which handles zooming (changing the transform), I must call a method in (or send a signal to, doesn't matter) the scene which tells it what the latest zoom level. This can then store a variable in the scene, so it can be serialized/saved.

    2. In the QGraphicsScene code which handles deserializing/loading, invent a new "reset"/"loaded" signal (there doesn't seem to be one in Qt code) which the view can then slot onto, so that it knows when to reset its zoom in response to the new scene zoom desired.

    Does this sound right?!


  • Lifetime Qt Champion

    Hi,

    You should keep these two things separated. Save what is related to scene in the context of the scene and what's for the view in the context of the view.

    Then, on startup, load the scene settings and once that done, load the view settings. This has the advantage that if you add a secondary view, it won't be affected by the settings of the other view.


  • Lifetime Qt Champion

    Hi,

    You should keep these two things separated. Save what is related to scene in the context of the scene and what's for the view in the context of the view.

    Then, on startup, load the scene settings and once that done, load the view settings. This has the advantage that if you add a secondary view, it won't be affected by the settings of the other view.



  • @SGaist
    Thanks. It gets complicated. Python dump/load() insists on a single object to serialize/deserialize. The boundary between what is scene vs view gets blurred. I was only intended to have one "settings" section in the file, this particular setting refers to a Qt view, others will be properties of the scene/model. The stakeholder sees the zoom level as an attribute of the scene/model, in that certain ones will require higher magnification than others inherently, rather than it just being a user preference.

    But I will have another think tomorrow about taking the save file scope out so it encompasses scene and view separately.


  • Lifetime Qt Champion

    Sounds a bit like the save/restoreGeometry functionality of QMainWindow.

    You could add some more fields that tells to what widget these settings apply.


Log in to reply