From: Matthew G. <mat...@gm...> - 2012-02-20 00:51:33
|
Recent changes to use the QT properties system have included the renaming of many core class member functions. In the case of public slots, this directly changes the scripting API. I also don't think the replacements offer any real improvement over the previous names (e.g. getFlagNames vs. isNamesDisplayed). Please change the names back. M |
From: Reaves, T. <tr...@si...> - 2012-02-20 13:59:38
|
I think the changes do add value. isXXXDisplayed will let you know if XXX is displayed. getFlagXXX -especially getFlagNames - tells you nothing. As far as the scripting API goes, the uses should have been updated too. But the scripting API should have insulated any scripts from the names of methods, regardless of if they are in the 'core' or not. That they do not shows a very poor implementation decision on someones part. It leads to fragile scripts. API's change. They improve; if not, they end up like Java. Consistency for the sake of consistency is not a good idea, as much as people like to banter it about. getFlagNames is bad. isNamesDisplayed is better. That this change will cause some scripts to need to be updated may be unfortunate, but that's progress. I do not think the names should be changed back. Providing a release document with the name changes is reasonable. Users would just need to look at the document, and update their scripts accordingly. As an aside, Stellarium does not - and probably never will - use QT. QT is a technology used for playing audio & video. On Sun, Feb 19, 2012 at 7:50 PM, Matthew Gates <mat...@gm...> wrote: > Recent changes to use the QT properties system have included the > renaming of many core class member functions. In the case of public > slots, this directly changes the scripting API. I also don't think > the replacements offer any real improvement over the previous names > (e.g. getFlagNames vs. isNamesDisplayed). > > Please change the names back. > > M > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > |
From: Matthew G. <mat...@gm...> - 2012-02-20 17:45:29
|
Changes to StelModule public slot names are not insulated from the scripting language. Public slots of classes whose instantiated objects are made available to the script engine make up a large part of the scripting API. This is how QTs scripting engine works, and in my view it's a perfectly good way to go about things. This difference between the "core" scripting object and the various StelModule objects is directly resultant from how Stellarium's code is [very deliberately] structured - that the core classes provide a low-level API from which the various StelModule are implemented, with the StelModule's providing a fairly fixed interface to the user. As you mentioned in IRC, using Q_PROPERTY should make things more robust, and other features easier to implement, and I think this is good idea, and work which should be continued. I also agree that API changes are inevitable, and sometimes a good thing. However, API churn is a terrible thing unless there is a compelling reason to do it. Somewhat improved function names has to be measured against this. Probably there are as many opinions about the relative weights as there are developers. I suppose I err on the side on not breaking user scripts in the wild. So what now? In the StelModules which have had the Q_PROPERTY treatment so far, I will revert the name changes (leaving the Q_PROPERTY code). Let's change the rest of the StelModules to use Q_PROPERTY, leaving the names alone for now. Once this is done, it's not such a big task to do an API name change later. M On 20 February 2012 05:59, Reaves, Timothy <tr...@si...> wrote: > I think the changes do add value. isXXXDisplayed will let you know if XXX > is displayed. getFlagXXX -especially getFlagNames - tells you nothing. As > far as the scripting API goes, the uses should have been updated too. But > the scripting API should have insulated any scripts from the names of > methods, regardless of if they are in the 'core' or not. That they do not > shows a very poor implementation decision on someones part. It leads to > fragile scripts. > > API's change. They improve; if not, they end up like Java. Consistency for > the sake of consistency is not a good idea, as much as people like to banter > it about. getFlagNames is bad. isNamesDisplayed is better. That this > change will cause some scripts to need to be updated may be unfortunate, but > that's progress. > > I do not think the names should be changed back. Providing a release > document with the name changes is reasonable. Users would just need to look > at the document, and update their scripts accordingly. > > As an aside, Stellarium does not - and probably never will - use QT. QT is > a technology used for playing audio & video. > > On Sun, Feb 19, 2012 at 7:50 PM, Matthew Gates <mat...@gm...> wrote: >> >> Recent changes to use the QT properties system have included the >> renaming of many core class member functions. In the case of public >> slots, this directly changes the scripting API. I also don't think >> the replacements offer any real improvement over the previous names >> (e.g. getFlagNames vs. isNamesDisplayed). >> >> Please change the names back. >> >> M >> >> >> ------------------------------------------------------------------------------ >> Try before you buy = See our experts in action! >> The most comprehensive online learning library for Microsoft developers >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >> Metro Style Apps, more. Free future releases when you subscribe now! >> http://p.sf.net/sfu/learndevnow-dev2 >> _______________________________________________ >> Stellarium-pubdevel mailing list >> Ste...@li... >> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > |
From: Bernhard Reutner-F. <rep...@gm...> - 2012-02-20 18:15:21
|
On Feb 20, 2012 2:59 PM, "Reaves, Timothy" <tr...@si...> wrote: > > As an aside, Stellarium does not - and probably never will - use QT. QT is a technology used for playing audio & video. Did not look at trunk (or however the current SCM calls it) lately but IIRC, Stellarium _does_ use QT. it does use it to achieve platform-independence in some areas like path handling (think boost::filesystem, but done wrong). Furthermore, we implement theme support (think night mode) and generally GUI elements (think file picker, dialogs in e.g. the configuration dialog and the other function key bound dialogs, including the buttons in the StelBar). So, while it is true that we do not use QT for rendering nor for audio -- since we do not do audio (pity BTW goto could use a wooshing sound ;) -- we do use it to abstract away certain routine tasks. Just as a sidenote for the curious reader! Cheers, |
From: Thomas M. <tom...@gm...> - 2012-02-20 18:20:20
|
I think Timothy was being sarcastic? (Qt is the library/toolkit we use) I tend to agree with Matthew regarding API changes, since many script engine users may not be regular/serious programmers, and don't want to change their scripts too often. Just my opinion! Thanks, Thomas On 20 February 2012 18:15, Bernhard Reutner-Fischer <rep...@gm...> wrote: > On Feb 20, 2012 2:59 PM, "Reaves, Timothy" <tr...@si...> > wrote: >> > >> As an aside, Stellarium does not - and probably never will - use QT. QT >> is a technology used for playing audio & video. > > Did not look at trunk (or however the current SCM calls it) lately but IIRC, > Stellarium _does_ use QT. it does use it to achieve platform-independence in > some areas like path handling (think boost::filesystem, but done wrong). > Furthermore, we implement theme support (think night mode) and generally GUI > elements (think file picker, dialogs in e.g. the configuration dialog and > the other function key bound dialogs, including the buttons in the StelBar). > > So, while it is true that we do not use QT for rendering nor for audio -- > since we do not do audio (pity BTW goto could use a wooshing sound ;) -- we > do use it to abstract away certain routine tasks. > > Just as a sidenote for the curious reader! > > Cheers, > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > |
From: Matthew G. <mat...@gm...> - 2012-02-20 18:29:26
|
Disambiguation required: QT is an abbreviation for Apple's QuickTime (which Stellarium does not use). QT is also Trolltech/Nokia's QT platform independent SDK, which Stellarium does use. M On 20 February 2012 10:20, Thomas Morris <tom...@gm...> wrote: > I think Timothy was being sarcastic? (Qt is the library/toolkit we use) > > I tend to agree with Matthew regarding API changes, since many script > engine users may not be regular/serious programmers, and don't want to > change their scripts too often. Just my opinion! > > Thanks, > Thomas > > On 20 February 2012 18:15, Bernhard Reutner-Fischer > <rep...@gm...> wrote: >> On Feb 20, 2012 2:59 PM, "Reaves, Timothy" <tr...@si...> >> wrote: >>> >> >>> As an aside, Stellarium does not - and probably never will - use QT. QT >>> is a technology used for playing audio & video. >> >> Did not look at trunk (or however the current SCM calls it) lately but IIRC, >> Stellarium _does_ use QT. it does use it to achieve platform-independence in >> some areas like path handling (think boost::filesystem, but done wrong). >> Furthermore, we implement theme support (think night mode) and generally GUI >> elements (think file picker, dialogs in e.g. the configuration dialog and >> the other function key bound dialogs, including the buttons in the StelBar). >> >> So, while it is true that we do not use QT for rendering nor for audio -- >> since we do not do audio (pity BTW goto could use a wooshing sound ;) -- we >> do use it to abstract away certain routine tasks. >> >> Just as a sidenote for the curious reader! >> >> Cheers, >> >> >> ------------------------------------------------------------------------------ >> Try before you buy = See our experts in action! >> The most comprehensive online learning library for Microsoft developers >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >> Metro Style Apps, more. Free future releases when you subscribe now! >> http://p.sf.net/sfu/learndevnow-dev2 >> _______________________________________________ >> Stellarium-pubdevel mailing list >> Ste...@li... >> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >> > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel |
From: Georg Z. <geo...@un...> - 2012-02-20 19:52:26
|
On Mo, 20.02.2012, 19:28, Matthew Gates wrote: > Disambiguation required: > > QT is an abbreviation for Apple's QuickTime (which Stellarium does not > use). > > QT is also Trolltech/Nokia's QT platform independent SDK, which > Stellarium does use. Hey, it's perfectly disambiguated: the second is Qt (lowercase t ;-) While stable scripting APIs are indeed desirable for script authors, replacing confusing names by expressive ones in a consistent way is also a good idea if not done too frequently, and maybe changes should be tracked or announced. Maybe a converter script for old scripts to use the new names would help (sed/awk anybody?). The problem is often getting started for newcomers. What's working, what are the primary concepts (for wide user base, plus an insight part for experts), and for programmers how to make your own modules script-aware. Is there a concise documentation of the currently usable scripting commands? Kind regards, G. > > M > > On 20 February 2012 10:20, Thomas Morris <tom...@gm...> wrote: >> I think Timothy was being sarcastic? (Qt is the library/toolkit we use) >> >> I tend to agree with Matthew regarding API changes, since many script >> engine users may not be regular/serious programmers, and don't want to >> change their scripts too often. Just my opinion! >> >> Thanks, >> Thomas >> >> On 20 February 2012 18:15, Bernhard Reutner-Fischer >> <rep...@gm...> wrote: >>> On Feb 20, 2012 2:59 PM, "Reaves, Timothy" >>> <tr...@si...> >>> wrote: >>>> >>> |
From: Bogdan M. <dag...@gm...> - 2012-02-20 20:45:21
|
On Mon, Feb 20, 2012 at 2:50 AM, Matthew Gates <mat...@gm...> wrote: > Recent changes to use the QT properties system have included the > renaming of many core class member functions. In the case of public > slots, this directly changes the scripting API. I also don't think > the replacements offer any real improvement over the previous names > (e.g. getFlagNames vs. isNamesDisplayed). > > Please change the names back. I just saw the latest changes, revision 5199. The revert to the old names is not complete, see this diff: http://bazaar.launchpad.net/~stellarium/stellarium/trunk/revision/5199?remember=5167&compare_revid=5167 You can use the "files modified" links to jump directly to the changes in the relevant files. I'm going to clean up what I can. Regards, Bogdan Marinov |
From: Matthew G. <mat...@gm...> - 2012-02-21 04:50:13
|
On 20 February 2012 12:45, Bogdan Marinov <dag...@gm...> wrote: > I just saw the latest changes, revision 5199. The revert to the old > names is not complete Sorted, thanks. |
From: Barry G. <bar...@ho...> - 2012-02-20 20:49:42
|
Hi All I agree with Matthew who is also working on the old principal that "if it ain't broke why fix it" The remarks about Qt are irrelevant and a topic for an argumentative forum not this column Getting back to current progress. Members have been crying out for the release of version 1.0.0 but the last 300 odd cosmetic commits have had nothing to do with fixing the core items that are required for the release of version 1.0.0. We have some marvelous talent amonst our regular programmers. How about turning your talents to fixing the core problems associated with the release of version 1.0.0 so we can reach our primary goal. I am not a programmer in the true sense because I don't use C or its derivatives but I can still write effective engineering programs in Qbasic to solve my requirements. I just regularly compile and test the changes as well as possible but do not try every possibility, so i only easily pick up the most glaring mistakes. Barry Gerdes Beaumont Hills Observatory S 33' 41' 44" E 150' 56' 32" > From: mat...@gm... > Date: Mon, 20 Feb 2012 10:28:46 -0800 > To: ste...@li... > Subject: Re: [Stellarium-pubdevel] renaming of members in the core > > Disambiguation required: > > QT is an abbreviation for Apple's QuickTime (which Stellarium does not use). > > QT is also Trolltech/Nokia's QT platform independent SDK, which > Stellarium does use. > > M > > On 20 February 2012 10:20, Thomas Morris <tom...@gm...> wrote: > > I think Timothy was being sarcastic? (Qt is the library/toolkit we use) > > > > I tend to agree with Matthew regarding API changes, since many script > > engine users may not be regular/serious programmers, and don't want to > > change their scripts too often. Just my opinion! > > > > Thanks, > > Thomas > > > > On 20 February 2012 18:15, Bernhard Reutner-Fischer > > <rep...@gm...> wrote: > >> On Feb 20, 2012 2:59 PM, "Reaves, Timothy" <tr...@si...> > >> wrote: > >>> > >> > >>> As an aside, Stellarium does not - and probably never will - use QT. QT > >>> is a technology used for playing audio & video. > >> > >> Did not look at trunk (or however the current SCM calls it) lately but IIRC, > >> Stellarium _does_ use QT. it does use it to achieve platform-independence in > >> some areas like path handling (think boost::filesystem, but done wrong). > >> Furthermore, we implement theme support (think night mode) and generally GUI > >> elements (think file picker, dialogs in e.g. the configuration dialog and > >> the other function key bound dialogs, including the buttons in the StelBar). > >> > >> So, while it is true that we do not use QT for rendering nor for audio -- > >> since we do not do audio (pity BTW goto could use a wooshing sound ;) -- we > >> do use it to abstract away certain routine tasks. > >> > >> Just as a sidenote for the curious reader! > >> > >> Cheers, > >> > >> > >> ------------------------------------------------------------------------------ > >> Try before you buy = See our experts in action! > >> The most comprehensive online learning library for Microsoft developers > >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > >> Metro Style Apps, more. Free future releases when you subscribe now! > >> http://p.sf.net/sfu/learndevnow-dev2 > >> _______________________________________________ > >> Stellarium-pubdevel mailing list > >> Ste...@li... > >> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > >> > > > > ------------------------------------------------------------------------------ > > Try before you buy = See our experts in action! > > The most comprehensive online learning library for Microsoft developers > > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > > Metro Style Apps, more. Free future releases when you subscribe now! > > http://p.sf.net/sfu/learndevnow-dev2 > > _______________________________________________ > > Stellarium-pubdevel mailing list > > Ste...@li... > > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel |
From: Reaves, T. <tr...@si...> - 2012-02-20 21:25:06
|
Barry; look up the Second Law of Thermodynamics. To paraphrase: "if it ain't broke, and you do not continue to fix it, it soon will be broke.' I agree with you that the vast majority of the commits over the last year, maybe even two, have been largely cosmetic. The thing is, that's not likely to change. Stellarium is stagnate; there is not enough energy going into the system to prevent bit-rot. That's unfortunate. We simply no longer have any OpenGL developers. Nor any developers that understand the math behind a good deal of it. So what does that leave? Small, mainly non-consequential cosmetic stuff. The OpenGL state is a real mess. Most of them are attributed to defects in video drivers. This is not likely to be the case. Other apps, doing far more sophisticated OpenGL work than Stellarium, do not seem to suffer this. There are a good deal of driver issues, especially on very low end video cards. But the OpenGL code simply needs to be cleaned up and fixed. I've considered posting to some OpenGL forums asking for any interested developers, but have not come up with a good pitch: "Please fix our code" probably won't get many respondents. :) Start catalogs, and especially DSS objects, could also use a good deal of love. Both in updating catalogs, and implementation of features. Some of the projections are in the same boat. Then there is the whole hot-key fiasco. Which is related to the odd way we handle modules. And on-and-on. Anyway, for this issue, Matthew & I types on IRC today; he is going to commit a reversal of the method renaming, while we both work on the continued property-modification of the code. I'll look into writing a script tool that can be used to updated scripts. Actually, this could be done by simply modifying the script engine to output an updated & corrected version of the script when it is run (that's the way some other tools I use work). On Mon, Feb 20, 2012 at 3:49 PM, Barry Gerdes <bar...@ho...>wrote: > Hi All > > I agree with Matthew who is also working on the old principal that "if it > ain't broke why fix it" > The remarks about Qt are irrelevant and a topic for an argumentative forum > not this column > Getting back to current progress. Members have been crying out for the > release of version 1.0.0 but the last 300 odd cosmetic commits have had > nothing to do with fixing the core items that are required for the > release of version 1.0.0. We have some marvelous talent amonst our regular > programmers. How about turning your talents to fixing the core problems > associated with the release of version 1.0.0 so we can reach our primary > goal. > > I am not a programmer in the true sense because I don't use C or its > derivatives but I can still write effective engineering programs in Qbasic > to solve my requirements. I just regularly compile and test the changes as > well as possible but do not try every possibility, so i only easily pick up > the most glaring mistakes. > > Barry Gerdes > Beaumont Hills Observatory > S 33' 41' 44" E 150' 56' 32" > > > > From: mat...@gm... > > Date: Mon, 20 Feb 2012 10:28:46 -0800 > > To: ste...@li... > > Subject: Re: [Stellarium-pubdevel] renaming of members in the core > > > > > Disambiguation required: > > > > QT is an abbreviation for Apple's QuickTime (which Stellarium does not > use). > > > > QT is also Trolltech/Nokia's QT platform independent SDK, which > > Stellarium does use. > > > > M > > > > On 20 February 2012 10:20, Thomas Morris <tom...@gm...> wrote: > > > I think Timothy was being sarcastic? (Qt is the library/toolkit we use) > > > > > > I tend to agree with Matthew regarding API changes, since many script > > > engine users may not be regular/serious programmers, and don't want to > > > change their scripts too often. Just my opinion! > > > > > > Thanks, > > > Thomas > > > > > > On 20 February 2012 18:15, Bernhard Reutner-Fischer > > > <rep...@gm...> wrote: > > >> On Feb 20, 2012 2:59 PM, "Reaves, Timothy" < > tr...@si...> > > >> wrote: > > >>> > > >> > > >>> As an aside, Stellarium does not - and probably never will - use > QT. QT > > >>> is a technology used for playing audio & video. > > >> > > >> Did not look at trunk (or however the current SCM calls it) lately > but IIRC, > > >> Stellarium _does_ use QT. it does use it to achieve > platform-independence in > > >> some areas like path handling (think boost::filesystem, but done > wrong). > > >> Furthermore, we implement theme support (think night mode) and > generally GUI > > >> elements (think file picker, dialogs in e.g. the configuration dialog > and > > >> the other function key bound dialogs, including the buttons in the > StelBar). > > >> > > >> So, while it is true that we do not use QT for rendering nor for > audio -- > > >> since we do not do audio (pity BTW goto could use a wooshing sound ;) > -- we > > >> do use it to abstract away certain routine tasks. > > >> > > >> Just as a sidenote for the curious reader! > > >> > > >> Cheers, > > > >> > > >> > > >> > ------------------------------------------------------------------------------ > > >> Try before you buy = See our experts in action! > > >> The most comprehensive online learning library for Microsoft > developers > > >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, > MVC3, > > >> Metro Style Apps, more. Free future releases when you subscribe now! > > >> http://p.sf.net/sfu/learndevnow-dev2 > > >> _______________________________________________ > > >> Stellarium-pubdevel mailing list > > >> Ste...@li... > > >> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > > >> > > > > > > > ------------------------------------------------------------------------------ > > > Try before you buy = See our experts in action! > > > The most comprehensive online learning library for Microsoft developers > > > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, > MVC3, > > > Metro Style Apps, more. Free future releases when you subscribe now! > > > http://p.sf.net/sfu/learndevnow-dev2 > > > _______________________________________________ > > > Stellarium-pubdevel mailing list > > > Ste...@li... > > > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > > > > > ------------------------------------------------------------------------------ > > Try before you buy = See our experts in action! > > The most comprehensive online learning library for Microsoft developers > > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > > Metro Style Apps, more. Free future releases when you subscribe now! > > http://p.sf.net/sfu/learndevnow-dev2 > > _______________________________________________ > > Stellarium-pubdevel mailing list > > Ste...@li... > > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > > |
From: Fabien C. <fab...@go...> - 2012-02-20 22:52:22
|
Hi guys, I was just followoing the thread from far away. I also don't like much the getFlagNames naming convention, but I never changed it to avoid breaking all code. In Stellarium we have a standard of using getProperyX and setPropertyX for getter and setter. Now if we want to be consistent we should use getXXXDisplayed or getIsXXXDisplayed rather than just isXXXDisplayed. Mmm, well I guess it's not so critical.. In general I am not against making the APIs more consistent, expecially before version 1.0, but we should also take care at not breaking everything if it's really just a matter of taste. On Mon, Feb 20, 2012 at 22:24, Reaves, Timothy <tr...@si...> wrote: > Barry; look up the Second Law of Thermodynamics. To paraphrase: "if it > ain't broke, and you do not continue to fix it, it soon will be broke.' > > I agree with you that the vast majority of the commits over the last year, > maybe even two, have been largely cosmetic. The thing is, that's not likely > to change. Stellarium is stagnate; there is not enough energy going into > the system to prevent bit-rot. That's unfortunate. We simply no longer > have any OpenGL developers. Nor any developers that understand the math > behind a good deal of it. So what does that leave? Small, mainly > non-consequential cosmetic stuff. I disagree, the real working is going in the plugins now, because the core is quite stable. Even if there is much more to do. > The OpenGL state is a real mess. Most of them are attributed to defects in > video drivers. This is not likely to be the case. Other apps, doing far > more sophisticated OpenGL work than Stellarium, do not seem to suffer this. > There are a good deal of driver issues, especially on very low end video > cards. But the OpenGL code simply needs to be cleaned up and fixed. I've > considered posting to some OpenGL forums asking for any interested > developers, but have not come up with a good pitch: "Please fix our code" > probably won't get many respondents. :) The OpenGL state is not so much a mess as you seem to think, but it is a bit complicated for 2 reasons: - we still support old graphic cards which don't support shaders, and using the fixed pipeline is quite different than using the shaders baed one, so maintaining both is by nature no so simple. - we do a lot of non-standard stuff in Stellarium because we handle non linear projections such as Stereographics, or Hammer Aitoff. To make this work with old openGL <= 1.2 drivers requires to do a lot of computation on the CPU instead of GPU. I spent a lot of time trying to abstract this from the higher level code by working on the StelPainter class, and indeed there are not so many places in the code where you actually need to write openGL calls, which is a good sign. At some point we'll need to decide when we stop support for old graphics drivers, and this will able us to move a large part of the rendering pipe line to the GPU. It will be prbably much faster, but I don't expect the code to become much simpler, maybe the opposite. > Start catalogs, and especially DSS objects, could also use a good deal of > love. Both in updating catalogs, and implementation of features. One year ago I did good progress on DSS display, but had no more time working on that since then. There's still a branch where you can display full sky images somewhere, but I probably won't have time in the next months doing anything on Stellarium :( Bye, Fab > Some of the projections are in the same boat. > > Then there is the whole hot-key fiasco. Which is related to the odd way we > handle modules. > > And on-and-on. > > Anyway, for this issue, Matthew & I types on IRC today; he is going to > commit a reversal of the method renaming, while we both work on the > continued property-modification of the code. I'll look into writing a > script tool that can be used to updated scripts. Actually, this could be > done by simply modifying the script engine to output an updated & corrected > version of the script when it is run (that's the way some other tools I use > work). > > > On Mon, Feb 20, 2012 at 3:49 PM, Barry Gerdes <bar...@ho...> > wrote: >> >> Hi All >> >> I agree with Matthew who is also working on the old principal that "if it >> ain't broke why fix it" >> The remarks about Qt are irrelevant and a topic for an argumentative forum >> not this column >> Getting back to current progress. Members have been crying out for the >> release of version 1.0.0 but the last 300 odd cosmetic commits have had >> nothing to do with fixing the core items that are required for the >> release of version 1.0.0. We have some marvelous talent amonst our regular >> programmers. How about turning your talents to fixing the core problems >> associated with the release of version 1.0.0 so we can reach our primary >> goal. >> >> I am not a programmer in the true sense because I don't use C or its >> derivatives but I can still write effective engineering programs in Qbasic >> to solve my requirements. I just regularly compile and test the changes as >> well as possible but do not try every possibility, so i only easily pick up >> the most glaring mistakes. >> >> Barry Gerdes >> Beaumont Hills Observatory >> S 33' 41' 44" E 150' 56' 32" >> >> >> > From: mat...@gm... >> > Date: Mon, 20 Feb 2012 10:28:46 -0800 >> > To: ste...@li... >> > Subject: Re: [Stellarium-pubdevel] renaming of members in the core >> >> > >> > Disambiguation required: >> > >> > QT is an abbreviation for Apple's QuickTime (which Stellarium does not >> > use). >> > >> > QT is also Trolltech/Nokia's QT platform independent SDK, which >> > Stellarium does use. >> > >> > M >> > >> > On 20 February 2012 10:20, Thomas Morris <tom...@gm...> wrote: >> > > I think Timothy was being sarcastic? (Qt is the library/toolkit we >> > > use) >> > > >> > > I tend to agree with Matthew regarding API changes, since many script >> > > engine users may not be regular/serious programmers, and don't want to >> > > change their scripts too often. Just my opinion! >> > > >> > > Thanks, >> > > Thomas >> > > >> > > On 20 February 2012 18:15, Bernhard Reutner-Fischer >> > > <rep...@gm...> wrote: >> > >> On Feb 20, 2012 2:59 PM, "Reaves, Timothy" >> > >> <tr...@si...> >> > >> wrote: >> > >>> >> > >> >> > >>> As an aside, Stellarium does not - and probably never will - use >> > >>> QT. QT >> > >>> is a technology used for playing audio & video. >> > >> >> > >> Did not look at trunk (or however the current SCM calls it) lately >> > >> but IIRC, >> > >> Stellarium _does_ use QT. it does use it to achieve >> > >> platform-independence in >> > >> some areas like path handling (think boost::filesystem, but done >> > >> wrong). >> > >> Furthermore, we implement theme support (think night mode) and >> > >> generally GUI >> > >> elements (think file picker, dialogs in e.g. the configuration dialog >> > >> and >> > >> the other function key bound dialogs, including the buttons in the >> > >> StelBar). >> > >> >> > >> So, while it is true that we do not use QT for rendering nor for >> > >> audio -- >> > >> since we do not do audio (pity BTW goto could use a wooshing sound ;) >> > >> -- we >> > >> do use it to abstract away certain routine tasks. >> > >> >> > >> Just as a sidenote for the curious reader! >> > >> >> > >> Cheers, >> >> > >> >> > >> >> > >> >> > >> ------------------------------------------------------------------------------ >> > >> Try before you buy = See our experts in action! >> > >> The most comprehensive online learning library for Microsoft >> > >> developers >> > >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, >> > >> MVC3, >> > >> Metro Style Apps, more. Free future releases when you subscribe now! >> > >> http://p.sf.net/sfu/learndevnow-dev2 >> > >> _______________________________________________ >> > >> Stellarium-pubdevel mailing list >> > >> Ste...@li... >> > >> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >> > >> >> > > >> > > >> > > ------------------------------------------------------------------------------ >> > > Try before you buy = See our experts in action! >> > > The most comprehensive online learning library for Microsoft >> > > developers >> > > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, >> > > MVC3, >> > > Metro Style Apps, more. Free future releases when you subscribe now! >> > > http://p.sf.net/sfu/learndevnow-dev2 >> > > _______________________________________________ >> > > Stellarium-pubdevel mailing list >> > > Ste...@li... >> > > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >> > >> > >> > ------------------------------------------------------------------------------ >> > Try before you buy = See our experts in action! >> > The most comprehensive online learning library for Microsoft developers >> > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >> > Metro Style Apps, more. Free future releases when you subscribe now! >> > http://p.sf.net/sfu/learndevnow-dev2 >> > _______________________________________________ >> > Stellarium-pubdevel mailing list >> > Ste...@li... >> > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >> >> >> ------------------------------------------------------------------------------ >> Try before you buy = See our experts in action! >> The most comprehensive online learning library for Microsoft developers >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >> Metro Style Apps, more. Free future releases when you subscribe now! >> http://p.sf.net/sfu/learndevnow-dev2 >> _______________________________________________ >> Stellarium-pubdevel mailing list >> Ste...@li... >> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >> > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > |
From: Reaves, T. <tr...@si...> - 2012-02-21 01:06:45
|
On Mon, Feb 20, 2012 at 5:51 PM, Fabien Chéreau < fab...@go...> wrote: > > The OpenGL state is not so much a mess as you seem to think, but it is > a bit complicated for 2 reasons: > If you think this, you are not paying attention to the defect list. Alex, would you care to chime in on how many OpenGL defects there are in LaunchPad? |
From: Alexander W. <ale...@gm...> - 2012-02-21 02:59:41
|
Greetings! 2012/2/21 Reaves, Timothy <tr...@si...>: >> The OpenGL state is not so much a mess as you seem to think, but it is >> a bit complicated for 2 reasons: > If you think this, you are not paying attention to the defect list. Alex, > would you care to chime in on how many OpenGL defects there are in > LaunchPad? Over 50% of bug reports now related with OpenGL -- With best regards, Alexander |
From: Bogdan M. <dag...@gm...> - 2012-02-22 13:43:24
|
On Tue, Feb 21, 2012 at 4:59 AM, Alexander Wolf <ale...@gm...> wrote: > Greetings! > > 2012/2/21 Reaves, Timothy <tr...@si...>: >>> The OpenGL state is not so much a mess as you seem to think, but it is >>> a bit complicated for 2 reasons: >> If you think this, you are not paying attention to the defect list. Alex, >> would you care to chime in on how many OpenGL defects there are in >> LaunchPad? > > Over 50% of bug reports now related with OpenGL On my count, of 83 open issues (no Fix Committed, no Wishlist), around 20 are related to graphics/OpenGL. A lot of them are duplicates of the basic "broken text" bug. Others appear to be connected to various screen composition managers. Bogdan |
From: Alexander W. <ale...@gm...> - 2012-02-22 13:52:25
|
IMHO: folks, first step - we need found and invite skilled OpenGL programmers and second step - begin discussion about supported versions of OpenGL into Stellarium and OpenGL related bugs. -- With best regards, Alexander |
From: Fabien C. <fab...@go...> - 2012-02-24 14:47:36
|
I don't think we should drop support for non OpenGL ES2 video cards indeed. We can still continue develop the OpenGL 2.0/ES part of the code, it's just more complicated to maintain both in parallel. For the bugs, most of the text-related bug are caused by Qt/opengl driver bugs. It could be that some update on Qt 4.8 will fix the problems. Also, it's almost sure that switching the GUI to QML would also fix the problems, although it's a huge work. Also, when Qt 5 will be released, it will only support OpenGL 2.0 capable video cards, so the question of support will come back in the next months. Fabien On Wed, Feb 22, 2012 at 14:52, Alexander Wolf <ale...@gm...> wrote: > IMHO: folks, first step - we need found and invite skilled OpenGL > programmers and second step - begin discussion about supported > versions of OpenGL into Stellarium and OpenGL related bugs. > > -- > With best regards, Alexander > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel |