Projects/Edu/KStars/JuniorJobs: Difference between revisions

From KDE TechBase
< Projects‎ | Edu‎ | KStars
(2017 updates)
Line 18: Line 18:
== The Tasks ==
== The Tasks ==


<strike>
=== Migrate KPlotting classes to QCustomPlot or Qt Charts ===
=== Update KStars Handbook ===


[https://docs.kde.org/stable5/en/kdeedu/kstars/index.html KStars Manual] is a detailed guide for end users to explore all the features and functionality of KStars in great depth. Sometimes KStars developers get very busy working on improving code and adding features while neglecting to update the handbook. Furthermore, a lot of the screenshots in the handbook are out of date. The task involves going over the handbook, which is written in a simple [http://www.docbook.org/ DocBook] format, and editing it as necessary to reflect the latest KStars release. This includes capturing and editing screenshots to replace old ones or add new screen captures where necessary.
Many classes in KStars are still using KPlotting library but since it is not actively developed, we would like to migrate away either to QCustomPlot class or Qt Charts module. You can start by migrating the AVT widget from KPlotting to QCustomPlot or Qt Charts.


Absolutely no programming knowledge is necessary, just use KStars and update the handbook as needed!
=== Investigate NEOs ===
</strike>
 
Job Completed Successfully by '''Cojocaru Raphael'''!
 
<strike>
=== Improve Altitude vs. Time tool ===
 
KStars Altitude vs. Time tool is one of the widely used tools in KStars and enables the user to plot objects' altitude changes versus time. Improve the tool to enable zoom and pan operations, and also to mark rise/transit/set times on the tool. The tool depends on the venerable KDE Plotting Library which was developed by KStars original author Jason Harris. However, KStars now also uses the [http://www.qcustomplot.com/ QCustomPlot] library which provides several improvements over the standard KDE plotting library. You can either keep using the existing KDE Plotting Library or migrate the tool to QCustomPlot with the following features:
* Zoom/Pan
* Rise/Transit/Set markers (if not cirumpolar). If the object is not circumpolar, add three buttons for Rise/Transit/Set. When clicking these buttons, the crosshair on the plot is updated to the new time/altitude intersection.
* Input boxes for both Time and Altitude: If a user changes the time, the altitude at that time is displayed. If the user changes the altitude, the time of that altitude is displayed.
</strike>
 
Job Completed Successfully by '''Cojocaru Raphael'''!


We import asteroid/comets data from JPL and update their regularly. However, some NEOs are missing and not imported from JPL. A web-query is generated and sent to JPL and then a file downloaded and parsed by KStars. This web query was not updated in a long time and should be updated to make sure all asteroids, including NEOs are properly imported. For example, 2003 YT1 is missing from KStars but it exists in JPL database. Find out how JPL spits out the data and construct a proper POST query to obtain the correct required data set for KStars.


=== Display FWHM and Star Profile in FITS Viewer ===
=== Display FWHM and Star Profile in FITS Viewer ===
Line 45: Line 31:


Start by looking at how stars are detected and how HFR is calculated in FITSData class. Then calculate FWHM and construct a simple stellar profile diagram if the user clicks on a particular star.
Start by looking at how stars are detected and how HFR is calculated in FITSData class. Then calculate FWHM and construct a simple stellar profile diagram if the user clicks on a particular star.
<strike>
=== Port What's Interesting tool to QML 2 ===
What's Interesting is a KStars tool written in QML/QtQuick 1.0 that finds the most interesting objects visible to the user given light pollution levels among other parameters. With the migration to Qt5, the tool is not longer operational and requires porting to QML 2. Most of the migration work for QML 2 is complete, but someone needs to take on the last extra mile to get it in a working condition again.
</strike>
Job Completed Successfully by '''Artem Fedoskin'''!


=== Auto-suggest well-placed objects for observation / imaging ===
=== Auto-suggest well-placed objects for observation / imaging ===
Line 65: Line 43:


For more details, contact Akarsh Simha
For more details, contact Akarsh Simha
=== DSS Overlay ===
Superimpose DSS images unto the SkyMap at different zoom levels. The user would be able to turn on/off the overlay which would be useful in checking what the real sky actually looks like at this exact location and at this particular zoom level. The overlay has to be consistent with the projection system in use, and must be careful not to tax the user's RAM (i.e. uses progressive smart loading) and should be usable on low-powered devices as well.
Contact Jasem or Akarsh for more details.


=== Debug the Sky Calendar ===
=== Debug the Sky Calendar ===
Line 98: Line 70:
Implementing this will fix a whole lot of translation-related bugs that are on our bugzilla, and make life for people who use localized versions easier.
Implementing this will fix a whole lot of translation-related bugs that are on our bugzilla, and make life for people who use localized versions easier.


=== Generalize JupiterMoons ===
=== Fix JupiterMoons ===


This was originally a GSoC idea, but I thought it was a bit too "small" for a whole summer. The idea is to implement a class that handles moons of planets in the solar system in KStars.
This was originally a GSoC idea, but I thought it was a bit too "small" for a whole summer. The idea is to implement a class that handles moons of planets in the solar system in KStars. Calculations for Jupiter Moons are incorrect which forced us to disable the tool until it is fixed. Identify what is wrong the algorithm and fix it.


Currently, we have the JupiterMoons classes. What should be done now, is to pack the machinery that goes into this class into a generic class (probably called 'SolarSystemMoons'), various instances of which, could represent the moons of Jupiter, Saturn, Mars...
Currently, we have the JupiterMoons classes. What should be done now, is to pack the machinery that goes into this class into a generic class (probably called 'SolarSystemMoons'), various instances of which, could represent the moons of Jupiter, Saturn, Mars...


All our class would need to do, to assume the form of say, JupiterMoons, would be to read off data corresponding to JupiterMoons from some file, say "solarsystemmoons.dat"!
All our class would need to do, to assume the form of say, JupiterMoons, would be to read off data corresponding to JupiterMoons from some file, say "solarsystemmoons.dat"!
Now, the next task...


=== Generalize the Jupiter's Moons Tool ===
=== Generalize the Jupiter's Moons Tool ===

Revision as of 08:32, 25 January 2017

What this page is about

This page is intended to list out some small jobs that, if completed, would help KStars become better and more usable. There are both easy ones and hard ones.

If you are interested in contributing to KStars, but don't know where to start, this is probably the best place.

Keeping track of Development

The best way to keep track of Development in KStars is to use the mailing list: [email protected] See The List Information Page to subscribe.

If you prefer IRC, we hang out on #kde-kstars on irc.freenode.org

We keep track of bugs and wishlists on The KDE bugzilla

Please do not hesitate to ask if you need help with contributing! We're always looking out for contributors and will be happy to help you out.

The Tasks

Migrate KPlotting classes to QCustomPlot or Qt Charts

Many classes in KStars are still using KPlotting library but since it is not actively developed, we would like to migrate away either to QCustomPlot class or Qt Charts module. You can start by migrating the AVT widget from KPlotting to QCustomPlot or Qt Charts.

Investigate NEOs

We import asteroid/comets data from JPL and update their regularly. However, some NEOs are missing and not imported from JPL. A web-query is generated and sent to JPL and then a file downloaded and parsed by KStars. This web query was not updated in a long time and should be updated to make sure all asteroids, including NEOs are properly imported. For example, 2003 YT1 is missing from KStars but it exists in JPL database. Find out how JPL spits out the data and construct a proper POST query to obtain the correct required data set for KStars.

Display FWHM and Star Profile in FITS Viewer

KStars FITS Viewer tool can calculate the overall Half-Flux-Radius (HFR) of stars in an image by summing each star's own HFR and then taking the average. Some users are interested to know the HFR of a single star, in addition to Full-Width-Half-Modulation (FWHM) and star profile (pixel distance from center vs. intensity). A tool-tip like popup when clicking on individual stars in the FITS image would be ideal as it would give users a quick access to some important information regarding a particular star.

Start by looking at how stars are detected and how HFR is calculated in FITSData class. Then calculate FWHM and construct a simple stellar profile diagram if the user clicks on a particular star.

Auto-suggest well-placed objects for observation / imaging

Aim: To auto-suggest objects that are well-placed in the night sky to users

Step 1: Move the wishlist feature into a database and support multiple wishlists, and rename it to something else. Ship pre-loaded wish-lists along with KStars, of varying levels of difficulty / experience / instrument requirements.

Step 2: Create a backend that will efficiently determine which objects are well-placed (lower than some threshold airmass set by the user) from one or more wishlists.

Step 3: Create a UI that will present one well-placed object to the user. The user may skip objects / cycle through suggestions. Skipped objects should not be displayed for a long time.

For more details, contact Akarsh Simha

Debug the Sky Calendar

The Sky Calendar tool lives in the Tools menu of KStars. The tool now has the labels that it needed badly. However, some lines still don't get labelled because the code isn't robust. The tool also fails at high latitudes. It would be helpful if the Sky Calendar was made complete and bug-free.

Add Lunar Eclipses

KStars doesn't predict Lunar Eclipses. Neither does it display them. It would be really useful if it could do these things.

One way to do this would be to create a virtual Sky Point, maybe called 'EarthShadow', whose position would be just opposite the sun. An eclipse will be a conjunction between EarthShadow and the moon.

Another possible way to do it is to add functionality to KSMoon, so that we check if the moon is in the shadow of the earth before drawing its image.

Fix refraction bugs

Because the refraction correction and its inverse are not perfect inverses, there are a whole bunch of problems when refraction corrections are turned on. It would greatly help KStars if this was fixed.

Fix all those translation bugs

Now, this is a big task.

SkyObject classes (see skyobject.h under kstars/skyobjects) should have some standard way of storing names. Currently, some SkyObjects store untranslated names and some store translated names, leading to a big mess. SkyObject should probably store untranslated name strings internally, and return untranslated names upon calling name(). The objectNames() hashes should ideally have untranslated names as well.

So how do we find by translated name? The best way, probably is to have a "reverse translation hash". Since very few objects have translated names, it might be easy to maintain a global hash of translated names vs. untranslated names in some convenient place (probably as a static member of SkyComposite) and do searches for translated names through this.

Implementing this will fix a whole lot of translation-related bugs that are on our bugzilla, and make life for people who use localized versions easier.

Fix JupiterMoons

This was originally a GSoC idea, but I thought it was a bit too "small" for a whole summer. The idea is to implement a class that handles moons of planets in the solar system in KStars. Calculations for Jupiter Moons are incorrect which forced us to disable the tool until it is fixed. Identify what is wrong the algorithm and fix it.

Currently, we have the JupiterMoons classes. What should be done now, is to pack the machinery that goes into this class into a generic class (probably called 'SolarSystemMoons'), various instances of which, could represent the moons of Jupiter, Saturn, Mars...

All our class would need to do, to assume the form of say, JupiterMoons, would be to read off data corresponding to JupiterMoons from some file, say "solarsystemmoons.dat"!

Generalize the Jupiter's Moons Tool

See Tools -> Jupiter's Moons. What if I could do this in general with SolarSystemMoons? [See earlier task for details]

Comets that looks like comets!

Comets in KStars are currently drawn as dull green circles (at least in the default color scheme). That's not what they look like, in reality!

The machinery required to estimate nucleus and coma sizes, and tail lengths of comets are all there in KSComet and KSPlanetBase. What needs to be done, is to provide a proper representation of a comet based on these data on the Sky Map.

Remember that a comet's tail points away from the Sun! You can use this to fix the direction of the tail - so you have all information required to draw the comet.

Re-implement CometsComponent::draw() to draw better comets.

Peng "Charles" Chang has already done a good amount of work to support this feature. It needs some polishing, though.

And...

Fix those inconsistencies with comets

Jeamy Lee, a KStars user and contributor, notices that our Sun-Comet distances are wrong! This makes all calculated parameters come out incorrectly. Find his mail with some details here.

Ideas are welcome!

If you are a user of KStars and have some cool, simple ideas that would make your experience with KStars better, you are welcome to add them to the list above, or discuss them on the kstars-devel mailing list (or post them as wishlists / bug reports on the bugzilla).