Example OpenGL project?

Hello,

Sorry if this issue has been beat to death. I did at least do a search ... didn't find answer.

Is there an example showing the recommend approach to having an OpenGL widget within a Designer generated project ... without having to hand-modify the Designer project code? I've read that some suggest a plug-in while others recommend modifying the Designer generated code? Which is the more orthodox approach?

I've noticed several threads/requests for QGLWidget being in Designer. I know that it can't be available in Designer "as is". But, I've used other designers that do indeed provide for an OpenGL widget. I wonder why is it not included "as a built-in capability"?

I'd prefer to let Designer manage as much code as possible. Maybe I'm trying to make it an IDE ... like other tools I've used in the past. Whatever the case, I'm trying to find which solution supports the life cycle best.

Thanks for you time and insight!

Cheers,
Ben

Quote:

---

Originally Posted by brcain

I wonder why is it not included "as a built-in capability"?

---

Because you have to subclass it to be able to draw anything.

You can put a frame or group box on the form and then add your QGLWidget subclass to that frame/group box programmatically.

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

Quote:

---

Originally Posted by brcain

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.

---

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.

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.

Quote:

---

Originally Posted by brcain

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

---

Did they allow you do load forms from files in the runtime?

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.