I recall Fabian started a qml port - what - four, five years ago? Unfortunately another symptom on the Second Law of Thermodynamics.
> On Jan 11, 2015, at 9:04 PM, Guillaume Chereau > <guilla...@noctua-software.com> wrote: > > Hello Georg, happy new year everyone! > > On Wed, Jan 07, 2015 at 01:13:15AM +0100, Georg Zotti wrote: >> 1) QtDeclarative has been deprecated a while ago and documentation links >> are (deliberately I suppose) getting sparse. QGL... classes are >> deprecated. We are still using them, but replacements have been made >> available for most, if not all, functionality. Not having much experience >> with these Qt window/widget classes does not help in finding correct >> replacements. > > Currently we still need QtDeclarative as it is the only way -that I am > aware of- to embed QWidgets into an opengl view. Last time I checked, > it was impossible to do it using a QQuickView. > >> 2) Classes which need to draw with OpenGL gl... calls should be derived >> from QOpenGLFunctions. The current situation is this #define nightmare in >> StelOpenGL.hpp. What was the specific reason to do that and not follow the >> documented and recommended path? > > The reason is because QOpenGLFunctions methods are not const, which > makes it impossible to call them from any const method when inheriting > from it (see https://bugreports.qt.io/browse/QTBUG-39095). That's why > we use the more verbose > QOpenGLContext::currentContext()->functions()->glXXX way on Windows. I > put the macro so that we don't have to type the whole thing for each > opengl call. > >> 3) Qt5.4 brings a change to allow building binaries for the most widely >> used platform that can locate and bind either native OpenGL, or OpenGL ES >> (ANGLE) or fallback to software OpenGL (MESA) libraries on startup. This >> however requires cleaning up issue (2) in the Qt way. > > Yes, I just committed a small fix to allow compilation on Windows with > Qt 5.4. Basically the problem is that since Qt 5.4 do not link with any > opengl implementation, the only way to call opengl function is through > QOpenGLFunctions. Qt also now make it simpler by having all the OpenGL > functions accessible as methods of QOpenGLFunctions, previously they had > this annoying idea of only reimplementing the problematic functions. So > at least with Qt 5.4 there is a clear unique way of doing opengl: all > the calls should be made from QOpenGLFunctions. > > Also when downloading Qt 5.4, I only consider the 'normal' version, not > the one with 'opengl' prefix. The normal Qt 5.4 windows version is > better since it includes both OpenGL and ANGLE libraries. > >> I tried my luck over the holidays but am stuck and had to see that I >> cannot complete this by tonight. Is there anyone more fluent in / >> knowledgeable about the current Qt GUI (i.e. QtQuick2, >> QtOpenGLWidget/-Window, ...) classes able to do these necessary steps? I >> leave my branch open as qt54-qtify, where I already replaced QtDeclarative >> with QtQuick+QtQuickwidgets+QtQml, but got stuck with various class >> changes, and I am of course not sure if my decisions of replacement >> classes were the best. So maybe either start from here or anew from trunk. >> I must currently cease work on this. > > I had a very quick look at your branch, but it failed to compile. I > still think currently it is not possible to get ride of QtDeclarative > because that is the only way Qt allows to put QWidgets on top of an > opengl view. Of course one solution would be to rewrite the whole GUI > in qml (is that what you try to do in your branch?), but this would be a > massive work, so I am not sure if it is the right thing to do. > > Then, maybe I am wrong and there is a way to embed QWidgets into an > OpenGL windows without using QtDeclarative (for example by putting a > qwidget inside qml view?) If we find a way to do that we could simplify > the code a lot without having to rewrite any of the UI code. > >> One further note on any possible replacement classes: >> My Raspberry experiment indicated that Stellarium can be compiled on this >> OpenGL ES2 embedded Linux system, but fails with a startup message: >> >> EGLFS: OpenGL windows cannot be mixed with others. > > Unfortunately I am not familiar with the Raspberry. Do simple Qt > + OpenGL ES 2 examples work on it? > > Best regards, > Guillaume > > ------------------------------------------------------------------------------ > New Year. New Location. New Benefits. New Data Center in Ashburn, VA. > GigeNET is offering a free month of service with a new server in Ashburn. > Choose from 2 high performing configs, both with 100TB of bandwidth. > Higher redundancy.Lower latency.Increased capacity.Completely compliant. > vanity: www.gigenet.com > _______________________________________________ > Stellarium-pubdevel mailing list > Stellarium-pubdevel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. vanity: www.gigenet.com
_______________________________________________ Stellarium-pubdevel mailing list Stellarium-pubdevel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
