Re: [Interest] Embedding QWindow
OK, I'm not familiar with QML QtQuick at all yet, only quite recently started using Qt as an alternative for MS. If those support OpenGL core profile 4+ then I'll have to take a look when I have the time, for now I have to stick with Qt Creator. So the context is that QtWidgets (QWidget, QMainWindow etc) are the traditional but still fine-to-use UI component technology, and QML is the newer tech. The QML tech stack includes QWindow; QtWidgets doesn't really. You can mix QtWidgets and QWindow/QML (with that createContainerWidget method or QQuickWidget), but you shouldn't unless you have a reason to, and it sounds like you don't. If you want to use QtWidgets then you should probably just use QGLWidget. Ian All right, that clarifies things. Thanks, -Risto PS. Sorry about the previous unfinished message, a sudden hand movement trying to save my coffee mug. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
Am 04.08.2014 um 23:58 schrieb Ian Monroe i...@monroe.nu: On Mon, Aug 4, 2014 at 1:53 PM, rap r...@dlc.fi wrote: From: Ian Monroe On Mon, Aug 4, 2014 at 12:32 PM, rap r...@dlc.fi wrote: Why do you want to use QWindow if you are using QWidget-based windows? QGLWidget seems like the correct solution. Your question arises a question of the purpose and usefulness of QWindow class regarding opengl if you can not easily create UI controls to go with it, at least in a SDI application. I'll check how things turn out with MDI and QWindow for child wnds. Sure you can create UI controls with QWindow, just use QML and Qt Quick Controls.You could do your own OpenGL stuff by subclassing QQuickItem. That's what QWindow is for. It's not meant to be poor replacement for QGLWidget. Ian OK, I'm not familiar with QML QtQuick at all yet, only quite recently started using Qt as an alternative for MS. If those support OpenGL core profile 4+ then I'll have to take a look when I have the time, for now I have to stick with Qt Creator. So the context is that QtWidgets (QWidget, QMainWindow etc) are the traditional but still fine-to-use UI component technology, and QML is the newer tech. While traditional and newer sounds like the one is going to replace the other (which might or might not be the case), I'd say that QML is simply a different approach for designing GUIs. Simplified you could say it's all about declarative (QML) vs imperative (QWidgets). Personally - for desktop applications - I still prefer traditional widget hierarchies with their very common parent-child paradigm (also in other GUI tool kits). However if you're thinking about full screen custom OpenGL GUIs (well, games ;)) then mixing OpenGL with QtQuick (with its declarative GUI language QML) is definitively worth checking out! There is a Qt example which does just that. The QML tech stack includes QWindow; QtWidgets doesn't really. Technically QWindow is in the base QtGui library on which the QtWidget library is based (just like the corresponding QtQuick library, if I am not mistaken). But it is correct to say that QWindow was more meant to be a low level window container for QtQuick based applications. So it cannot really be directly incorporated into a QWidget hierarchy (like e.g. a top-level QDialog widget which could have another QMainWindow as parent). But if I am not mistaken under the hood a QWindow is also used as base for e.g. a QMainWindow. It is just the lowest common and most lightweight denominator for interaction with the underlying window system (which could also simply be a framebuffer on embedded systems, if I understood this correctly). You can mix QtWidgets and QWindow/QML (with that createContainerWidget method or QQuickWidget), That's exactly the magic keyword here, the static method of QWidget::createContainerWidget! The only downside is you cannot (?) do that entirely within Qt Designer: you cannot e.g. simply drag'n'drop a QGLWidget into the Designer form and promote it to MyOpenGLWidget. So you have to insert another Container widget into the form (e.g. your QMainWidow) and add a QLayout to it, then in the c'tor of your QMainWindow based class create an instance of your OpenGL enabled QWindow, then create a container widget for it with the above method (which takes ownership over the QWindow) and add that newly created widget to your QLayout. Works pretty well, with a little bit of hand-coding. Off course the upcoming QOpenGLWidget (which replaces QGLWidget) would make that boilerplate code unnecessary again. But for the time being - Qt 5.3 - and for new code QWindow/createWidgetContainer is the way to go, so I understand. but you shouldn't unless you have a reason to, and it sounds like you don't. If you want to use QWidgets for *new* code and want to make use of the most recent QOpenGL classes (as opposed to the old QGL classes) then the createWidgetContainer way is the most sensible one to me. Also see below. If you want to use QtWidgets then you should probably just use QGLWidget. There is a conversion method to convert a new QOpenGLContext (which was really designed to be used with QWindow and which you should be using now) to the old QGLContext, but that is really a detour, since QGLContext is just a wrapper over the newer QOpenGLContext again. So when you create a QGLWidget with your converted QGLContext under the hood it will be converted back to a QOpenGLContext. Not a huge performance hit (if at all), but probably just a hint that you should be using QWindow based OpenGL rendering for /new/ code (and the upcoming QOpenGLWindow which I expect will then work with the new QOpenGL classes exclusively). So for /existing/ code you can still use your QGLWidget, but progressively replace all other QGL classes with their QOpenGL counterparts. For new code start using QOpenGL classes right away (including the new
Re: [Interest] Embedding QWindow
Am 05.08.2014 um 10:27 schrieb Till Oliver Knoll till.oliver.kn...@gmail.com: ... That's exactly the magic keyword here, the static method of QWidget::createContainerWidget! That's QWidget::createWindowContainer() to be correct ;) Cheers, Oliver ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
According to this blog post: http://blog.qt.digia.com/blog/2014/07/02/qt-weekly-16-qquickwidget never use the QWidget::createWindowContainer() :) use QQuickWidget instead. BR, Filip On Tue, Aug 5, 2014 at 10:31 AM, Till Oliver Knoll till.oliver.kn...@gmail.com wrote: Am 05.08.2014 um 10:27 schrieb Till Oliver Knoll till.oliver.kn...@gmail.com: ... That's exactly the magic keyword here, the static method of QWidget::createContainerWidget! That's QWidget::createWindowContainer() to be correct ;) Cheers, Oliver ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
From: Till Oliver Knoll Sent: Tuesday, August 05, 2014 11:27 AM But if I am not mistaken under the hood a QWindow is also used as base for e.g. a QMainWindow. It is just the lowest common and most lightweight denominator for interaction with the underlying window system (which could also simply be a framebuffer on embedded systems, if I understood this correctly). That don't seem to be the case, QMainWindow inherits from QWidget, which probably is the reason for the need of QWidget::createWindowContainer() when using QWindow based classes in QWidget based contexts. ... Off course the upcoming QOpenGLWidget (which replaces QGLWidget) would make that boilerplate code unnecessary again. So for /existing/ code you can still use your QGLWidget, but progressively replace all other QGL classes with their QOpenGL counterparts. For new code start using QOpenGL classes right away (including the new QWindow based OpenGL rendering). Cheers, Oliver Right, this is exactly the reason for my initial question after studying some QtGuiApplication /QWindow based samples by KDAB, also the Qt examples in the gui subfolder. For now, if QWindow works for MDI child wnds without any user controls that would be sufficient for me at this point, actually even better. Working in that direction now. Thanks -Risto ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
There is a QWindow under the hood for each top-level widget, but it is not done via inheritance. The QWindow and QWidget hierarchies are distinct. The description from Oliver covers the situation pretty well. One thing worth noting in addition is that using QWindow for rendering OpenGL (or raster, for that matter) stuff without relying on widgets or Qt Quick is a perfectly valid use case. Applications that render everything on their own are better off with QWindow than QGLWidget (or QOpenGLWidget) if all they need is a window they can render to. Best regards, Laszlo From: interest-bounces+laszlo.agocs=digia@qt-project.org [interest-bounces+laszlo.agocs=digia@qt-project.org] on behalf of rap [r...@dlc.fi] Sent: Tuesday, August 05, 2014 12:09 PM To: Till Oliver Knoll; Qt Project Subject: Re: [Interest] Embedding QWindow From: Till Oliver Knoll Sent: Tuesday, August 05, 2014 11:27 AM But if I am not mistaken under the hood a QWindow is also used as base for e.g. a QMainWindow. It is just the lowest common and most lightweight denominator for interaction with the underlying window system (which could also simply be a framebuffer on embedded systems, if I understood this correctly). That don't seem to be the case, QMainWindow inherits from QWidget, which probably is the reason for the need of QWidget::createWindowContainer() when using QWindow based classes in QWidget based contexts. ... Off course the upcoming QOpenGLWidget (which replaces QGLWidget) would make that boilerplate code unnecessary again. So for /existing/ code you can still use your QGLWidget, but progressively replace all other QGL classes with their QOpenGL counterparts. For new code start using QOpenGL classes right away (including the new QWindow based OpenGL rendering). Cheers, Oliver Right, this is exactly the reason for my initial question after studying some QtGuiApplication /QWindow based samples by KDAB, also the Qt examples in the gui subfolder. For now, if QWindow works for MDI child wnds without any user controls that would be sufficient for me at this point, actually even better. Working in that direction now. Thanks -Risto ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
Am 05.08.2014 um 10:48 schrieb Filip Piechocki fpiecho...@gmail.com: According to this blog post: http://blog.qt.digia.com/blog/2014/07/02/qt-weekly-16-qquickwidget never use the QWidget::createWindowContainer() :) use QQuickWidget instead. Read the fine print: ;) having a QQuickView embedded via createWindowContainer() will always lead to better performance when compared to QQuickWidget The reason is probably related to buffering: according to the blog all drawing of the QQuickWidget - that includes (raw) OpenGL drawing as well, I guess - will first go into an application specific buffer where it is combined with all the other widget paintings (notably transparent overlays etc., which otherwise would cause rendering artifacts when using native windows). That per Qt application buffering (especially referring to raw OpenGL) even raises more interesting questions on platforms such as OS X where the Window (composition) Manager itself introduces yet another per application buffer (so swapping GL double buffers on OS X is in fact pointless, since the window manager will do this for you, too). So you render into the Qt application buffer, which gets copied into the OS specific per application buffer, which eventually (with the whole composited desktop) is copied into the video (front) buffer. Even more interesting: Retina displays (on OS X). By default the OpenGL framebuffer resolution that is created by the OS when requesting a window size of w times h points is half the resolution of the Retina display, such that the same amount of OpenGL fragments are processed by default, as compared to a non-Retina display with the same window size [in points]. If one really wants to draw with OpenGL in the native (physical) resolution then a flag (in Core Graphics?) can be set before creating the corresponding OpenGL Cocoa widget. Besides the Retina use case there is another full screen with custom resolution use case: instead of switching the graphic mode (resolution) for full screen OpenGL applications one simply requests a custom size of the frame buffer. The window manager itself will then scale up that buffer (without the application having to deal with that, apart from initially requesting the custom size buffer) to the physical screen resolution. I wonder how this all adds up when the application introduces yet another per application composition layer with buffer...? But yes, there are issues with createWindowContainer ;) (especially on certain embedded systems with no Window Manager). But from what I understand they are not worse than what we know from QGLWidget (on desktop systems anyway). And let's just wait what QOpenGLWidget brings to us and how it turns out in practise with all this buffering! By now it should be clear that if you want to have as few as possible between you and the GPU: use QWindow only! Cheers, Oliver___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
Thanks, this discussion has been really useful, I haven't found anything written giving the larger picture, just nuts and bolts everywhere. Regarding the idea of using MDI and QWindow for child wnds seems to stumble on the fact that QMdiSubWindow class is a QWidget based class too. There seems to be no escape from using QWidget::createWindowContainer() at the moment, even for MDI child wnds. - Risto From: Agocs Laszlo Sent: Tuesday, August 05, 2014 2:21 PM There is a QWindow under the hood for each top-level widget, but it is not done via inheritance. The QWindow and QWidget hierarchies are distinct. The description from Oliver covers the situation pretty well. One thing worth noting in addition is that using QWindow for rendering OpenGL (or raster, for that matter) stuff without relying on widgets or Qt Quick is a perfectly valid use case. Applications that render everything on their own are better off with QWindow than QGLWidget (or QOpenGLWidget) if all they need is a window they can render to. Best regards, Laszlo Sent: Tuesday, August 05, 2014 11:27 AM But if I am not mistaken under the hood a QWindow is also used as base for e.g. a QMainWindow. It is just the lowest common and most lightweight denominator for interaction with the underlying window system (which could also simply be a framebuffer on embedded systems, if I understood this correctly). That don't seem to be the case, QMainWindow inherits from QWidget, which probably is the reason for the need of QWidget::createWindowContainer() when using QWindow based classes in QWidget based contexts. ... Off course the upcoming QOpenGLWidget (which replaces QGLWidget) would make that boilerplate code unnecessary again. So for /existing/ code you can still use your QGLWidget, but progressively replace all other QGL classes with their QOpenGL counterparts. For new code start using QOpenGL classes right away (including the new QWindow based OpenGL rendering). Cheers, Oliver Right, this is exactly the reason for my initial question after studying some QtGuiApplication /QWindow based samples by KDAB, also the Qt examples in the gui subfolder. For now, if QWindow works for MDI child wnds without any user controls that would be sufficient for me at this point, actually even better. Working in that direction now. Thanks -Risto ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
Am 05.08.2014 um 12:09 schrieb rap r...@dlc.fi: From: Till Oliver Knoll Sent: Tuesday, August 05, 2014 11:27 AM But if I am not mistaken under the hood a QWindow is also used as base for e.g. a QMainWindow. ... That don't seem to be the case, QMainWindow inherits from QWidget, That's why I wrote [uses] under the hood and not inherits from ;) Maybe my used as base wording was a bit misleading here: I meant that the QtGui library acts as a base (basis? Sorry, not a native English speaker here ;)) for both QWidget and QtQuick applications to interact with the underlying windowing system. So whenever a QWidget figures out that it is a top-level widget it request a native window - by using a QWindow (in Qt 4.x and earlier that Window Manager interaction was probably all coded into the QWidget (support) classes directly). And I also wrote that a QWindow fits better into the QtQuick world, since there it is indeed a base class (now in the inheritance meaning ;)) for QQuickView etc. - for the QWidget world you need a wrapper class:, said QWindowContainer. Also refer to Laszo's reply :) Cheers, Oliver ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
OK, got that now ;) Thanks, - Risto From: Till Oliver Knoll Sent: Tuesday, August 05, 2014 2:45 PM Am 05.08.2014 um 12:09 schrieb rap r...@dlc.fi: From: Till Oliver Knoll Sent: Tuesday, August 05, 2014 11:27 AM But if I am not mistaken under the hood a QWindow is also used as base for e.g. a QMainWindow. ... That don't seem to be the case, QMainWindow inherits from QWidget, That's why I wrote [uses] under the hood and not inherits from ;) Maybe my used as base wording was a bit misleading here: I meant that the QtGui library acts as a base (basis? Sorry, not a native English speaker here ;)) for both QWidget and QtQuick applications to interact with the underlying windowing system. So whenever a QWidget figures out that it is a top-level widget it request a native window - by using a QWindow (in Qt 4.x and earlier that Window Manager interaction was probably all coded into the QWidget (support) classes directly). And I also wrote that a QWindow fits better into the QtQuick world, since there it is indeed a base class (now in the inheritance meaning ;)) for QQuickView etc. - for the QWidget world you need a wrapper class:, said QWindowContainer. Also refer to Laszo's reply :) Cheers, Oliver ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
On Tue, Aug 5, 2014 at 1:29 PM, Till Oliver Knoll till.oliver.kn...@gmail.com wrote: Am 05.08.2014 um 10:48 schrieb Filip Piechocki fpiecho...@gmail.com: According to this blog post: http://blog.qt.digia.com/blog/2014/07/02/qt-weekly-16-qquickwidget never use the QWidget::createWindowContainer() :) use QQuickWidget instead. Read the fine print: ;) That's why I pasted the link to this article - so anybody can read it in details :) having a QQuickView embedded via createWindowContainer() will always lead to better performance when compared to QQuickWidget The reason is probably related to buffering: according to the blog all drawing of the QQuickWidget - that includes (raw) OpenGL drawing as well, I guess - will first go into an application specific buffer where it is combined with all the other widget paintings (notably transparent overlays etc., which otherwise would cause rendering artifacts when using native windows). That per Qt application buffering (especially referring to raw OpenGL) even raises more interesting questions on platforms such as OS X where the Window (composition) Manager itself introduces yet another per application buffer (so swapping GL double buffers on OS X is in fact pointless, since the window manager will do this for you, too). So you render into the Qt application buffer, which gets copied into the OS specific per application buffer, which eventually (with the whole composited desktop) is copied into the video (front) buffer. Even more interesting: Retina displays (on OS X). By default the OpenGL framebuffer resolution that is created by the OS when requesting a window size of w times h points is half the resolution of the Retina display, such that the same amount of OpenGL fragments are processed by default, as compared to a non-Retina display with the same window size [in points]. If one really wants to draw with OpenGL in the native (physical) resolution then a flag (in Core Graphics?) can be set before creating the corresponding OpenGL Cocoa widget. Besides the Retina use case there is another full screen with custom resolution use case: instead of switching the graphic mode (resolution) for full screen OpenGL applications one simply requests a custom size of the frame buffer. The window manager itself will then scale up that buffer (without the application having to deal with that, apart from initially requesting the custom size buffer) to the physical screen resolution. I wonder how this all adds up when the application introduces yet another per application composition layer with buffer...? But yes, there are issues with createWindowContainer ;) (especially on certain embedded systems with no Window Manager). But from what I understand they are not worse than what we know from QGLWidget (on desktop systems anyway). And let's just wait what QOpenGLWidget brings to us and how it turns out in practise with all this buffering! By now it should be clear that if you want to have as few as possible between you and the GPU: use QWindow only! Cheers, Oliver ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
if it is somehow possible to embed Opengl classes derived from QWindow PS. Just to clarify my poorly chosen words: I have classes that use opengl and they are derived from QWindow. Hope that is more clear. Thanks, Risto From: rap Sent: Monday, August 04, 2014 6:28 PM To: Qt developer forum Subject: [Interest] Embedding QWindow Hello, I'm trying to create an initial OpenGL project for porting some Visual Studio 2010 win32 OpenGL learning stuff to Qt 5.3.1. I wonder if it is somehow possible to embed Opengl classes derived from QWindow as the centralwidget to QMainWindow? So far I have been using a QGLWidget as the centralwidget. Thanks, Risto ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
On Mon, Aug 4, 2014 at 8:28 AM, rap r...@dlc.fi wrote: Hello, I'm trying to create an initial OpenGL project for porting some Visual Studio 2010 win32 OpenGL learning stuff to Qt 5.3.1. I wonder if it is somehow possible to embed Opengl classes derived from QWindow as the centralwidget to QMainWindow? So far I have been using a QGLWidget as the centralwidget. See the OpenGL Window Example. Ian ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
From: Ian Monroe
...
On Mon, Aug 4, 2014 at 8:28 AM, rap r...@dlc.fi wrote:
Hello,
I'm trying to create an initial OpenGL project for porting some Visual
Studio 2010 win32 OpenGL learning stuff to Qt 5.3.1. I
wonder
if it is somehow possible to embed Opengl classes derived from QWindow as
the centralwidget to QMainWindow? So far I have been
using
a QGLWidget as the centralwidget.
See the OpenGL Window Example.
Ian
Thanks Ian, I have studied that example but it does not give an answer.
What I'm trying accomplish is to have a MainWindow (derived from QApplication
/ QWidget) for user input, (buttons etc.) and then a
QWindow derived class as the OpenGL drawing surface and also to be the
centralwidget in the MainWindow . However, I haven't been
able to get this to work (probably because QWindow is not a QWidget based class
and thus won't be accepted as central*widget*). I
have read that there will be a QOpenGLWidget in future versions that may be
just what I'm after, but for now I'm trying to find out
if there is a workaround until that happens.
This is how I have been doing things so far, the myGLWidget is currently
QGLWidget based, and now I want/need to replace it with a
QWindow based class. The MainWindow constructor:
MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent)
{
ui.setupUi(this);
glw = new myGLWidget();
setCentralWidget(glw);
glw-setAttribute( Qt::WA_DeleteOnClose );
...
}
All my OpenGL stuff is in the glw instance, using signals from MainWindow/user
controls but mouse input directly.
Thanks,
Risto
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
On Mon, Aug 4, 2014 at 11:21 AM, rap r...@dlc.fi wrote:
Thanks Ian, I have studied that example but it does not give an answer.
What I'm trying accomplish is to have a MainWindow (derived from
QApplication / QWidget) for user input, (buttons etc.) and then a QWindow
derived class as the OpenGL drawing surface and also to be the centralwidget
in the MainWindow . However, I haven't been able to get this to work
(probably because QWindow is not a QWidget based class and thus won't be
accepted as central*widget*). I have read that there will be a
QOpenGLWidget in future versions that may be just what I'm after, but for
now I'm trying to find out if there is a workaround until that happens.
This is how I have been doing things so far, the myGLWidget is currently
QGLWidget based, and now I want/need to replace it with a QWindow based
class. The MainWindow constructor:
MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent)
{
ui.setupUi(this);
glw = new myGLWidget();
setCentralWidget(glw);
glw-setAttribute( Qt::WA_DeleteOnClose );
...
}
All my OpenGL stuff is in the glw instance, using signals from
MainWindow/user controls but mouse input directly.
Why do you want to use QWindow if you are using QWidget-based windows?
QGLWidget seems like the correct solution.
You can embed a QWindow inside a QWidget using QWidget::createWindowContainer.
Ian
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
Why do you want to use QWindow if you are using QWidget-based windows? QGLWidget seems like the correct solution. Your question arises a question of the purpose and usefulness of QWindow class regarding opengl if you can not easily create UI controls to go with it, at least in a SDI application. I'll check how things turn out with MDI and QWindow for child wnds. You can embed a QWindow inside a QWidget using QWidget::createWindowContainer. OK, however the help file doesn't paint a very promising picture of the usage of QWidget::createWindowContainer. -Risto ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
On Mon, Aug 4, 2014 at 12:32 PM, rap r...@dlc.fi wrote: Why do you want to use QWindow if you are using QWidget-based windows? QGLWidget seems like the correct solution. Your question arises a question of the purpose and usefulness of QWindow class regarding opengl if you can not easily create UI controls to go with it, at least in a SDI application. I'll check how things turn out with MDI and QWindow for child wnds. Sure you can create UI controls with QWindow, just use QML and Qt Quick Controls.You could do your own OpenGL stuff by subclassing QQuickItem. That's what QWindow is for. It's not meant to be poor replacement for QGLWidget. Ian ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
From: Ian Monroe On Mon, Aug 4, 2014 at 12:32 PM, rap r...@dlc.fi wrote: Why do you want to use QWindow if you are using QWidget-based windows? QGLWidget seems like the correct solution. Your question arises a question of the purpose and usefulness of QWindow class regarding opengl if you can not easily create UI controls to go with it, at least in a SDI application. I'll check how things turn out with MDI and QWindow for child wnds. Sure you can create UI controls with QWindow, just use QML and Qt Quick Controls.You could do your own OpenGL stuff by subclassing QQuickItem. That's what QWindow is for. It's not meant to be poor replacement for QGLWidget. Ian OK, I'm not familiar with QML QtQuick at all yet, only quite recently started using Qt as an alternative for MS. If those support OpenGL core profile 4+ then I'll have to take a look when I have the time, for now I have to stick with Qt Creator. -Risto ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
On Mon, Aug 4, 2014 at 1:53 PM, rap r...@dlc.fi wrote: From: Ian Monroe On Mon, Aug 4, 2014 at 12:32 PM, rap r...@dlc.fi wrote: Why do you want to use QWindow if you are using QWidget-based windows? QGLWidget seems like the correct solution. Your question arises a question of the purpose and usefulness of QWindow class regarding opengl if you can not easily create UI controls to go with it, at least in a SDI application. I'll check how things turn out with MDI and QWindow for child wnds. Sure you can create UI controls with QWindow, just use QML and Qt Quick Controls.You could do your own OpenGL stuff by subclassing QQuickItem. That's what QWindow is for. It's not meant to be poor replacement for QGLWidget. Ian OK, I'm not familiar with QML QtQuick at all yet, only quite recently started using Qt as an alternative for MS. If those support OpenGL core profile 4+ then I'll have to take a look when I have the time, for now I have to stick with Qt Creator. So the context is that QtWidgets (QWidget, QMainWindow etc) are the traditional but still fine-to-use UI component technology, and QML is the newer tech. The QML tech stack includes QWindow; QtWidgets doesn't really. You can mix QtWidgets and QWindow/QML (with that createContainerWidget method or QQuickWidget), but you shouldn't unless you have a reason to, and it sounds like you don't. If you want to use QtWidgets then you should probably just use QGLWidget. Ian ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
