[Interest] Questions about QGraphicsWidget

[BRM]

> From: Jason H <scorp1us at yahoo.com>

>Sent: Tuesday, August 7, 2012 4:03 PM
>Subject: Re: [Interest] Questions about 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."
>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?


QGraphicsItemGroup seems to just sit separately as far as I can tell from the documentation; so it works great if all you're doing is arranging things in the scene. But once you need to apply a layout to it, its no longer sufficient. This is what led to my first question - about layouts:

> From: BRM <bm_witness at yahoo.com>
> 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