QGraphicsView and QGraphicsScene

[sajis997]

Hello forum,


I need some suggestion on when to customize which class - i mean the scenario.

When to subclass QGraphicsScene and QGraphicsView?


Thanks
Sajjad

[SixDegrees]

You should override the one which needs its functions overridden, or which you need to add your own functions and/or data to.

[Dong Back Kim]

Hello forum,


I need some suggestion on when to customize which class - i mean the scenario.

When to subclass QGraphicsScene and QGraphicsView?


Thanks
Sajjad

Hi Sajjad,

QGraphicsScene and QGraphicsView are really based on MVC (Model-View-Control) philosophy. As you may already know, QGraphicsView is conceptually a rendering implementation of QGraphicsScene so I guess it is safe to say QGraphicsScene is a Model and QGraphicsView is a View. This means, in my opinion, QGraphicsView should be extended if you want to specialize the drawing operations so you need to bit more extra than what the QGraphicsView does. On the other hand, if you need a specialized data structure or interface you may extend QGraphicsScene. However, this means you are most likely going to extend a QGraphicsScene because once you extend a QGraphicsScene, you also need to extend QGraphicsView to support the extra you added in QGraphicsScene from the sub class of QGraphicsView.

Does this make any sense to you? =)

[sajis997]

Hi Sajjad,

QGraphicsScene and QGraphicsView are really based on MVC (Model-View-Control) philosophy. As you may already know, QGraphicsView is conceptually a rendering implementation of QGraphicsScene so I guess it is safe to say QGraphicsScene is a Model and QGraphicsView is a View. This means, in my opinion, QGraphicsView should be extended if you want to specialize the drawing operations so you need to bit more extra than what the QGraphicsView does. On the other hand, if you need a specialized data structure or interface you may extend QGraphicsScene. However, this means you are most likely going to extend a QGraphicsScene because once you extend a QGraphicsScene, you also need to extend QGraphicsView to support the extra you added in QGraphicsScene from the sub class of QGraphicsView.

Does this make any sense to you? =)

Hello Dong,


Thanks for the explanation. Lets consider two examples. Diagramscene and Elastic ndoes that come along with the qtdemo.

In the diagramscene example the QGraphicsScene class has been specialized, where as in the elastic node example the QGraphicsView class has been specialized. The main difference that i see is that the elastic node rendering is very crispy , where the rendering for the diagramscene example is not so good.

Other than this is there any significant difference. How do you decouple the model and view part from each other in both the examples?


Regards
Sajjad

[Dong Back Kim]

Hello Dong,


Thanks for the explanation. Lets consider two examples. Diagramscene and Elastic ndoes that come along with the qtdemo.

In the diagramscene example the QGraphicsScene class has been specialized, where as in the elastic node example the QGraphicsView class has been specialized. The main difference that i see is that the elastic node rendering is very crispy , where the rendering for the diagramscene example is not so good.

Other than this is there any significant difference. How do you decouple the model and view part from each other in both the examples?


Regards
Sajjad

Hi Sajjad,

That's exactly what I was trying to say. In the "Diagram Scene" example, as you mentioned, QGraphicsScene has been extended because the application has to have its own "specialized" functionality that QGraphicsScene does not provide. In the "Elastic Nodes" example, again as you mentioned, QGraphicsView has been extended because the application has to show "specialized" graphics outcome or user interactions that QGraphicsView does not provide.

By the way, it is not really relevant to claim that elastic node application's graphical quality is better simply because it has extended the QGraphicsView. It is better because it has better rendering implementation. In other words, you can make it have "worse" graphics with a sub class of QGraphicsView (although no one would ever do I reckon). I guess this leads us back to the No. 1 question in Object Oriented Programming. "When do we extend a class?" This is a really big question and I'm afraid I don't have a ultimate answer for the question. In general, I extend a class when things gets too specialized and prevent the re-usability of a class.

For your question, how to decouple Model and View... that is a kind of an software architecture related question. If I dare to answer your question, I guess they are already decoupled in the first place. That's the bottom line of using MVC concept. Model-View-Control classes are all independent (although most of cases it's not entirely true in real world...) I guess Model should never know about View because it has to be absolutely independent from View. This ways a Model can be used by any Views on demands. It's solely up to the Views using the Model how they are going to render. Therefore, I'm not sure whether we can call this as they are "decoupled" because it sounds like in both way they are independent. However, if View is independent from the Model... I think it sounds bit weird because it means the View will never be able to render a Model properly since different Model will have different members.

I guess this discussion would never end =) I'm a kinda guy who doesn't really picky on software architecture and design as long as the software works but we should think of why we keep indenting the source codes. It tells us something doesn't it? I really hope any of above I wrote helps you anyhow.

Regards,

[sajis997]

Thanks Dong,

Thanks for the explanation. I am still having trouble to get my head around the issue.

Both the class has the mouseMoveEvent, mousePressEvent, mouseReleaseEvent that can be over-ridden.

I am still having trouble to how to decide when to decide if i need to subclass QGraphicsScene or QGraphicsView. So far i undestand QGraphicsView just visualize the part of the scene - provides the scrollbar support.


Ok Let me say , what i want to achieve. I am studying an API where they have subclassed the QGraphicsView. It is possible to drag graphics item into the view . Now I wan to connect two items with an arrow. The arrow is only drawn when the mouse is moved from one item to the other item while the Ctrl button is down. Now i think that i have to over-ride the mouseMoveEvent with the modifiers() . What do you think?

To achieve this do i have to subclass QGraphicsScene as well or it will be fine if i over-ride the mouseMoveEvent() function in the QGraphicsView subclass - which is already done.

Looking forward to some feedback on this issue.


Regards
Sajjad

Hi Sajjad,

That's exactly what I was trying to say. In the "Diagram Scene" example, as you mentioned, QGraphicsScene has been extended because the application has to have its own "specialized" functionality that QGraphicsScene does not provide. In the "Elastic Nodes" example, again as you mentioned, QGraphicsView has been extended because the application has to show "specialized" graphics outcome or user interactions that QGraphicsView does not provide.

By the way, it is not really relevant to claim that elastic node application's graphical quality is better simply because it has extended the QGraphicsView. It is better because it has better rendering implementation. In other words, you can make it have "worse" graphics with a sub class of QGraphicsView (although no one would ever do I reckon). I guess this leads us back to the No. 1 question in Object Oriented Programming. "When do we extend a class?" This is a really big question and I'm afraid I don't have a ultimate answer for the question. In general, I extend a class when things gets too specialized and prevent the re-usability of a class.

For your question, how to decouple Model and View... that is a kind of an software architecture related question. If I dare to answer your question, I guess they are already decoupled in the first place. That's the bottom line of using MVC concept. Model-View-Control classes are all independent (although most of cases it's not entirely true in real world...) I guess Model should never know about View because it has to be absolutely independent from View. This ways a Model can be used by any Views on demands. It's solely up to the Views using the Model how they are going to render. Therefore, I'm not sure whether we can call this as they are "decoupled" because it sounds like in both way they are independent. However, if View is independent from the Model... I think it sounds bit weird because it means the View will never be able to render a Model properly since different Model will have different members.

I guess this discussion would never end =) I'm a kinda guy who doesn't really picky on software architecture and design as long as the software works but we should think of why we keep indenting the source codes. It tells us something doesn't it? I really hope any of above I wrote helps you anyhow.

Regards,

[Dong Back Kim]

Ok Let me say , what i want to achieve. I am studying an API where they have subclassed the QGraphicsView. It is possible to drag graphics item into the view . Now I wan to connect two items with an arrow. The arrow is only drawn when the mouse is moved from one item to the other item while the Ctrl button is down. Now i think that i have to over-ride the mouseMoveEvent with the modifiers() . What do you think?

That sounds reasonable to me.

To achieve this do i have to subclass QGraphicsScene as well or it will be fine if i over-ride the mouseMoveEvent() function in the QGraphicsView subclass - which is already done.

I guess it depends on whether you want to have specialized data in your scene. If you are absolutely sure you are not going to modify your scene but just extend your view then I guess subclassing QGraphicsScene is not necessary. Having said that I think it's not too late if you subclass the QGraphicsScene when you need to I guess sometimes it is better to kick off the journey to figure out which way you are going rather than sitting in the room and falling into the endless worrying and "what-if" questions.

Regards,