From: Reaves, T. <tr...@si...> - 2014-01-10 18:45:54
|
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. |
From: Georg Z. <geo...@un...> - 2014-01-12 11:25:09
|
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? 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. > |
From: Noah M. <nem...@ya...> - 2014-01-25 17:32:33
|
Here is a suggestion how about we let them bookmark stars and the ones that they use most we make them so they pop up first. It si just a theory but get back to me Noah Michalski On Sunday, January 12, 2014 6:25 AM, Georg Zotti <geo...@un...> 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? 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. > ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Stellarium-pubdevel mailing list Ste...@li... https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel |
From: Guillaume C. <gui...@gm...> - 2014-02-13 03:42:10
|
On Sun, Jan 12, 2014 at 7:25 PM, Georg Zotti <geo...@un...> 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. >> > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel -- Guillaume gui...@gm... +886 970422910 |
From: Guillaume C. <gui...@gm...> - 2014-02-13 08:16:49
|
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 <gui...@gm...> wrote: > On Sun, Jan 12, 2014 at 7:25 PM, Georg Zotti <geo...@un...> 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. >>> >> >> >> ------------------------------------------------------------------------------ >> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >> Learn Why More Businesses Are Choosing CenturyLink Cloud For >> Critical Workloads, Development Environments & Everything In Between. >> Get a Quote or Start a Free Trial Today. >> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >> _______________________________________________ >> Stellarium-pubdevel mailing list >> Ste...@li... >> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > > > > -- > Guillaume > gui...@gm... > +886 970422910 -- Guillaume gui...@gm... +886 970422910 |
From: Georg Z. <geo...@un...> - 2014-02-13 10:36:43
|
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 > <gui...@gm...> wrote: >> On Sun, Jan 12, 2014 at 7:25 PM, Georg Zotti <geo...@un...> >> 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. >>>> |
From: Fabien C. <fab...@gm...> - 2014-02-14 13:22:07
|
Hi Georg, thanks for the detailed email. In term of code, stellarium needs only quite limited opengl features. OpenGL ES2.0 should be enough, or OpenGL 2.1 (on desktop) should also be enough. However, on windows, we should only use the ANGLE version of Qt, from Qt website: "For QtQuick <https://qt-project.org/doc/qt-5.1/qtquick/qtquick-module.html> 2.0 to work, a graphics driver that provides OpenGL 2.1 or higher is required. The Windows default driver provides only OpenGL 1.1, which is not sufficient. To work around this limitation, Qt now includes a version of the ANGLE <http://code.google.com/p/angleproject/> project which is used by default. ANGLE implements the OpenGL ES 2.0 API on top of DirectX 9. ANGLE requires that the DirectX SDK is installed when building Qt." -> So in theory using Qt5 ANGLE version, the requirement on windows should be DirectX 9c, and on Mac/Linux OpenGL 2.1 What kind of advanced features would you like to use in the code? For coming versions of Stellarium, we should try to stop using GraphicsView, i.e. re-implement the base button bars GUI in QtQuick2, and try to preserve our current dialogs code using code like the createWindowContainer stuff mentioned by Guillaume. We should also start to think about a roadmap for moving all GUI to QML. For the basic GUI it should actually not be that difficult, I'm not too sure about the GUI in plugins. Maybe it would be a good opportunity to re-think and simplify the main GUI which is getting a bit too complicated: for example choosing the delta T model should definitely not be something that a regular user see in the main GUI. Fabien On Thu, Feb 13, 2014 at 11:36 AM, Georg Zotti <geo...@un...>wrote: > 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 > > <gui...@gm...> wrote: > >> On Sun, Jan 12, 2014 at 7:25 PM, Georg Zotti <geo...@un...> > >> 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 > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > |
From: Georg Z. <geo...@un...> - 2014-02-14 15:28:42
|
Dear Fabien! I also think that likely everything that's in trunk currently can run in OpenGLES2.0 if that is almost equivalent to OpenGL2.1. However, some of the things that still await integration in scenery3d are based on OpenGL3.2. That 0.12 renderer class update prevented integration, but the return of the previous API for the 0.13 series made me hope again. Meanwhile also newer Intel HD systems support OpenGL4 (at least per specs), so scenery3d should also run on them, if I ever get around successfully calling initializeOpenGLFunctions() and subsequently reactivating Andrei's code. (Unfortunately Andrei is no longer available.) Alex tried to compile Stellarium with MSVC/Qt/ANGLE a few weeks ago, it did not work (cannot remember the details, but I think mostly OpenGL(ES) related errors). I have not tried myself, but a working Cmake/MSVC2012-free/Qt-Angle building path would be a useful starting point to test and adapt to an optional OpenGLES2.0 build. (There is no Qt-Angle for MinGW, and I wouldn't want to have to build it! I only have my Atom 450 netbook to test that, and building Stellarium-MinGW for Qt4.8 took ages, that indicates at least overnight for Qt(?), and that is reportedly difficult), so it's no fun developing with that. Not sure if its already possible to have Angle and non-Angle installed at the same time on a more powerful system, I remember having read it's not possible with Qt5.0. So, if OpenGLES2.0 is just a few #ifdefs apart from "real" OpenGL2.1, there may be two Windows versions: Angle/OpenGLES2 as successor of what used to be "fallback mode" to run on legacy hardware (no problem not to have scenery3d on a travel/mobile-telescope netbook or some 2006 vintage PC), and on the other hand an OpenGL version for systems with OpenGL2.1 and better drivers, where add-ons and plugins with higher OpenGL functions may then easier mix. However, somebody please hit me with a working HOWTO Qt5/OpenGL(ES) tutorial that applies to our class infrastructure. On GUI changes: Some things can be rearranged, but most GUI changes in the last 2 years were also a question of available space. My candidate for relocation would be the projection setting in the "Marks" tab, or generally the first two tabs could be rearranged. I think esp the DeltaT model switch (in the advanced settings anyway) is a unique feature and very useful, if only for a handful of scientists. Maybe a caution like "use only if you know what you are doing" should be added if the default model is not in use, or a tick "Expert Mode" added that deactivates the DeltaT panel if not active? Or add a new tab "Expert settings" to the F2 menu? (This could actually go on a tab together with the Planetarium settings, which are also definitely not for everybody.) Kind regards, Georg On Fr, 14.02.2014, 14:21, Fabien Chéreau wrote: > Hi Georg, > thanks for the detailed email. > > In term of code, stellarium needs only quite limited opengl features. > OpenGL ES2.0 should be enough, or OpenGL 2.1 (on desktop) should also be > enough. However, on windows, we should only use the ANGLE version of Qt, > from Qt website: > "For QtQuick > <https://qt-project.org/doc/qt-5.1/qtquick/qtquick-module.html> > 2.0 > to work, a graphics driver that provides OpenGL 2.1 or higher is required. > The Windows default driver provides only OpenGL 1.1, which is not > sufficient. To work around this limitation, Qt now includes a version of > the ANGLE <http://code.google.com/p/angleproject/> project which is used > by > default. ANGLE implements the OpenGL ES 2.0 API on top of DirectX 9. ANGLE > requires that the DirectX SDK is installed when building Qt." > > -> So in theory using Qt5 ANGLE version, the requirement on windows should > be DirectX 9c, and on Mac/Linux OpenGL 2.1 > What kind of advanced features would you like to use in the code? > > For coming versions of Stellarium, we should try to stop using > GraphicsView, i.e. re-implement the base button bars GUI in QtQuick2, and > try to preserve our current dialogs code using code like the > createWindowContainer > stuff mentioned by Guillaume. > We should also start to think about a roadmap for moving all GUI to QML. > For the basic GUI it should actually not be that difficult, I'm not too > sure about the GUI in plugins. Maybe it would be a good opportunity to > re-think and simplify the main GUI which is getting a bit too complicated: > for example choosing the delta T model should definitely not be something > that a regular user see in the main GUI. > > Fabien > > > > > > On Thu, Feb 13, 2014 at 11:36 AM, Georg Zotti > <geo...@un...>wrote: > >> 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 >> > <gui...@gm...> wrote: >> >> On Sun, Jan 12, 2014 at 7:25 PM, Georg Zotti >> <geo...@un...> >> >> 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 >> Ste...@li... >> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >> > ------------------------------------------------------------------------------ > 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 > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > -- Dipl.-Ing. Dr. Georg Zotti Ludwig Boltzmann Institute for Archaeological Prospection and Virtual Archaeology (LBI ArchPro) Hohe Warte 38 A-1190 Wien |
From: Guillaume C. <gui...@gm...> - 2014-02-19 08:50:14
|
About the compilation problems with ANGLE, I am working on a branch that fixes those issues: https://code.launchpad.net/~stellarium/stellarium/windows-cleanup It is based on r6538 (just before the planet shadow commit, because the shadows have some bugs on my machine). I was able to compile and run this branch both with mingw and msvc 2012 + ANGLE, with the default Qt 5.2 binaries, on windows 7, 32 bit. The major change to make it work with angle is in the CMakeLists, where we should not link with opengl but with the default Qt gui opengl libs. See http://bazaar.launchpad.net/~stellarium/stellarium/windows-cleanup/revision/6542 and http://bazaar.launchpad.net/~stellarium/stellarium/windows-cleanup/revision/6544 Regards, guillaume On Fri, Feb 14, 2014 at 11:28 PM, Georg Zotti <geo...@un...> wrote: > Dear Fabien! > > I also think that likely everything that's in trunk currently can run in > OpenGLES2.0 if that is almost equivalent to OpenGL2.1. However, some of > the things that still await integration in scenery3d are based on > OpenGL3.2. That 0.12 renderer class update prevented integration, but the > return of the previous API for the 0.13 series made me hope again. > Meanwhile also newer Intel HD systems support OpenGL4 (at least per > specs), so scenery3d should also run on them, if I ever get around > successfully calling initializeOpenGLFunctions() and subsequently > reactivating Andrei's code. (Unfortunately Andrei is no longer available.) > > Alex tried to compile Stellarium with MSVC/Qt/ANGLE a few weeks ago, it > did not work (cannot remember the details, but I think mostly OpenGL(ES) > related errors). I have not tried myself, but a working > Cmake/MSVC2012-free/Qt-Angle building path would be a useful starting > point to test and adapt to an optional OpenGLES2.0 build. (There is no > Qt-Angle for MinGW, and I wouldn't want to have to build it! I only have > my Atom 450 netbook to test that, and building Stellarium-MinGW for Qt4.8 > took ages, that indicates at least overnight for Qt(?), and that is > reportedly difficult), so it's no fun developing with that. Not sure if > its already possible to have Angle and non-Angle installed at the same > time on a more powerful system, I remember having read it's not possible > with Qt5.0. > > So, if OpenGLES2.0 is just a few #ifdefs apart from "real" OpenGL2.1, > there may be two Windows versions: Angle/OpenGLES2 as successor of what > used to be "fallback mode" to run on legacy hardware (no problem not to > have scenery3d on a travel/mobile-telescope netbook or some 2006 vintage > PC), and on the other hand an OpenGL version for systems with OpenGL2.1 > and better drivers, where add-ons and plugins with higher OpenGL functions > may then easier mix. However, somebody please hit me with a working HOWTO > Qt5/OpenGL(ES) tutorial that applies to our class infrastructure. > > On GUI changes: Some things can be rearranged, but most GUI changes in the > last 2 years were also a question of available space. My candidate for > relocation would be the projection setting in the "Marks" tab, or > generally the first two tabs could be rearranged. > I think esp the DeltaT model switch (in the advanced settings anyway) is > a unique feature and very useful, if only for a handful of scientists. > Maybe a caution like "use only if you know what you are doing" should be > added if the default model is not in use, or a tick "Expert Mode" added > that deactivates the DeltaT panel if not active? Or add a new tab "Expert > settings" to the F2 menu? (This could actually go on a tab together with > the Planetarium settings, which are also definitely not for everybody.) > > Kind regards, > Georg > > > On Fr, 14.02.2014, 14:21, Fabien Chéreau wrote: >> Hi Georg, >> thanks for the detailed email. >> >> In term of code, stellarium needs only quite limited opengl features. >> OpenGL ES2.0 should be enough, or OpenGL 2.1 (on desktop) should also be >> enough. However, on windows, we should only use the ANGLE version of Qt, >> from Qt website: >> "For QtQuick >> <https://qt-project.org/doc/qt-5.1/qtquick/qtquick-module.html> >> 2.0 >> to work, a graphics driver that provides OpenGL 2.1 or higher is required. >> The Windows default driver provides only OpenGL 1.1, which is not >> sufficient. To work around this limitation, Qt now includes a version of >> the ANGLE <http://code.google.com/p/angleproject/> project which is used >> by >> default. ANGLE implements the OpenGL ES 2.0 API on top of DirectX 9. ANGLE >> requires that the DirectX SDK is installed when building Qt." >> >> -> So in theory using Qt5 ANGLE version, the requirement on windows should >> be DirectX 9c, and on Mac/Linux OpenGL 2.1 >> What kind of advanced features would you like to use in the code? >> >> For coming versions of Stellarium, we should try to stop using >> GraphicsView, i.e. re-implement the base button bars GUI in QtQuick2, and >> try to preserve our current dialogs code using code like the >> createWindowContainer >> stuff mentioned by Guillaume. >> We should also start to think about a roadmap for moving all GUI to QML. >> For the basic GUI it should actually not be that difficult, I'm not too >> sure about the GUI in plugins. Maybe it would be a good opportunity to >> re-think and simplify the main GUI which is getting a bit too complicated: >> for example choosing the delta T model should definitely not be something >> that a regular user see in the main GUI. >> >> Fabien >> >> >> >> >> >> On Thu, Feb 13, 2014 at 11:36 AM, Georg Zotti >> <geo...@un...>wrote: >> >>> 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 >>> > <gui...@gm...> wrote: >>> >> On Sun, Jan 12, 2014 at 7:25 PM, Georg Zotti >>> <geo...@un...> >>> >> 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 >>> Ste...@li... >>> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >>> >> ------------------------------------------------------------------------------ >> 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 >> Ste...@li... >> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >> > > > -- > Dipl.-Ing. Dr. Georg Zotti > Ludwig Boltzmann Institute for > Archaeological Prospection and > Virtual Archaeology > (LBI ArchPro) > Hohe Warte 38 > A-1190 Wien > > > > ------------------------------------------------------------------------------ > 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 > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel -- Guillaume gui...@gm... +886 970422910 |
From: Fabien C. <fab...@gm...> - 2014-02-19 09:06:38
|
Guillaume, that's great news! we discussed with Jörg in IRC, and I think the problem with the planet shadow code are that: - it uses floating point textures - it contains a large loop in the fragment shader. I personally think this code was not ready to be merged in trunk, as there are ways to get rid of both shortcomings. What about we temporarily revert this commit in trunk until the problems are fixed? Jörg would you agree with that? Fabien On Wed, Feb 19, 2014 at 9:49 AM, Guillaume Chéreau < gui...@gm...> wrote: > About the compilation problems with ANGLE, I am working on a branch > that fixes those issues: > > https://code.launchpad.net/~stellarium/stellarium/windows-cleanup > > It is based on r6538 (just before the planet shadow commit, because > the shadows have some bugs on my machine). > > I was able to compile and run this branch both with mingw and msvc > 2012 + ANGLE, with the default Qt 5.2 binaries, on windows 7, 32 bit. > > The major change to make it work with angle is in the CMakeLists, > where we should not link with opengl but with the default Qt gui > opengl libs. > > See > http://bazaar.launchpad.net/~stellarium/stellarium/windows-cleanup/revision/6542 > and > http://bazaar.launchpad.net/~stellarium/stellarium/windows-cleanup/revision/6544 > > Regards, > > guillaume > > > On Fri, Feb 14, 2014 at 11:28 PM, Georg Zotti <geo...@un...> > wrote: > > Dear Fabien! > > > > I also think that likely everything that's in trunk currently can run in > > OpenGLES2.0 if that is almost equivalent to OpenGL2.1. However, some of > > the things that still await integration in scenery3d are based on > > OpenGL3.2. That 0.12 renderer class update prevented integration, but the > > return of the previous API for the 0.13 series made me hope again. > > Meanwhile also newer Intel HD systems support OpenGL4 (at least per > > specs), so scenery3d should also run on them, if I ever get around > > successfully calling initializeOpenGLFunctions() and subsequently > > reactivating Andrei's code. (Unfortunately Andrei is no longer > available.) > > > > Alex tried to compile Stellarium with MSVC/Qt/ANGLE a few weeks ago, it > > did not work (cannot remember the details, but I think mostly OpenGL(ES) > > related errors). I have not tried myself, but a working > > Cmake/MSVC2012-free/Qt-Angle building path would be a useful starting > > point to test and adapt to an optional OpenGLES2.0 build. (There is no > > Qt-Angle for MinGW, and I wouldn't want to have to build it! I only have > > my Atom 450 netbook to test that, and building Stellarium-MinGW for Qt4.8 > > took ages, that indicates at least overnight for Qt(?), and that is > > reportedly difficult), so it's no fun developing with that. Not sure if > > its already possible to have Angle and non-Angle installed at the same > > time on a more powerful system, I remember having read it's not possible > > with Qt5.0. > > > > So, if OpenGLES2.0 is just a few #ifdefs apart from "real" OpenGL2.1, > > there may be two Windows versions: Angle/OpenGLES2 as successor of what > > used to be "fallback mode" to run on legacy hardware (no problem not to > > have scenery3d on a travel/mobile-telescope netbook or some 2006 vintage > > PC), and on the other hand an OpenGL version for systems with OpenGL2.1 > > and better drivers, where add-ons and plugins with higher OpenGL > functions > > may then easier mix. However, somebody please hit me with a working HOWTO > > Qt5/OpenGL(ES) tutorial that applies to our class infrastructure. > > > > On GUI changes: Some things can be rearranged, but most GUI changes in > the > > last 2 years were also a question of available space. My candidate for > > relocation would be the projection setting in the "Marks" tab, or > > generally the first two tabs could be rearranged. > > I think esp the DeltaT model switch (in the advanced settings anyway) is > > a unique feature and very useful, if only for a handful of scientists. > > Maybe a caution like "use only if you know what you are doing" should be > > added if the default model is not in use, or a tick "Expert Mode" added > > that deactivates the DeltaT panel if not active? Or add a new tab "Expert > > settings" to the F2 menu? (This could actually go on a tab together with > > the Planetarium settings, which are also definitely not for everybody.) > > > > Kind regards, > > Georg > > > > > > On Fr, 14.02.2014, 14:21, Fabien Chéreau wrote: > >> Hi Georg, > >> thanks for the detailed email. > >> > >> In term of code, stellarium needs only quite limited opengl features. > >> OpenGL ES2.0 should be enough, or OpenGL 2.1 (on desktop) should also be > >> enough. However, on windows, we should only use the ANGLE version of Qt, > >> from Qt website: > >> "For QtQuick > >> <https://qt-project.org/doc/qt-5.1/qtquick/qtquick-module.html> > >> 2.0 > >> to work, a graphics driver that provides OpenGL 2.1 or higher is > required. > >> The Windows default driver provides only OpenGL 1.1, which is not > >> sufficient. To work around this limitation, Qt now includes a version of > >> the ANGLE <http://code.google.com/p/angleproject/> project which is > used > >> by > >> default. ANGLE implements the OpenGL ES 2.0 API on top of DirectX 9. > ANGLE > >> requires that the DirectX SDK is installed when building Qt." > >> > >> -> So in theory using Qt5 ANGLE version, the requirement on windows > should > >> be DirectX 9c, and on Mac/Linux OpenGL 2.1 > >> What kind of advanced features would you like to use in the code? > >> > >> For coming versions of Stellarium, we should try to stop using > >> GraphicsView, i.e. re-implement the base button bars GUI in QtQuick2, > and > >> try to preserve our current dialogs code using code like the > >> createWindowContainer > >> stuff mentioned by Guillaume. > >> We should also start to think about a roadmap for moving all GUI to QML. > >> For the basic GUI it should actually not be that difficult, I'm not too > >> sure about the GUI in plugins. Maybe it would be a good opportunity to > >> re-think and simplify the main GUI which is getting a bit too > complicated: > >> for example choosing the delta T model should definitely not be > something > >> that a regular user see in the main GUI. > >> > >> Fabien > >> > >> > >> > >> > >> > >> On Thu, Feb 13, 2014 at 11:36 AM, Georg Zotti > >> <geo...@un...>wrote: > >> > >>> 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 > >>> > <gui...@gm...> wrote: > >>> >> On Sun, Jan 12, 2014 at 7:25 PM, Georg Zotti > >>> <geo...@un...> > >>> >> 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 > >>> Ste...@li... > >>> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > >>> > >> > ------------------------------------------------------------------------------ > >> 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 > >> Ste...@li... > >> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > >> > > > > > > -- > > Dipl.-Ing. Dr. Georg Zotti > > Ludwig Boltzmann Institute for > > Archaeological Prospection and > > Virtual Archaeology > > (LBI ArchPro) > > Hohe Warte 38 > > A-1190 Wien > > > > > > > > > ------------------------------------------------------------------------------ > > 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 > > Ste...@li... > > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > > > > -- > Guillaume > gui...@gm... > +886 970422910 > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > |
From: Jörg M. <ne...@gm...> - 2014-02-19 13:28:48
|
Hi, I disabled the shadows for now in the code. I'll try to find a better solution, but I'm quite busy with other stuff right now, so I can't give promises when this will be done. Regards, Jörg Am 2014-02-19 10:06, schrieb Fabien Chéreau: > Guillaume, > > that's great news! > > we discussed with Jörg in IRC, and I think the problem with the planet > shadow code are that: > - it uses floating point textures > - it contains a large loop in the fragment shader. > > I personally think this code was not ready to be merged in trunk, as > there are ways to get rid of both shortcomings. What about we > temporarily revert this commit in trunk until the problems are fixed? > Jörg would you agree with that? > > Fabien > > > > > > On Wed, Feb 19, 2014 at 9:49 AM, Guillaume Chéreau > <gui...@gm... <mailto:gui...@gm...>> wrote: > > About the compilation problems with ANGLE, I am working on a branch > that fixes those issues: > > > https://code.launchpad.net/~stellarium/stellarium/windows-cleanup > <https://code.launchpad.net/%7Estellarium/stellarium/windows-cleanup> > > It is based on r6538 (just before the planet shadow commit, because > the shadows have some bugs on my machine). > > I was able to compile and run this branch both with mingw and msvc > 2012 + ANGLE, with the default Qt 5.2 binaries, on windows 7, 32 bit. > > The major change to make it work with angle is in the CMakeLists, > where we should not link with opengl but with the default Qt gui > opengl libs. > > See > http://bazaar.launchpad.net/~stellarium/stellarium/windows-cleanup/revision/6542 > <http://bazaar.launchpad.net/%7Estellarium/stellarium/windows-cleanup/revision/6542> > and > http://bazaar.launchpad.net/~stellarium/stellarium/windows-cleanup/revision/6544 > <http://bazaar.launchpad.net/%7Estellarium/stellarium/windows-cleanup/revision/6544> > > Regards, > > guillaume > > > On Fri, Feb 14, 2014 at 11:28 PM, Georg Zotti > <geo...@un... <mailto:geo...@un...>> wrote: > > Dear Fabien! > > > > I also think that likely everything that's in trunk currently > can run in > > OpenGLES2.0 if that is almost equivalent to OpenGL2.1. However, > some of > > the things that still await integration in scenery3d are based on > > OpenGL3.2. That 0.12 renderer class update prevented > integration, but the > > return of the previous API for the 0.13 series made me hope again. > > Meanwhile also newer Intel HD systems support OpenGL4 (at least per > > specs), so scenery3d should also run on them, if I ever get around > > successfully calling initializeOpenGLFunctions() and subsequently > > reactivating Andrei's code. (Unfortunately Andrei is no longer > available.) > > > > Alex tried to compile Stellarium with MSVC/Qt/ANGLE a few weeks > ago, it > > did not work (cannot remember the details, but I think mostly > OpenGL(ES) > > related errors). I have not tried myself, but a working > > Cmake/MSVC2012-free/Qt-Angle building path would be a useful > starting > > point to test and adapt to an optional OpenGLES2.0 build. (There > is no > > Qt-Angle for MinGW, and I wouldn't want to have to build it! I > only have > > my Atom 450 netbook to test that, and building Stellarium-MinGW > for Qt4.8 > > took ages, that indicates at least overnight for Qt(?), and that is > > reportedly difficult), so it's no fun developing with that. Not > sure if > > its already possible to have Angle and non-Angle installed at > the same > > time on a more powerful system, I remember having read it's not > possible > > with Qt5.0. > > > > So, if OpenGLES2.0 is just a few #ifdefs apart from "real" > OpenGL2.1, > > there may be two Windows versions: Angle/OpenGLES2 as successor > of what > > used to be "fallback mode" to run on legacy hardware (no problem > not to > > have scenery3d on a travel/mobile-telescope netbook or some 2006 > vintage > > PC), and on the other hand an OpenGL version for systems with > OpenGL2.1 > > and better drivers, where add-ons and plugins with higher OpenGL > functions > > may then easier mix. However, somebody please hit me with a > working HOWTO > > Qt5/OpenGL(ES) tutorial that applies to our class infrastructure. > > > > On GUI changes: Some things can be rearranged, but most GUI > changes in the > > last 2 years were also a question of available space. My > candidate for > > relocation would be the projection setting in the "Marks" tab, or > > generally the first two tabs could be rearranged. > > I think esp the DeltaT model switch (in the advanced settings > anyway) is > > a unique feature and very useful, if only for a handful of > scientists. > > Maybe a caution like "use only if you know what you are doing" > should be > > added if the default model is not in use, or a tick "Expert > Mode" added > > that deactivates the DeltaT panel if not active? Or add a new > tab "Expert > > settings" to the F2 menu? (This could actually go on a tab > together with > > the Planetarium settings, which are also definitely not for > everybody.) > > > > Kind regards, > > Georg > > > > > > On Fr, 14.02.2014, 14:21, Fabien Chéreau wrote: > >> Hi Georg, > >> thanks for the detailed email. > >> > >> In term of code, stellarium needs only quite limited opengl > features. > >> OpenGL ES2.0 should be enough, or OpenGL 2.1 (on desktop) > should also be > >> enough. However, on windows, we should only use the ANGLE > version of Qt, > >> from Qt website: > >> "For QtQuick > >> <https://qt-project.org/doc/qt-5.1/qtquick/qtquick-module.html> > >> 2.0 > >> to work, a graphics driver that provides OpenGL 2.1 or higher > is required. > >> The Windows default driver provides only OpenGL 1.1, which is not > >> sufficient. To work around this limitation, Qt now includes a > version of > >> the ANGLE <http://code.google.com/p/angleproject/> project > which is used > >> by > >> default. ANGLE implements the OpenGL ES 2.0 API on top of > DirectX 9. ANGLE > >> requires that the DirectX SDK is installed when building Qt." > >> > >> -> So in theory using Qt5 ANGLE version, the requirement on > windows should > >> be DirectX 9c, and on Mac/Linux OpenGL 2.1 > >> What kind of advanced features would you like to use in the code? > >> > >> For coming versions of Stellarium, we should try to stop using > >> GraphicsView, i.e. re-implement the base button bars GUI in > QtQuick2, and > >> try to preserve our current dialogs code using code like the > >> createWindowContainer > >> stuff mentioned by Guillaume. > >> We should also start to think about a roadmap for moving all > GUI to QML. > >> For the basic GUI it should actually not be that difficult, I'm > not too > >> sure about the GUI in plugins. Maybe it would be a good > opportunity to > >> re-think and simplify the main GUI which is getting a bit too > complicated: > >> for example choosing the delta T model should definitely not be > something > >> that a regular user see in the main GUI. > >> > >> Fabien > >> > >> > >> > >> > >> > >> On Thu, Feb 13, 2014 at 11:36 AM, Georg Zotti > >> <geo...@un... <mailto:geo...@un...>>wrote: > >> > >>> 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 > >>> > <gui...@gm... > <mailto:gui...@gm...>> wrote: > >>> >> On Sun, Jan 12, 2014 at 7:25 PM, Georg Zotti > >>> <geo...@un... <mailto:geo...@un...>> > >>> >> 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 > >>> Ste...@li... > <mailto:Ste...@li...> > >>> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > >>> > >> > ------------------------------------------------------------------------------ > >> 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 > >> Ste...@li... > <mailto:Ste...@li...> > >> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > >> > > > > > > -- > > Dipl.-Ing. Dr. Georg Zotti > > Ludwig Boltzmann Institute for > > Archaeological Prospection and > > Virtual Archaeology > > (LBI ArchPro) > > Hohe Warte 38 > > A-1190 Wien > > > > > > > > > ------------------------------------------------------------------------------ > > 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 > > Ste...@li... > <mailto:Ste...@li...> > > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > > > > -- > Guillaume > gui...@gm... <mailto:gui...@gm...> > +886 970422910 <tel:%2B886%20970422910> > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > <mailto:Ste...@li...> > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > > > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > > > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel |
From: Alexander W. <ale...@gm...> - 2014-02-13 09:45:00
|
2014-02-13 15:16 GMT+07:00 Guillaume Chéreau <gui...@gm...>: > > Meanwhile what exactly is the problem with the current qml fragment > shader? For me it seems to work on windows, linux and OSX. it was problem with deployment -- With best regards, Alexander |
From: Timothy R. <tr...@si...> - 2014-02-13 15:24:03
Attachments:
signature.asc
|
No, Alex, it was not as simple as a 'problem with deployment'. The problem is that QtQuick is deprecated, and what was in the labs package with 1.0 is now in the main 2.0. This was a bigger issue on Mac; the deployment didn't include the labs modules. Alex has modified so that it does. So for the time being, these deprecated labs modules are still usable; but for how long? On Feb 13, 2014, at 4:44 AM, Alexander Wolf <ale...@gm...> wrote: > > 2014-02-13 15:16 GMT+07:00 Guillaume Chéreau <gui...@gm...>: > > Meanwhile what exactly is the problem with the current qml fragment > shader? For me it seems to work on windows, linux and OSX. > > it was problem with deployment > > > -- > With best regards, Alexander > ------------------------------------------------------------------------------ > 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 > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel |
From: Georg Z. <geo...@un...> - 2014-02-19 11:14:05
|
Dear Guillaume, thank you for working on this. I bought myself out of my Atom troubles with a new travel netbook, Win8.1(OMG!) with AMD APU A4-1200. Not too bad, indeed: OpenGL4.3! Unfortunately, I had to disable the satellites plugin before alpha7 started successfully (?). I tried to build trunk with Qt5.2.1/Angle and MSVC2012/free. Several plugins don't build: Satellites, Telescope, Oculars. I will try with your branch. Kind regards, Georg On Mi, 19.02.2014, 09:49, Guillaume Chéreau wrote: > About the compilation problems with ANGLE, I am working on a branch > that fixes those issues: > > https://code.launchpad.net/~stellarium/stellarium/windows-cleanup > > It is based on r6538 (just before the planet shadow commit, because > the shadows have some bugs on my machine). > > I was able to compile and run this branch both with mingw and msvc > 2012 + ANGLE, with the default Qt 5.2 binaries, on windows 7, 32 bit. > > The major change to make it work with angle is in the CMakeLists, > where we should not link with opengl but with the default Qt gui > opengl libs. > > See > http://bazaar.launchpad.net/~stellarium/stellarium/windows-cleanup/revision/6542 > and > http://bazaar.launchpad.net/~stellarium/stellarium/windows-cleanup/revision/6544 > > Regards, > > guillaume > > > On Fri, Feb 14, 2014 at 11:28 PM, Georg Zotti <geo...@un...> > wrote: >> Dear Fabien! >> >> I also think that likely everything that's in trunk currently can run in >> OpenGLES2.0 if that is almost equivalent to OpenGL2.1. However, some of >> the things that still await integration in scenery3d are based on >> OpenGL3.2. That 0.12 renderer class update prevented integration, but >> the >> return of the previous API for the 0.13 series made me hope again. >> Meanwhile also newer Intel HD systems support OpenGL4 (at least per >> specs), so scenery3d should also run on them, if I ever get around >> successfully calling initializeOpenGLFunctions() and subsequently >> reactivating Andrei's code. (Unfortunately Andrei is no longer >> available.) >> >> Alex tried to compile Stellarium with MSVC/Qt/ANGLE a few weeks ago, it >> did not work (cannot remember the details, but I think mostly OpenGL(ES) >> related errors). I have not tried myself, but a working >> Cmake/MSVC2012-free/Qt-Angle building path would be a useful starting >> point to test and adapt to an optional OpenGLES2.0 build. (There is no >> Qt-Angle for MinGW, and I wouldn't want to have to build it! I only have >> my Atom 450 netbook to test that, and building Stellarium-MinGW for >> Qt4.8 >> took ages, that indicates at least overnight for Qt(?), and that is >> reportedly difficult), so it's no fun developing with that. Not sure if >> its already possible to have Angle and non-Angle installed at the same >> time on a more powerful system, I remember having read it's not possible >> with Qt5.0. >> >> So, if OpenGLES2.0 is just a few #ifdefs apart from "real" OpenGL2.1, >> there may be two Windows versions: Angle/OpenGLES2 as successor of what >> used to be "fallback mode" to run on legacy hardware (no problem not to >> have scenery3d on a travel/mobile-telescope netbook or some 2006 vintage >> PC), and on the other hand an OpenGL version for systems with OpenGL2.1 >> and better drivers, where add-ons and plugins with higher OpenGL >> functions >> may then easier mix. However, somebody please hit me with a working >> HOWTO >> Qt5/OpenGL(ES) tutorial that applies to our class infrastructure. >> >> On GUI changes: Some things can be rearranged, but most GUI changes in >> the >> last 2 years were also a question of available space. My candidate for >> relocation would be the projection setting in the "Marks" tab, or >> generally the first two tabs could be rearranged. >> I think esp the DeltaT model switch (in the advanced settings anyway) >> is >> a unique feature and very useful, if only for a handful of scientists. >> Maybe a caution like "use only if you know what you are doing" should be >> added if the default model is not in use, or a tick "Expert Mode" added >> that deactivates the DeltaT panel if not active? Or add a new tab >> "Expert >> settings" to the F2 menu? (This could actually go on a tab together with >> the Planetarium settings, which are also definitely not for everybody.) >> >> Kind regards, >> Georg >> >> >> On Fr, 14.02.2014, 14:21, Fabien Chéreau wrote: >>> Hi Georg, >>> thanks for the detailed email. >>> >>> In term of code, stellarium needs only quite limited opengl features. >>> OpenGL ES2.0 should be enough, or OpenGL 2.1 (on desktop) should also >>> be >>> enough. However, on windows, we should only use the ANGLE version of >>> Qt, >>> from Qt website: >>> "For QtQuick >>> <https://qt-project.org/doc/qt-5.1/qtquick/qtquick-module.html> >>> 2.0 >>> to work, a graphics driver that provides OpenGL 2.1 or higher is >>> required. >>> The Windows default driver provides only OpenGL 1.1, which is not >>> sufficient. To work around this limitation, Qt now includes a version >>> of >>> the ANGLE <http://code.google.com/p/angleproject/> project which is >>> used >>> by >>> default. ANGLE implements the OpenGL ES 2.0 API on top of DirectX 9. >>> ANGLE >>> requires that the DirectX SDK is installed when building Qt." >>> >>> -> So in theory using Qt5 ANGLE version, the requirement on windows >>> should >>> be DirectX 9c, and on Mac/Linux OpenGL 2.1 >>> What kind of advanced features would you like to use in the code? >>> >>> For coming versions of Stellarium, we should try to stop using >>> GraphicsView, i.e. re-implement the base button bars GUI in QtQuick2, >>> and >>> try to preserve our current dialogs code using code like the >>> createWindowContainer >>> stuff mentioned by Guillaume. >>> We should also start to think about a roadmap for moving all GUI to >>> QML. >>> For the basic GUI it should actually not be that difficult, I'm not too >>> sure about the GUI in plugins. Maybe it would be a good opportunity to >>> re-think and simplify the main GUI which is getting a bit too >>> complicated: >>> for example choosing the delta T model should definitely not be >>> something >>> that a regular user see in the main GUI. >>> >>> Fabien >>> |
From: Georg Z. <geo...@un...> - 2014-02-19 21:38:39
|
I cannot checkout this branch: bzr: ERROR: Permission denied: "Cannot create 'stellarium'. Only Bazaar branches are allowed." I tried bzr co, checkout, branch, nothing works. What kind of repository is that? G. On Mi, 19.02.2014, 12:13, Georg Zotti wrote: > Dear Guillaume, > > thank you for working on this. I bought myself out of my Atom troubles > with a new travel netbook, Win8.1(OMG!) with AMD APU A4-1200. Not too bad, > indeed: OpenGL4.3! Unfortunately, I had to disable the satellites plugin > before alpha7 started successfully (?). > > I tried to build trunk with Qt5.2.1/Angle and MSVC2012/free. Several > plugins don't build: Satellites, Telescope, Oculars. I will try with your > branch. > > Kind regards, > Georg > |
From: Georg Z. <geo...@un...> - 2014-02-20 01:11:02
|
Sorry, I forgot the "~"... G. On Mi, 19.02.2014, 22:38, Georg Zotti wrote: > I cannot checkout this branch: > bzr: ERROR: Permission denied: "Cannot create 'stellarium'. Only Bazaar > branches are allowed." > > I tried bzr co, checkout, branch, nothing works. What kind of repository > is that? > > G. > > On Mi, 19.02.2014, 12:13, Georg Zotti wrote: >> Dear Guillaume, >> >> thank you for working on this. I bought myself out of my Atom troubles >> with a new travel netbook, Win8.1(OMG!) with AMD APU A4-1200. Not too >> bad, >> indeed: OpenGL4.3! Unfortunately, I had to disable the satellites plugin >> before alpha7 started successfully (?). >> >> I tried to build trunk with Qt5.2.1/Angle and MSVC2012/free. Several >> plugins don't build: Satellites, Telescope, Oculars. I will try with >> your >> branch. >> >> Kind regards, >> Georg >> > > > |
From: Guillaume C. <gui...@gm...> - 2014-02-20 03:25:06
|
Oh yes I forgot to mention. The "windows-cleanup" branch might not compile with the plugins yet. For the moment I focus on the core of stellarium. Later I will see if the plugins need modifications. I think a few are using non Opengl ES 2 api, that would prevent them from compiling with ANGLE. gui On Thu, Feb 20, 2014 at 9:10 AM, Georg Zotti <geo...@un...> wrote: > Sorry, I forgot the "~"... > > G. > > On Mi, 19.02.2014, 22:38, Georg Zotti wrote: >> I cannot checkout this branch: >> bzr: ERROR: Permission denied: "Cannot create 'stellarium'. Only Bazaar >> branches are allowed." >> >> I tried bzr co, checkout, branch, nothing works. What kind of repository >> is that? >> >> G. >> >> On Mi, 19.02.2014, 12:13, Georg Zotti wrote: >>> Dear Guillaume, >>> >>> thank you for working on this. I bought myself out of my Atom troubles >>> with a new travel netbook, Win8.1(OMG!) with AMD APU A4-1200. Not too >>> bad, >>> indeed: OpenGL4.3! Unfortunately, I had to disable the satellites plugin >>> before alpha7 started successfully (?). >>> >>> I tried to build trunk with Qt5.2.1/Angle and MSVC2012/free. Several >>> plugins don't build: Satellites, Telescope, Oculars. I will try with >>> your >>> branch. >>> >>> Kind regards, >>> Georg >>> >> >> >> > > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel -- Guillaume gui...@gm... +886 970422910 |
From: Alexander W. <ale...@gm...> - 2014-02-20 13:06:52
|
Hi! 2014-02-20 10:24 GMT+07:00 Guillaume Chéreau <gui...@gm...>: > Oh yes I forgot to mention. The "windows-cleanup" branch might not > compile with the plugins yet. For the moment I focus on the core of > stellarium. Later I will see if the plugins need modifications. I > think a few are using non Opengl ES 2 api, that would prevent them > from compiling with ANGLE. > <gui...@gm...> Ouch... I revert my changes for Angle Measure and Compass plugins :( How you solve problem with gettext & libiconv for MSVC? -- With best regards, Alexander |
From: Fabien C. <fab...@gm...> - 2014-02-20 13:35:12
|
gettext and libiconv are not necesary anymore to build stellarium. I suppressed those dependencies to use Qt translate stuff instead. gettext is required only to generate the .pot, but it's an external tool, and this doesn't need to be done on windows. Fabien On Thu, Feb 20, 2014 at 2:06 PM, Alexander Wolf <ale...@gm...>wrote: > Hi! > > 2014-02-20 10:24 GMT+07:00 Guillaume Chéreau <gui...@gm...> > : > > Oh yes I forgot to mention. The "windows-cleanup" branch might not >> compile with the plugins yet. For the moment I focus on the core of >> stellarium. Later I will see if the plugins need modifications. I >> think a few are using non Opengl ES 2 api, that would prevent them >> from compiling with ANGLE. >> > > <gui...@gm...> > Ouch... I revert my changes for Angle Measure and Compass plugins :( > > How you solve problem with gettext & libiconv for MSVC? > > -- > With best regards, Alexander > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > > |
From: Alexander W. <ale...@gm...> - 2014-02-20 14:57:23
|
Hi! 2014-02-20 20:34 GMT+07:00 Fabien Chéreau <fab...@gm...>: > gettext and libiconv are not necesary anymore to build stellarium. I > suppressed those dependencies to use Qt translate stuff instead. > gettext is required only to generate the .pot, but it's an external tool, > and this doesn't need to be done on windows. > Yes, we shouldn't use translations-* solutions for MSVC. I use Qt 5.2.1 (x86 + x64) + MSVC2012 (x86 + x64) for building windows-cleanup branch. In 32-bit mode I catch fatal error for linker (troubles with linking of the archive management code parts). In 64-bit mode I can build Stellarium (core, without plugins) + make an installer (I fixed the deployment issue for ANGLE libs). But when I try run it I catch of the follow error - class QWindowsEGLStaticContext *__cdecl QWindowsEGLStaticContext::create(void): Could not initialize egl display: error 12289 -- With best regards, Alexander |
From: Guillaume C. <gui...@gm...> - 2014-02-20 16:31:08
|
On Thu, Feb 20, 2014 at 10:57 PM, Alexander Wolf <ale...@gm...> wrote: > I use Qt 5.2.1 (x86 + x64) + MSVC2012 (x86 + x64) for building > windows-cleanup branch. > > In 32-bit mode I catch fatal error for linker (troubles with linking of the > archive management code parts). Maybe this is related to zlib dll? You have to manually set it in your CMakeCache.txt, as msvc does not provide it. For example in my case I have those two lines: //Path to a file. ZLIB_INCLUDE_DIR:PATH=C:/Proj/stellarium/zlib/include //Path to a library. ZLIB_LIBRARY:FILEPATH=C:/Proj/stellarium/zlib/lib/zdll.lib (C:/Proj/stellarium/zlib is the path where I downloaded zlib on my machine). Regards, guillaume > > -- > With best regards, Alexander > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > -- Guillaume gui...@gm... +886 970422910 |
From: Alexander W. <ale...@gm...> - 2014-02-20 16:58:19
|
Hi! 2014-02-20 23:30 GMT+07:00 Guillaume Chéreau <gui...@gm...>: > On Thu, Feb 20, 2014 at 10:57 PM, Alexander Wolf <ale...@gm...> > wrote: > > I use Qt 5.2.1 (x86 + x64) + MSVC2012 (x86 + x64) for building > > windows-cleanup branch. > > > > In 32-bit mode I catch fatal error for linker (troubles with linking of > the > > archive management code parts). > > Maybe this is related to zlib dll? You have to manually set it in > your CMakeCache.txt, as msvc does not provide it. > For example in my case I have those two lines: > > //Path to a file. > ZLIB_INCLUDE_DIR:PATH=C:/Proj/stellarium/zlib/include > //Path to a library. > ZLIB_LIBRARY:FILEPATH=C:/Proj/stellarium/zlib/lib/zdll.lib > > (C:/Proj/stellarium/zlib is the path where I downloaded zlib on my > machine). > Yes, this is was related to zlib-win64 libraries (I fixed PATH now) <gui...@gm...> -- With best regards, Alexander |