Dear Guillaume! First, thank you for looking into this. This is a major architectural change, so I can imagine it's not simple.
When I wrote the bug report, I tried alpha5 (?) on an Intel PC that should support OpenGL2.1. I have no build environment on this and cannot spend much time on Stellarium there. It complains in the logfile about unresolved OpenGL functions, and in night mode displays a big dark-red rectangle in the lower left corner (limited by the extents of the sliding button bars). I also tried with the Mesa library, here it worked, but of course quite slow (it is a dual-core2 though, so still not too bad (2009?)). That means, once again it's mostly an Intel driver problem, but that PC is not so old and should support current Qt, and may represent a considerable fraction of users' PCs. I think I have also reproduced the same issue on an i3 notebook (HD3000 graphics). Maybe also that Intel driver is just pickier about having to use initializeOpenGLfunctions(?) or such, but for OpenGL2.1 I had thought it is not necessary? Apparently this call gives different results on Win and Linux, my scenery3d branch seems to initialize OK on Linux (Alex reported) and always failed on my Win7/NVidia system. I can also only guess when QtDeclarative will be removed from Qt, but I can imagine that Qt devs will not invest much time into keeping it alive when they talk so much more about, and want devs to convert to use, QtQuick2. So my thoughts were that all things documented in Qt work only reliably with the newer classes. Else, on the cheap-hardware base, I don't know where we should go: Shall Stellarium rather be converted to work on OpenGL-ES2.0 with no higher OpenGL functionality, or can we mix development that involves higher GPUs' OpenGL3.2 or better with just a few #ifdefs? I am afraid I don't know the programming details and differences concerning OpenGLES. Given the enormous popularity of Stellarium from schools to world-class observatories (wow!), it would be nice to have our application in basic functionality available on all Qt platforms: Androids, netbooks (using the Angle crutch) and toy computers (Raspberries etc.), but advanced versions available in plugins that would then work only on powerful hardware, if that is possible. Cheap/old hardware with Mesa (esp. single-core CPUs) is too slow. Better old hardware (like that Intel used above) can be kicked to work with Mesa. If only one type of OpenGL is possible, I strongly vote for higher quality thingies (dropping hopes in OpenGL1.4 hardware and Angle translating OpenGLES2.0 to DirectX9c), and would like to see a working example of initializeOpenGLfunctions() on Windows... Best regards, and good luck and rapid success with trials, Georg On Do, 13.02.2014, 09:16, Guillaume Chéreau wrote: > OK, I did some tests. So far I have no luck using > createWindowContainer: each time the container hides any other widget > no matter how I try. This is not good because for stellarium we need > to show first the qml view, and then the normal widgets (for the > settings windows) on top of it. > > I will try to ask the Qt dev how to achieve that. > > Meanwhile what exactly is the problem with the current qml fragment > shader? For me it seems to work on windows, linux and OSX. Do we > have more info about when QDeclarativeView will be deprecated? One > thing I could do is start to work on the qml UI using QtQuick 1.0 in a > branch, then later switch it to QtQuick 2.0. > > gui > > On Thu, Feb 13, 2014 at 11:41 AM, Guillaume Chéreau > <[email protected]> wrote: >> On Sun, Jan 12, 2014 at 7:25 PM, Georg Zotti <[email protected]> >> wrote: >>> I had the same fear for weeks now that the deprecation of QtDeclarative >>> will sooner than later hit us. Is anybody working on this? >>> Fabien, Guillaume? Anybody else with deep enough insight into Qt? What >>> has >>> to be done, where? >> >> I had a look at this yesterday. The problem is that currently Qt does >> not allow to mix QtQuick 2.0 and widgets very well. There is >> QWidget::createWindowContainer() that might help : >> >> https://blog.qt.digia.com/blog/2013/02/19/introducing-qwidgetcreatewindowcontainer/ >> >> With this we could maybe have the sky + the basic UI (bottom and left >> bars) written in qml (with QtQuick 2.0), and keep the settings windows >> as they are now. >> >> An other way would be to rewrite the entire UI in qml, but this would >> take a lot of effort. >> >> Anyway I am going to make more tests to see how we can do the >> transition. I think having the bottom and left bars in qml would be >> an improvement to the code anyway. >> >> Regards, >> >> guillaume >> >>> >>> Still very much hoping for a "Yes, I do", >>> >>> Best regards, Georg >>> >>> >>> On Fr, 10.01.2014, 19:23, Reaves, Timothy wrote: >>>> Until this is completed, Stellarium is now completely broken. >>>> >>>> The shaders the app uses require QtQuick 2.0 now, as that is where the >>>> labs >>>> stuff was moved. When moving to QtQuick 2.0, we need to replace >>>> QDeclarativeView with QQuickView. >>>> >>>>>From the docs: "When porting from QDeclarativeView to QQuickView, note >>>>> that >>>> QDeclarativeItem inherited from QGraphicsView. In contrast, QQuickView >>>> inherits from QQuickWindow and uses the QWindow infrastructure >>>> introduced >>>> in Qt 5; any QGraphicsView-specific functionality is no longer >>>> available." >>>> >>>> This is some major work around the windowing code; dialogs, widgets, >>>> menus, >>>> etc. >>>> ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ Stellarium-pubdevel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
