If you insist on putting a QGLWidget on a form, you can use wwWidgets, but you won't be able to do anything serious with the widget without subclassing it.
If you insist on putting a QGLWidget on a form, you can use wwWidgets, but you won't be able to do anything serious with the widget without subclassing it.
Not insisting upon anything really.
I just don't understand why the OpenGL widget is treated differently than other widgets. I realize "as implemented" one has to subclass QGlWidget for functionality. However, there are other extension mechanisms than simply subclassing. There's extension via composition and delegation, etc.
Not trying to get flamed here ... at least not my first week. I'm a relative Qt newbie and really want to learn the orthodox approach. It's obvious I'm missing some of the architectural design goals of Qt.
Thanks for you inputs. I am proceeding with the extension mechanism as recommended. I would like a better understanding though.
Much thanks,
Ben
Of course it would be nice if you could put QGLWidget on the form using Designer and then connect some other object to it that would paint on it, but for some reason the Trolls made it in a different way. Maybe they couldn't bypass some limitation of one of the OSes. You will have to ask them.Originally Posted by brcain
Thanks. That reply makes more since than "you have to subclass" because that's the way you have do "it". You hint to a possible design decision. I've asked Trolltech, but all I really get is the QGlWidget is an abstract class. Indeed, that is a fact; but wasn't my question to them ... why different than other widgets.
Some Designers I've used in the past have been more like IDEs where essentially every UI component (and their external events) could be connected together.
Cheers,
Ben
It could be just because of performance reasons. Having an external object would imply passing the GL context here and there causing huge amounts of data being transferred across widgets, making the widget slower. It could also be that Trolls were lazy and didn't want to make using OpenGL more complex than they had to. You could ask the same question about QThread for example. It's just a design and not a bad one, too.
Did they allow you do load forms from files in the runtime?Originally Posted by brcain
Designer produces a XML file the layout. You can transform it to a header files using uic, but you can also load it in the runtime --- this gives you some new possibilities, but like every solution has its own limitations. One of them is that you can't put everything on the form using designer (without plugins).
PS. I haven't mentioned one of the ways of dealing with QGLWidget: you can create a "custom widget" which is a just a stub that will be replaced by uic with the proper widget.
They didn't have that type of runtime extensibility. That's pretty amazing.
I may create a custom gl widget. I'm still in mode where I'm learning Qt details more than understanding how everything fits together. So, I think I'll just procede with the subclassing approach for now ... creating custom widget when/if it supports the life cycle better.
Thanks for all the helpful comments.
I've just found this. Sounds great, I will try it in a moment.
Edit: Well... it works without any problems. You can even use signals & slots mechanism to attach the scene to it.
Last edited by jacek; 24th February 2006 at 14:14.
Bookmarks