[Kstars-devel] KDE/kdeedu/kstars/kstars/skycomponents

[Jason Harris]

Hi James,

On Wednesday 14 December 2005 11:10, James Bowlin wrote:
> My understanding is that you are currently hip deep in converting the
> Qt 3.x code to Qt 4 and are in the process of getting things to compile
> with Qt 4.
>
Yes...slowly but surely.  Emphasis on "slowly" :)

> My plan would be to sit on the sidelines until there is a Qt 4 version
> that actually runs and then jump in and first port my "Rey Constellations"
> changes to the Qt 4 version and then work on speeding things up with
> hashes. In the meantime, I plan on completing my work of adding genetive
> star names from the "Sky Atlas 2000.0" to the hip001.dat file.
>
That sounds like a good plan.  I had hoped to have a fully-compiling version 
of KStars by the end of the year, but I'm not sure if I will be able to meet 
that.  Depends on how the rest of the porting goes.  I might have everything 
except the tools and indi working by then, but maybe not.  

Oh, I should also mention that I am going to be out of town for much of 
January (observing in Chile, then a meeting in Washington DC), and I won't be 
able to work on porting while I'm away.  I'm really starting to regret having 
a powerbook instead of a linux laptop :)

> I've also been thinking about making a slight change to the hip???.dat
> file format.  Currently each data line ends with an optional variable
> length "name" followed by an optional fixed length "genetive name". Every
> star with a name, now has a genetive name.  I think it would be a littler
> neater if the fixed length "genetive name" came before the variable length
> "name".  A genetive name of all spaces could be used in new cases where a
> "name" is needed but no genetive name exists.  This may be a nit and I
> think it should be a lower priority than all of the above, but I think it
> should be done eventually and a major version bump seems like an
> appropriate time.  I would also provide a small Perl program for updating
> hip.dat type files in case some people are using custom hip files that I am
> not aware of. It may even be possible to make the C++ code that reads these
> files slightly forgiving so that it gracefully accepts both formats. This
> shouldn't impose a speed penalty since the process should still be I/O
> bound.
>
Yes, good idea.

> Another idea I had would be to add code that prevents text labels on the
> skymap from bumping into one another and that also automatically decides
> how much detail to show as the map zooms in and out.  Open source code to
> do this sort of thing already exists in projects such as MapServer,
> http://mapserver.gis.umn.edu/index.html which I've worked with in the past.
> But this is a big project and I don't think it should be part of the 4.0
> effort.  I have no interest in pursuing it further until after 4.0 is out
> the door.
>
> PLMK if you think any or all of the above is reasonable.  Also, LMK if
> you think there are other areas where it would be more useful for me
> to direct my efforts.
>
I'm really glad to have your contributions; I try not to direct people's 
efforts, I prefer to let you scratch your own itches.  It's more fun all 
around that way :)

regards,
Jason

-- 
-------------------------------
KStars: KDE Desktop Planetarium
http://edu.kde.org/kstars