Improved variable-speed slewing. Instead of a kludgy mess of nested if's to
implement a triangular speed profile, I am now using much simpler code to
implement a cosine-shaped profile.
There's a little bit of asymmetry in the profile (i.e., the ending speed doesn't
quite get down to the level of the starting speed, so the ending is a little bit
abrupt). This is a consequence of the speed being determined for position r, and
then applied over the interval (r+dr). The solution is to make the determined
speed the average of speed(r) and speed(r+dr), but I'm not sure it's worth the
extra math. Let me know if the asymmetry is bothersome, or if you have a clean
solution for it...
Introducing variable-speed slewing. When you move to a new position, rather than
slewing at a uniform rate, the speed will gradually increase to a maximum value,
then slow down as the target is approached.
Try it out and let me know what you think. Is this appealing enough that we can
just discard uniform slews, or should users be given the option?
The ImageViewer dialog has Save and Close buttons, but due to a layout problem,
they were not visible in the window. I added a QFrame container for the image
canvas and the text caption, and made this container the dialog's mainWidget.
This makes the dialog buttons visible again.
Unfortunately, it also causes a pretty thick margin to be added around the
image/caption. Maybe a designer file for the dialog could solve this issue, but
at least the Save button is accessible again. Too bad it's too late for 4.1...
Committing patch from Prakash to make the Find dialog more flexible. You can now
omit spaces when searching for M/NGC/IC objects.
i.e., "m51" will match to "M 51".
Reverting r829109 (removing KStarsData pointers from function args).
As discussed on the mailing list, it would be wise to postpone such pervasive
"code cleanup" changes until after our two branches have been merged back into
trunk.
All of the reverted changes remain on my local disk, awaiting the merge.
Remove KStarsData pointers from function argument lists (use
KStarsData::Instance() instead).
Stage 1: SkyComponents.
I have added a protected KStarsData* member to SkyComponent (so all
Components/Composites inherit this member). The pointer is assigned to
KStarsData::Instance() in the component's init() function.
Question: does it make sense to store this pointer as a member, or should we
simply call KStarsData::Instance() locally in the functions that need it?
Note: I made init() pure virtual in abstract classes (i.e., "virtual void init() =
0;" instead of "virtual void init() {}") to make sure they can't be instantiated.
As a result of this change, I had to add a CustomCatalogComposite class, because I
had been using a SkyComposite directly to store our custom catalog components, and
I decided that SkyComposite should be an abstract class.
Applying variable timestep patch from trunk (r827206).
Akarsh, your commit message mentioned fixing a few bugs that my original patch
revealed...was there anything besides reducing the tolerance of findPrecise() to 1
minute?
Also adding a nice progress bar that appears in place of the Compute button while
the computation takes place, and then disappears when it's done.
TODO:
+ it would be nice to see conjunctions added to the results box as they are found,
rather than waiting until the computation is finished.
+ Add a "Show conjunction" button that will set the date/time to the time found by
the tool for the highlighted event, and set the focus to Object1.
