Thanks for clearing that up. Would you have any time to try to do this to the main app, and then we can start looking at the plugins?
> On Jan 12, 2015, at 10:34 AM, Fabien Chéreau <fabien.cher...@gmail.com> wrote: > > No we just implemented the SVMT plugin in QML while I was at ESO, but I never > tried to re-code Stellarium GUI in QML.. > Actually I don't think it would be a huge effort to port the base GUI. The > problem is more with the plugins which will all be broken.. > Fabien > > On Mon, Jan 12, 2015 at 2:16 PM, Timothy Reaves <trea...@silverfieldstech.com > <mailto:trea...@silverfieldstech.com>> wrote: > 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 <mailto: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 > > <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 <http://www.gigenet.com/> > > _______________________________________________ > > Stellarium-pubdevel mailing list > > Stellarium-pubdevel@lists.sourceforge.net > > <mailto:Stellarium-pubdevel@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > > <https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel> > > > ------------------------------------------------------------------------------ > 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 <http://www.gigenet.com/> > _______________________________________________ > Stellarium-pubdevel mailing list > Stellarium-pubdevel@lists.sourceforge.net > <mailto:Stellarium-pubdevel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > <https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel> > > > ------------------------------------------------------------------------------ > 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. www.gigenet.com
_______________________________________________ Stellarium-pubdevel mailing list Stellarium-pubdevel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
