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

[James Bowlin]

On Wednesday 14 December 2005 12:12 am, you wrote:
> Thanks for the tip.  Are you interested in taking a stab at it?  In any case, 
> I'll read up on the QHash docs.

Yes, I would be interested in working on this.   I am a newbie to this
code and to Qt so I would be much more comfortable waiting for a version
of the 4.0 code that compiles and runs before diving in.

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.

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.

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.

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.


-- 
Peace, James