> Am 03.04.2015 um 17:26 schrieb Matthew Woehlke > <mw_tr...@users.sourceforge.net>: > > On 2015-04-02 13:45, Till Oliver Knoll wrote: >>>> ..... But what's next? A "drawButton"? "drawBitmap"? >> In a Widget?! > > Yes. And why not?
Because the class name sais *Widget, and not *Painter or *WhateverItem. A Widget's responsibility - much like the one of a View; we'll come to that in a second... - is to provide a /surface/ to draw onto, and to manage the underlying system resources (we'll deliberately skip over other functionality, such as layout management). The important point to take away here is that a /Widget/ itself never exposes functionality to /draw/ something (exceptions might prove my thesis ;)). You may draw /onto/ a Widget - but /how/, that's the responsibility of some other class. > QGraphicsView already does this sort of thing. It's funny that you mention that /View/ class, since it does exactly /not/ "this sort of thing". Check again the API of http://doc.qt.io/qt-5/qgraphicsview.html You won't find a single "drawWhatever" method there. Why? In analogy to QOpenGLWidget, same reasoning: it's responsibility is to /manage/ items, not to /draw/ them. That's the responsibility of each item itself. > (Well, > it wouldn't be literally "drawButton", but I can readily imagine Qt The reason why I mentioned a hypotetical "drawButton" in QOpenGLWidget's API was to merely illustrate my point how absurd it was to have any "draw" functionality therein. The existence of a single "drawText" would justify future additions of similar "drawWhatever" functions (because "hey! QOpenGLWidget already has a drawText, why not add my drawFoo method there, too?"). And clearly such an API would get messy and would not scale. So as convenient as "drawText" was, IMHO it is a Good Thing(tm) to leave it out of QOpenGLWidget's API (same goes for bindTexture). > sprouting an easy and convenient way to render a QWidget in a 3D > scene... either as "truly" 3D geometry, i.e. transformed and scaled, or > billboarded and rendered at fixed pixel size, but potentially still > using the GL depth buffer. I'm not even sure what Qt3D can't *already* > do this.) That sounds to me you really want to look into Qt3D, if you want this kind of convenience. >> ... >> >> That's the way to draw "over OpenGL" - not with a restricted "drawText" >> convenience method which happened to be placed in some random API >> (QGLWidget) over a decade ago ;) > > The problem is I don't *want* to draw "over" GL¹. I *need* to draw *in* > GL, specifically I need to specify the text location in terms of the GL > modelview space. > ... > Overpainting techniques are fine... *for overpainting*. That's not what > I'm doing. Clearly I cannot predict your application's requirements, but "overpainting", that's exactly what you were doing apparently, all the time. You said so yourself, you were using http://doc.qt.io/qt-4.8/qglwidget.html#renderText I've never used this method myself, but from what I gather you specify the text coordinates in /window/ coordinates - /not/ world (or model) coordinates! So all the "renderText" does is it "overpaints" the given text into the current GL buffer (by disabling the depth test). You get exactly the same result (probably even a better one due to better anti-aliasing) by using a QPainter and "overpaint" at the same window coordinates. So this method did not do what you now tell us what your requirements are. So one reason more to quickly remove it (before people come and request to please extend the API such that the coordinates could be specified also in model/world coordinates ;)). Happy Easter! Oliver _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
