Hi Bogdan
That should fix it for the normal user OK. I tend to agree with your other
comments. I am not a programmer in the C++ language but I can program in
QBasic/QB64[gl] quite effectively. I know how to code a program to take care of
anomalies like this.
In the meantime as I said I run multiple versions of Stellarium and now knowing
problem it was easy to edit all the old versions to update the catalogues and
the old stars.ini file to reflect the latest catalogues.
The other problem with the lack of Splash is quite apparently in the opengl
driver for many of the common video displays. This problem does not show in
Linux which uses its own opengl driver and Windows 7 works OK on some displays
where XP on the same computer does not.
Barry
> Date: Wed, 6 Mar 2013 22:42:30 +0200
> From: [email protected]
> To: [email protected]
> Subject: [Stellarium-pubdevel] The defaultStarsConfig.json problem (fixed)
> and its roots
>
> Hello to all.
>
> I choose not to derail further the other thread to reply to this:
>
> On Wed, Mar 6, 2013 at 9:06 AM, Barry Gerdes <[email protected]> wrote:
> >
> > Hi Alex
> >
> > I changed the starconfig.json OK but now the other versions I run do not
> > work.
> > You should have given the new file a slightly different name so it can
> > co-exist in the folder with the old version.
>
> This no longer will be a problem - I've bumped the version number of
> the defaultStarsConfig.json file:
> http://bazaar.launchpad.net/~stellarium/stellarium/trunk/revision/5875
>
> This means that each version of Stellarium will try to read the file
> in the user data directory, find out that its version is off, and
> replace it with that version's own default copy.
>
> This is something that *should* have been noticed and done by Alex
> when he changed the file. It's a bug that would have affected a lot of
> people after the next official release, as the old
> defaultStarsConfig.json would have remained in their user data
> directory, pointing to the old file names - in other words, to files
> not in the installation. And, no, telling users to "reset their
> settings" when they show up to complain is not an acceptable solution.
>
> Stellarium has been using user data directory copies of various files
> for quite some time. By now, touching one of them should cause
> immediately red lights to flash in one's head - "hey, what's going to
> happen to the user copy of that file when the next release rolls
> out?".
>
> What disturbs me is that this is another problem caused by
> Stellarium's lack of good developer culture - in this case, lack of
> attention and/or knowledge of the codebase and insufficient testing.
> At the moment, I can't offer a solution. The only thing that comes
> immediately to my mind is "shouting at people", but that won't be very
> productive. :(
>
> Bogdan
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Stellarium-pubdevel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Stellarium-pubdevel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
