It has almost been a year since Season of KDE, 2011 happened and now its time for Google Summer of Code, 2012. The students’ application period is over now, and this would be a good time to blog about my proposal and thoughts. Choosing to work on KStars and KDE during the summer, if I do get selected, was also not a difficult choice to make. Being connected with KStars for over 10 months now, I had to contribute to KStars something that I could actually relate to. Being a beginner in astronomy, the idea of making KStars more beginner friendly had always been very attractive to me. I was therefore certain that this was what I actually wanted to work on during the summer. I plan to work on two features during the summer coding period. One would be adding a new feature named “What’s Interesting…”. The other feature I would work on is “Star Hopping” in KStars. In the next few sections I will talk about both in slight detail.
This feature will basically be a QML based user interface that will suggest sky objects which are currently visible and interesting.
Interesting refers to the interest of the user. Intermediate users for example would probably not need suggestions on planets and their positions.
Visible sky objects are sky objects meeting the following two conditions:
- The sky object should be visible in the current sky +/- 1 hour.
- Taking into account the location conditions and availability of equipment of the user, the sky objects should not be too difficult to see.
There is already a feature known as “What’s Up Tonight”, which is not of much help at present. This is because the results or suggestions are not personalised. The user should not be suggested to have a look at the Andromeda Galaxy when the location is a city badly polluted with light. So “What’s Interesting…” aims to provide more helpful suggestions in a much more attractive manner through a QML based GUI. Every time “What’s Interesting…” is started by the user, a easy-to-use wizard would open up asking the user for information like his location, location conditions, interests, equipment in possession and specifications. An option to skip all these steps would be provided in case the user wants to use previously stated conditions.
After going through this wizard the “What’s Interesting…” window would show. I have prepared mockups for this window using QML. Screenshots of two such mockups are:
One option not provided in the mockup here for the details view window, is the “Get directions to here”. This option would be there in the details view for deep-sky objects. This would provide the user star hopping directions to the current deep-sky object. These star hopping directions would also be ‘personalised’ by taking into account equipment availability and location conditions of the user.
Location conditions of the user here refers to the amount of light pollution in the area. How to take this into account? For this Bortle Dark-Sky Scale will be used. It is a nine-level numeric scale that measures the naked-eye and stellar limiting magnitude for a particular location. A chart as in here helps to get a better idea. The user will be asked to rate his own sky from 1 to 9 after being provided with such a chart. The limiting magnitude associated with each rating would then.be used as a parameter to screen out deep-sky objects of greater magnitudes (Confusion alert: In astronomy Greater magnitude == Lesser brightness).
Also equipment available to the user will play a role in screening out more sky objects. Specifications of available equipment would be converted into scores for respective equipment such as “Telescope Score” and “Binoculars Score”. Deep-sky objects which require greater scores would be screened out. These implementation details are provided in my proposal in much greater detail.
User Configurable Star Hopping in KStars
Sometimes some sky objects are difficult to view with the naked eye. So it becomes difficult to find their position on the sky and point a telescope at it. Star hopping involves centering a bright naked-eye star in the telescope, looking through the telescope and subsequently working through other stars or other sky-objects as ‘landmarks’ to the desired object. Currently this feature in KStars is in an experimental stage and I plan to work on the following matters during the coding period:
- Replace hard-coded values of limiting magnitude(maglim) and equipment field-of-view(fov) parameters in StarHopper::computePath() for real values.
- Dialog to initiate star hopping that asks user for location conditions (rate the light-pollution in the area according to the Bortle Dark Sky Scale), equipment specifications and the destination star.
- Destination star is to be either selected from a list or selected manually from the skymap.
- Users can currently use “Starhop from here to…” in the popup menu that opens up on right-clicking on the skymap. Now, a new option”Get directions to here…”, enabling users to get star hopping directions to a destination star, to be added in the popup menu.
- Dialog that displays list of star hopping directions to a destination star.
So that was the summary of what I plan to be doing this summer. For a more technical and detailed read, my proposal is available for public viewing at http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/samxan/1.
Hope April 23rd turns out to a happy day! Will keep my spirits high and prepare for college examinations till then.