[Interest] Questions about QGraphicsWidget

[BRM]

I'm working on a QGraphicsWidget version of something I already have a QWidget version of; namely because I need to add some features where I need to overlay items, lines, and text in a way that QWidget does not support (namely the addition of the text information) - presently I'm just focused on getting to the point of equivalence with what I had under QWidget.  In doing so I have taken my one QWidget and converted it into a series of QGraphicsWidgets, and added a parent QGraphicsWidget that will contain at most two of the sub-widgets - the data being drawn, and its ideal overlay. (I originally had just one QGraphicsWidget but found it simplified things if I split stuff out. I figured this would be an advantage since I can overlay stuff in QGraphics* where I could not under QWidget.)


Question #1: The parent widget has two widgets within it. At this time I'm not using a QGraphicsLayout of any sort as none seem to match doing the overlay I need - that is, the two widgets will be in different Z-levels (1 and 2), and if both are visible then they will be nearly the same coordinates in their parent coordinate system. Or am I missing something and this would be supported by one of the existing QGraphicsLayouts? Do I really even need a QGraphicsLayout to manage these, or is there a simpler way to do it? I'm thinking the geometry would be that of the farthest extremities of the combination of the two widgets when both are visible, or just the one widget when only one is visible. The parent widget will likely sit in a QGraphicsLayout of some sort when I am done.


Question #2: I'm having an issue with scaling of the drawing. If I understand QTransform::scale() correctly, then it maps the coordinates being used from one coordinate system to another. I am trying to keep the drawing within the boundaries of the widget itself, but using the boundingRect().contains(pointToDraw) does not keep any points from being drawn when the leave the boundingRect(). I didn't have to worry about this with QWidget as QWidget clipped what was being drawn (or at least displayed) on the boundaries of the widget; while QGraphicsWidget doesn't do that - it'll gladly leave artifacts. Am I missing an easy way to keep it from leaving artifacts?

TIA,

Ben

[Bill Crocker]

Post by BRM
I'm working on a QGraphicsWidget version of something I already have a QWidget version of; namely because I need to add some features where I need to overlay items, lines, and text in a way that QWidget does not support

You can also overlay your existing widget with another widget
on which you draw arbitrary text and lines.
Set the overlay widget as transparent to mouse events.

Bill

Post by BRM
http://lists.qt-project.org/mailman/listinfo/interest

[Bo Thorsen]

Post by Bill Crocker

Post by BRM
I'm working on a QGraphicsWidget version of something I already have a QWidget version of; namely because I need to add some features where I need to overlay items, lines, and text in a way that QWidget does not support

You can also overlay your existing widget with another widget
on which you draw arbitrary text and lines.
Set the overlay widget as transparent to mouse events.

This was exactly what I was about to answer. Going to QGW is the wrong
approach for this problem. Unless of course there are other reasons for
doing it. But it sounds like the OP is only converting to QGW to do this
one thing.

You can create any QWidget with the top widget as parent and call
raise() to bring it to the front of the other widgets. That will give
you an overlay widget inside the window.

For overlays, I usually do this:

setAttribute(Qt::WA_TranslucentBackground);
setFocusPolicy(Qt::NoFocus);

in the constructor.

Bo Thorsen,
Fionia Software.

[BRM]

Subject: Re: [Interest] Questions about QGraphicsWidget

Post by Bill Crocker

Post by BRM
I'm working on a QGraphicsWidget version of something I already
have a QWidget version of; namely because I need to add some features where I
need to overlay items, lines, and text in a way that QWidget does not support

You can also overlay your existing widget with another widget
on which you draw arbitrary text and lines.
Set the overlay widget as transparent to mouse events.

This was exactly what I was about to answer. Going to QGW is the wrong
approach for this problem. Unless of course there are other reasons for
doing it. But it sounds like the OP is only converting to QGW to do this
one thing.

Besides picking up the additional performance? Updating to the new APIs?
Being able to eventually move to integrating with QML (if and when QML becomes an option)?

Yes there are other reasons for doing the conversion. This is just the only aspect that I've had trouble with.

You can create any QWidget with the top widget as parent and call
raise() to bring it to the front of the other widgets. That will give
you an overlay widget inside the window.
    setAttribute(Qt::WA_TranslucentBackground);
    setFocusPolicy(Qt::NoFocus);
in the constructor.

An interesting idea, but how then do I map specific points within the original widget (which has internal scaling, matrix tranformations, drag 'n drop movement of the drawn data, etc) to the QGraphicsScene?
I need to draw lines to specific coordinates within the widget if I were to do that; and based on how it draws I doubt that's possible.

Please correct me if I'm wrong.

Ben

[Bo Thorsen]

Post by BRM

Subject: Re: [Interest] Questions about QGraphicsWidget

Post by Bill Crocker

Post by BRM
I'm working on a QGraphicsWidget version of something I already
have a QWidget version of; namely because I need to add some features where I
need to overlay items, lines, and text in a way that QWidget does not support

You can also overlay your existing widget with another widget
on which you draw arbitrary text and lines.
Set the overlay widget as transparent to mouse events.

This was exactly what I was about to answer. Going to QGW is the wrong
approach for this problem. Unless of course there are other reasons for
doing it. But it sounds like the OP is only converting to QGW to do this
one thing.

Besides picking up the additional performance? Updating to the new APIs?
Being able to eventually move to integrating with QML (if and when QML becomes an option)?
Yes there are other reasons for doing the conversion. This is just
the only aspect that I've had trouble with.

As I said, if there are other reason, then go ahead with the conversion.
My point was that you shouldn't do it just to achieve the overlay.

I've never been fond of the widgets on QGW. Maybe that's a reason I'm
showing the way to avoid it.

Bo Thorsen,
Fionia Software.

[BRM]

Subject: Re: [Interest] Questions about QGraphicsWidget

Post by BRM

Subject: Re: [Interest] Questions about QGraphicsWidget

  I'm working on a QGraphicsWidget version of something I already
have a QWidget version of; namely because I need to add some features where I
need to overlay items, lines, and text in a way that QWidget does not support

  You can also overlay your existing widget with another widget
  on which you draw arbitrary text and lines.
  Set the overlay widget as transparent to mouse events.

This was exactly what I was about to answer. Going to QGW is the wrong
approach for this problem. Unless of course there are other reasons for
doing it. But it sounds like the OP is only converting to QGW to do this
one thing.

Besides picking up the additional performance? Updating to the new APIs?
Being able to eventually move to integrating with QML (if and when QML becomes an option)?
Yes there are other reasons for doing the conversion. This is just
the only aspect that I've had trouble with.

As I said, if there are other reason, then go ahead with the conversion.
My point was that you shouldn't do it just to achieve the overlay.

As should be the case. If there's a simpler way to do things that requires less effort and achieve the same outcome, then why not?
 

I've never been fond of the widgets on QGW. Maybe that's a reason
I'm showing the way to avoid it.

I'm about split at the moment. I see a number of benefits coming through QGW; but it seems to be about even with QWigdet overall.
In part, there's just so much richness to what is available with QWidget that is simply lacking in QGW, and QGW seems to be getting a little ignored that way as focus is more on QML.
That said, it does seem to provide a nice transition from QWidget to QML too.

Now if I can just get the overlay to the right coordinates...

Ben

[Jason H]

I think you're kinda thinking about it wrong. 
First, there is QGraphicsItemGroup, which would probably do what you want, and automatically provides a boundingRect() as the unsion of all child bounding rects.

When custom drawing your item always draw it "native" resolution. let the Scene work out the scaling and scaled bounding rect. You only need to worry about yourself at 1:1 scaling.

HTH



________________________________
From: BRM <***@yahoo.com>
To: Interests Qt <***@qt-project.org>
Sent: Tuesday, August 7, 2012 12:36 PM
Subject: [Interest] Questions about QGraphicsWidget

I'm working on a QGraphicsWidget version of something I already have a QWidget version of; namely because I need to add some features where I need to overlay items, lines, and text in a way that QWidget does not support (namely the addition of the text information) - presently I'm just focused on getting to the point of equivalence with what I had under QWidget.  In doing so I have taken my one QWidget and converted it into a series of QGraphicsWidgets, and added a parent QGraphicsWidget that will contain at most two of the sub-widgets - the data being drawn, and its ideal overlay. (I originally had just one QGraphicsWidget but found it simplified things if I split stuff out. I figured this would be an advantage since I can overlay stuff in QGraphics* where I could not under QWidget.)


Question #1: The parent widget has two widgets within it. At this time I'm not using a QGraphicsLayout of any sort as none seem to match doing the overlay I need - that is, the two widgets will be in different Z-levels (1 and 2), and if both are visible then they will be nearly the same coordinates in their parent coordinate system. Or am I missing something and this would be supported by one of the existing QGraphicsLayouts? Do I really even need a QGraphicsLayout to manage these, or is there a simpler way to do it? I'm thinking the geometry would be that of the farthest extremities of the combination of the two widgets when both are visible, or just the one widget when only one is visible. The parent widget will likely sit in a QGraphicsLayout of some sort when I am done.


Question #2: I'm having an issue with scaling of the drawing. If I understand QTransform::scale() correctly, then it maps the coordinates being used from one coordinate system to another. I am trying to keep the drawing within the boundaries of the widget itself, but using the boundingRect().contains(pointToDraw) does not keep any points from being drawn when the leave the boundingRect(). I didn't have to worry about this with QWidget as QWidget clipped what was being drawn (or at least displayed) on the boundaries of the widget; while QGraphicsWidget doesn't do that - it'll gladly leave artifacts. Am I missing an easy way to keep it from leaving artifacts?

TIA,

Ben

[BRM]

Subject: Re: [Interest] Questions about QGraphicsWidget
I think you're kinda thinking about it wrong. 

You're right - I probably am. I'm quite use to QWidget still, and trying to get my head around some of the differences for QGraphics.

First, there is QGraphicsItemGroup, which would probably do what you want, and automatically provides a boundingRect() as the unsion of all child bounding rects.

An interesting idea.

I had been planning on using the QGraphicsItemGroup to capture the larger widget set with all the lines, text, and data displays; while having this widget just deal with the data and its overlay. And looking a little closer I guess I can add a group to be within another group...I'll have to look into this more.

When custom drawing your item always draw it "native" resolution. let the Scene work out the scaling and scaled bounding rect. You only need to worry about yourself at 1:1 scaling.

I'd be glad to once I can figure it out. KISS is a very good principle to live by.

Thanks,


Ben

Subject: [Interest] Questions about QGraphicsWidget
I'm working on a QGraphicsWidget version of something I already have a QWidget version of; namely because I need to add some features where I need to overlay items, lines, and text in a way that QWidget does not support (namely the addition of the text information) - presently I'm just focused on getting to the point of equivalence with what I had under QWidget.  In doing so I have taken my one QWidget and converted it into a series of QGraphicsWidgets, and added a parent QGraphicsWidget that will contain at most two of the sub-widgets - the data being drawn, and

its ideal overlay. (I originally had just one QGraphicsWidget but found it simplified things if I split stuff out. I figured this would be an advantage since I can overlay stuff in QGraphics* where I could not under QWidget.)

Question #1: The parent widget has two widgets within it. At this time I'm not using a QGraphicsLayout of any sort as none seem to match doing the overlay I need - that is, the two widgets will be in different Z-levels (1 and 2), and if both are visible then they will be nearly the same coordinates in their parent coordinate system. Or am I missing something and this would be supported by one of the existing QGraphicsLayouts? Do I really even need a QGraphicsLayout to manage these, or is there a simpler way to do it? I'm thinking the geometry would be that of the farthest extremities of the combination of the two widgets when both are visible, or just the one widget when only one is visible. The parent widget will likely

sit in a QGraphicsLayout of some sort when I am done.

Question #2: I'm having an issue with scaling of the drawing. If I understand QTransform::scale() correctly, then it maps the coordinates being used from one coordinate system to another. I am trying to keep the drawing within the boundaries of the widget itself, but using the boundingRect().contains(pointToDraw) does not keep any points from being drawn when the leave the boundingRect(). I didn't have to worry about this with QWidget as QWidget clipped what was being drawn (or at least displayed) on the boundaries of the widget; while QGraphicsWidget doesn't do that - it'll gladly leave artifacts. Am I missing an easy way to keep it from leaving artifacts?
TIA,
Ben
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

[BRM]

Subject: Re: [Interest] Questions about QGraphicsWidget

Subject: Re: [Interest] Questions about QGraphicsWidget
First, there is QGraphicsItemGroup, which would probably do what you want, and automatically provides a boundingRect() as the unsion of all child bounding rects.

An interesting idea.
I had been planning on using the QGraphicsItemGroup to capture the larger widget set with all the lines, text, and data displays; while having this widget just deal
with the data and its overlay. And looking a little closer I guess I can add a group to be within another group...I'll have to look into this more.

I actually already did that in part - that is, my parent widget is a QGraphicsWidget, and it created a QGraphicsItemGroup and added the two sub-widgets to it.
However, in examining this aspect it now seems like the parent widget has no relationship to its child widgets - e.g. moving/resizing/etc the parent is not necessarily going to moving/resizing/etc the child widgets. Or (again) am I missing something? (Yes, the QGraphicsItemGroup is parented to the QGraphicsWidget.)


Converting the parent QGraphicsWidget to be derived from QGraphicsItemGroup also removes the ability to add a nice little management layer with signals and slots; it also removes the parent widget from being able to be added to a QGraphicsLayout.

Looking to learn,
TIA,


Ben

[Jason H]

"Converting the parent QGraphicsWidget to be derived from
QGraphicsItemGroup also removes the ability to add a nice little
management layer with signals and slots; it also removes the parent
widget from being able to be added to a QGraphicsLayout."

Why and why? You might have to map a event coordinate to a client, but I don't see why that would be a problem. Either way you're not wrong though. It all depends on how much coding you want to do and how much you need to coordinate the objects.


What might work better is trying to do it in QML first, to work it out, and maybe even just use that? Without more details, I can't give better advice.




________________________________
From: BRM <***@yahoo.com>
To: Interests Qt <***@qt-project.org>
Sent: Tuesday, August 7, 2012 3:28 PM
Subject: Re: [Interest] Questions about QGraphicsWidget

Subject: Re: [Interest] Questions about QGraphicsWidget

Subject: Re: [Interest] Questions about QGraphicsWidget
First, there is QGraphicsItemGroup, which would probably do what you want, and automatically provides a boundingRect() as the unsion of all child bounding rects.

An interesting idea.
I had been planning on using the QGraphicsItemGroup to capture the larger widget set with all the lines, text, and data displays; while having this widget just deal
with the data and its overlay. And looking a little closer I guess I can add a group to be within another group...I'll have to look into this more.

I actually already did that in part - that is, my parent widget is a QGraphicsWidget, and it created a QGraphicsItemGroup and added the two sub-widgets to it.
However, in examining this aspect it now seems like the parent widget has no relationship to its child widgets - e.g. moving/resizing/etc the parent is not necessarily going to moving/resizing/etc the child widgets. Or (again) am I missing something? (Yes, the QGraphicsItemGroup is parented to the QGraphicsWidget.)


Converting the parent QGraphicsWidget to be derived from QGraphicsItemGroup also removes the ability to add a nice little management layer with signals and slots; it also removes the parent widget from being able to be added to a QGraphicsLayout.

Looking to learn,
TIA,


Ben

[BRM]

Sent: Tuesday, August 7, 2012 4:03 PM
Subject: Re: [Interest] Questions about QGraphicsWidget

Post by Jason H
"Converting the parent QGraphicsWidget to be derived from
QGraphicsItemGroup also removes the ability to add a nice little
management layer with signals and slots; it also removes the parent
widget from being able to be added to a QGraphicsLayout."

Why and why? You might have to map a event coordinate to a client, but I don't
see why that would be a problem. Either way you're not wrong though. It all
depends on how much coding you want to do and how much you need to coordinate the objects.

Amount of coding is not an issue. Obviously a smaller approach would likely be better, but I'm not afraid to get in and write a layout or something either if need be.
The objects will be linked together - they have a coordinate that must overlap, and the parent widget will need to move the one object to make them overlap.
This almost seems like something that would be ideal for a QGraphicsLayout to do - take the given geometry, move the objects around in it, and maximize them to use
as much of the geometry as possible, cliping it

What might work better is trying to do it in QML first, to work it out, and maybe even just use that?

QML is not an option at the moment, in part, as its not covered by the Qt Commercial license - its LGPL yes, but a problem for me at the moment.

Yes I could play with it, but I'm not sure it'll solve my issue in the end.

(I do intend to look at it more in the future; but it won't help with my current deliverables.)

Without more details, I can't give better advice.

I have about 6 different kinds of things to display. All share some common functionality in what is displayed; and have a similar coordinate system.
So I have one QGraphicsWidget that implements the common functionality, and a series of widgets that derive from it for each specific data set.
I need to display them in a pretty timely manner. The QWidget version can easily support 50HZ data flow, and this version will need to as well.
Realistically, it probably only actually gets to about 6 HZ in general.


Most of the kinds of things being displayed are based on network messages containing a series of points - up to ~16k points - and some additional data.
The last kind is an ideal set of what two of the network-based data should look like, and gets loaded based on that network message. The ideal data structure
being drawn is >16k points, but its drawn quickly via a drawPolygon(); the others are drawn one point at a time due to extra data with the points and I don't want all the points connected.


So I have incoming network data that gets update (Signal->Slot); I have log messages coming out (Signal); and I have several graphical objects that will need to update each other (Signal->Slot).
Most of the connections being made are internal between the various items; some are from external sources. I'd like to minimize the API that someone has to use to use the widget, so I need a wrapper widget that supports Signals and Slots. They can be easily enough grouped using QGraphicsItemGroups - at present, I'm planning two groups: (i) the data message display and its ideal display, and (ii) the fuller display with the first group and the extra items with leaders and text.


The widget represents one data source and there may be several displayed at a time so it will need to be in a layout of some sort.

At the moment, I'm trying to think about how the parent widget relates to the sub-widgets, and whether it really needs to be a widget - e.g. could I make it a QObject or QGraphicsObject? Given the layout constraint it probably does need to be a QGraphicsWidget derivative since that is the only layer that can go into a QGraphicsLayout. But then how do it relate to the QGraphicsItemGroup? Does QGraphicsItemGroup just sit separate, or does it sit inside the QGraphicsWidget that is parenting it? How does resizing fit in?

Sent: Tuesday, August 7, 2012 12:36 PM
Question #1: The parent widget has two widgets within it. At this time I'm
not using a QGraphicsLayout of any sort as none seem to match doing the overlay
I need - that is, the two widgets will be in different Z-levels (1 and 2), and
if both are visible then they will be nearly the same coordinates in their
parent coordinate system. Or am I missing something and this would be supported
by one of the existing QGraphicsLayouts? Do I really even need a QGraphicsLayout
to manage these, or is there a simpler way to do it? I'm thinking the
geometry would be that of the farthest extremities of the combination of the two
widgets when both are visible, or just the one widget when only one is visible.
The parent widget will likely sit in a QGraphicsLayout of some sort when I am
done.

I had to use different scales in the QWidget version as the different
data structures being drawn had different coordinate systems. That is
still the case; but I think QGraphicsScene may be able to help mitigate
that so all I have to do is worry about moving the items around to
achieve the overlay. That was my second question since I had to do scaling of the painter matrix (now transform) to get everything into the same coordinates.


Ben