[Qt-interest] [Updated] QGWidgetProxy: backgrounds and opengl issues

David García Garzón david.garcia at upf.edu
Wed Sep 2 15:02:20 CEST 2009


I drilled more in the QGraphicsWidget issues and found some of the causes. 
Still if someone on the list wants to drop more light i will be very grateful.

A Dimecres, 19 d'agost de 2009 14:47:46, David García Garzón va escriure:
> We have ported our Qt4.1 based dataflow editor widget (NetworkCanvas) to
> QGraphicsView. The port is almost complete now.
>
> The last step is about dataflow modules, ProcessingBoxes (QGItems), which
> may have an embeded widget for data monitorization, control sending...
> Right now, we just place such widget on the top of the NetworkCanvas as
> regular child widget and it used to work but for the fact that widgets
> always awfully overlap any other element of the canvas[1]. Something that
> we want to fix by using QGWidgetProxy.
>
> But after trying, we got a set of issues:
>
> 1- We were not able to use the parent item, or whatever they have below, as
> background. We set 'background-color:transparent' style to disable the
> standard grey background but then we got QPalette::Base (spin box numbers)
> in black and where QPalete::Window a black box on the top and a
> semitransparent gradient rubbish is painted on the background. Any idea on
> how to achieve that or getting the rubbish away?

I found that the black box and the gradiend just appears in the Oxygen style. 
I guess that not coping properly with a transparent background color. Other 
widgets styles do not get those artifacts but QPalette::Base still look weird 
in most styles. Is that a bug on the style or it is something about our way to 
get the transparency? Any better solution?

> 2- Some custom widgets like an oscilloscope which just draws a polyline,
> scales the painter to have the same coordinates than the domain (1,-1). The
> problem is that the pen width gets scaled as well when inside QGWP while as
> regular widget it doesn't. Is that a QGWP bug that they work different or
> am i missing something? The paintEvent method contains this:
>         QPainter painter(this);
>         painter.setPen(QColor(0x77,0x77,0x77,0x77));
>         painter.translate(0,height()/2);
>         painter.scale(width(),-height()/2);
>         // axis line, gets scaled as well
>         painter.drawLine(0,0,1,0);
>         painter.setPen(_lineColor);
>         QPolygonF line;
>         for (int i=0; i<_size; i++)
>             line << QPointF(float(i)/size, _data[i]);
>         painter.drawPolyline(line);

I saw that the following line fixes up a little the problem:
painter.setRenderHint(QPainter::NonCosmeticDefaultPen,false);

But not fully. I understand, acording to Andreas blog[4], that scene and item 
scalings should affect the point size, i think that inner drawing scalings like 
this one should not affect it, so that a zero (scene) scaled within QGPW would 
look the same as the widget out of it.

Any further thoughs about that? Andreas?

[4] http://labs.trolltech.com/blogs/2007/10/

> 3- Some of the monitoring widgets are OpenGl based[3], documentation says
> OpenGl widgets are not supported. My current workaround is to keep them as
> on- top widgets if the WA_PaintOnScreen flag is set. Is there any plan to
> support them in the future? Any alternative idea?

No update on that one. :-(


> [1] http://clam-project.org/wiki/Image:BeforeMerge2.png
> [2] http://clam-project.org/wiki/Image:QGWPBugs.png
> [3] http://clam-project.org/wiki/Image:OptimizedKeySpace.png


-- 
David García Garzón
(Work) david dot garcia at upf anotherdot edu
http://www.iua.upf.edu/~dgarcia




More information about the Qt-interest-old mailing list