[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