1. 17 Jan, 2004 1 commit
  2. 16 Jan, 2004 1 commit
  3. 15 Jan, 2004 1 commit
  4. 14 Jan, 2004 1 commit
    • Pablo de Vicente's avatar
      Fixed a bug when precessing from 1950.0 to any epoch different of J2000. · 8e687040
      Pablo de Vicente authored
      I just needed to recompute cosine and sine of RA and Dec once precession
      from B1950 to J2000 was completed, so that precession from J2000 to the
      target epoch was done correctly.
      All the other cases: B1950 to J2000 or any epoch != B1950 to any epoch
      worked fine.
      CCMAIL: kstars-devel@kde.org
      svn path=/trunk/kdeedu/kstars/; revision=279779
  5. 07 Jan, 2004 2 commits
    • Jason Harris's avatar
      Fixing Bug #71829: star is not i18n · 1abd5731
      Jason Harris authored
      It's a bit complicated, but essentially:  We keep several name-strings for
      each object, including the untranslated English Name [name()], the
      translated name [translatedName()], and a long name [longName()].
      We display the "long name" of sky objects in the status bar and the
      popup menu.  In the case of unnamed stars, the "long name" was being
      assigned the non-localized name "star".  We now are using
      "translatedName()" in SkyObject::setLongName(), so it
      should work.  Please test.
      Incidental fixes: Fixed three instances where we compare the untranslated
      name to "i18n("star")" instead of just "star" in starobject.cpp and
      CCMAIL: 71829-done@bugs.kde.org
      CCMAIL: kstars-devel@kde.org
      svn path=/trunk/kdeedu/kstars/; revision=277683
    • Jason Harris's avatar
      Fixing Bug #71826: "Nize does not exist". Removing "Nize, France" from · d16a94b6
      Jason Harris authored
      Cities.dat.  We already have "Nice, France".
      CCMAIL: 71826-done@bugs.kde.org
      svn path=/trunk/kdeedu/kstars/; revision=277674
  6. 05 Jan, 2004 1 commit
    • Jason Harris's avatar
      Fixing bug 69953: text of View Toolbar buttons is too long. As a · e7ee84e9
      Jason Harris authored
      workaround, I am suppressing displaying text on these buttons.  After the
      strings freeze, I can remove this restriction and simply make the text of
      each button shorter.  I'd actually be interested whether you'd prefer that
      or just leaving text off altogether.
      CCMAIL: 69953-done@bugs.kde.org
      CCMAIL: kstars-devel@kde.org
      svn path=/trunk/kdeedu/kstars/; revision=277071
  7. 04 Jan, 2004 2 commits
  8. 02 Jan, 2004 3 commits
    • Pablo de Vicente's avatar
      Fixed non-UTF8 characters in some city names, which seemed to produce · df848839
      Pablo de Vicente authored
      repetitive fuzzies. This was demanded by some translators in the kde-i18n-doc
      list this week. I think that the error came from someone who converted this
      file to UTF8 when it already was UTF8; this bug has been dragging for one
      year now.
      IMHO the best way to modify to file is to do:
       iconv -f utf8 -t iso-8859-1 Cities.dat -o Cities.dat.iso
      then edit Cities.dat.iso with any editor and convert back to UTF8
       iconv -f iso8859-1 -t utd8 Cities.dat.iso -o Cities.dat
      CCMAIL: kstars-devel@kde.org
      CCMAIL: kde-i18n-doc@kde.org
      svn path=/trunk/kdeedu/kstars/; revision=276147
    • Jason Harris's avatar
      One more fix that I noticed while addressing the previous bug report fix: · 589965dd
      Jason Harris authored
      In the WUT tool, the displayed Moon Illumination fraction did not change
      when changing the date inside the tool.  Fixed.
      CCMAIL: kstars-devel@kde.org
      svn path=/trunk/kdeedu/kstars/; revision=276080
    • Jason Harris's avatar
      Fixing last portion of compound BR #71520. The reporter found that the · 0cf03144
      Jason Harris authored
      WUT tool did not report that the Moon and Venus were up on the night of 26
      Dec. 2003.  He provided photographic evidence that they were, in fact,
      visible that night :)
      The problem was in our definition of what to consider "up" on a given
      night.  Naively, one might just consider whether the object is above the
      horizon at any time between sunset and sunrise.  However, what we really
      want to know is, can one *observe* a given object from a given location,
      on a given night?  In this case, we want to know if the object is above
      the horizon between the end of evening twilight and the beginning of
      morning twilight, not the moments of sunset and sunrise.
      Twilight is defined to end or begin when the Sun is at a certain negative
      altitude below the horizon.  There are three kinds of twilight: civil
      twilight (alt=-6 deg), nautical twilight (alt=-12 deg) and astronomical
      twilight (alt=-18 deg).  In KStars, we had been using -20 degrees, which
      is close to astronomical twilight.
      However, this is probably too strict, especially for planets and the moon
      which are often easily visible low in the sky during twilight.  We are now
      using the definition of civil twilight, -6 degrees, to determine whether
      an object is visible.
      Wow, four paragraphs to explain a one-line change in the code.  :)  Sorry
      abot that!
      CCMAIL: 71520@bugs.kde.org
      CCMAIL: kstars-devel@kde.org
      svn path=/trunk/kdeedu/kstars/; revision=276066
  9. 01 Jan, 2004 1 commit
    • Jason Harris's avatar
      partial fix of BR #71469. User reported that position of Sunset and · fa78ae88
      Jason Harris authored
      Sunrise in the Altitude vs. Time tool did not actually follow the correct
      times for a given Date and Location, they were hardcoded at 06:00 and
      18:00.  This is now fixed.  Please test the changes
      I am unable to reproduce the main part of bug report (altitude curves not
      updating when changing Date or Location), however.  I'd appreciate it if
      people could attempt to reproduce it and report to the mailing list.
      CCMAIL: kstars-devel@kde.org
      CCMAIL: 71469-done@bugs.kde.org
      svn path=/trunk/kdeedu/kstars/; revision=275952
  10. 31 Dec, 2003 2 commits
    • Jason Harris's avatar
      Fixing bug #71520 ("Strange behavior of What's up tonight"). Problem · 538a2b2a
      Jason Harris authored
      traced to the fact that planet positions were not recomputed when user
      changed the Date inside the tool.  In order to fix, I am using the
      SkyObject::computeCoordsForJD() function.  I also had to make this
      function public.
      Incidental fix:  wutdialog.cpp had code that was meant to always exclude
      the Sun from the list of visible objects, but the code only worked for
      English, because it compared the translated name to the untranslated name.
      In addition, the same code also excluded the Moon.  However, the Moon
      should NOT be excluded like this, so I removed that part.
      (note that part 3 of this bug report, regarding the date format displayed
      in WUT, was found to be invalid).
      Thank you for the detailed bug reports!
      CCMAIL: kstars-devel@kde.org
      CCMAIL: 71520-done@bugs.kde.org
      svn path=/trunk/kdeedu/kstars/; revision=275815
    • Jason Harris's avatar
      Display localized name of objects in the Altitude vs. Time Tool. This · 2c712625
      Jason Harris authored
      fixes one of the three issues reported in BR #71469.  This fix
      does not break the strings freeze, we simply call
      SkyObject::translatedName() instead of SkyObject::name().
      svn path=/trunk/kdeedu/kstars/; revision=275806
  11. 24 Dec, 2003 2 commits
    • Pablo de Vicente's avatar
      Fixed a subtle bug when converting from a QString to a dms object. · ad39b5f4
      Pablo de Vicente authored
      The bug appeared when integer degrees were cero, integer minutes were
      negative and seconds were not null. For example: "00 -02 30" was considered
      to be "-2+30/60.", whereas it should be "-2-30/60." However "00 00 -30" was
      computed correctly.
      The criteria now is, if any of the fields "dd" or "mm" or "ss" is negative
      the angle is considered to be negative.
      CCMAIL: kstars-devel@kde.org
      svn path=/trunk/kdeedu/kstars/; revision=274716
    • Pablo de Vicente's avatar
      Allows to convert between equatorial and galactic coordinates using · de679101
      Pablo de Vicente authored
      any epoch for the former coordinates.
      This option was not coded before resulting in a bug when the epoch of the
      equatorial coordinates was not B1950. To avoid the bug we used a
      workaround: we locked the epoch in the UI file to always be 1950.0.
      With the present change we have unlocked the epoch field in the UI file
      and one can choose any epoch for the equatorial cooordinates. The change
      consists on adding precession from the input epoch to B1950. That is, if
      one goes from Equatorial to Galactic. the order is:
       - precession of equatorial coordinates from the given epoch to B1950
       - conversion from equatorial to galactic coordinates
      If one goes from Galactic to Equatorial, the order is:
       - conversion from galactic to equatorial coordinates
       - precession of equatorial coordinates from B1950 to the given epoch.
      CCMAIL: kstars-devel@kde.org
      svn path=/trunk/kdeedu/kstars/; revision=274712
  12. 23 Dec, 2003 1 commit
  13. 21 Dec, 2003 2 commits
    • Stephan Binner's avatar
      +GenericName · 9bb9b809
      Stephan Binner authored
      svn path=/trunk/kdeedu/kstars/; revision=274163
    • Pablo de Vicente's avatar
      Fixed a bug first pointed out by Mikhail Zotov in a private communication, · b16889e1
      Pablo de Vicente authored
      who noticed that precession between B1950 to J2000 as done by KStars does not
      coincide with the results given by SIMBAD (http://simbad.u-strasbg.fr/sim-fidl.pl).
      M. Zotov has not opened yet a bug in bugs.kde.org, so I have no bug
      number to refer to in this commit.
        The bug comes from the fact that conversion between coordinates in B1950
      to J2000 (and viceversa) involves changing from (old) catalog FK4 to FK5,
      and a simple precesion, as done by KStars is not enough.
        To fix this bug I have used the following reference:
      Smith, C. A.; Kaplan, G. H.; Hughes, J. A.; Seidelmann, P. K.; Yallop,
      B. D.; Hohenkerk, C. Y.
      Astronomical Journal, vol. 97, Jan. 1989, p. 265-279
      The conversion between the FK4 catalog and the FK5 catalog requires 4 steps:
      - Drop E-Terms in B1950 coordinates. In the past, the mean places of
        stars published in the FK4 catalog included the contribution to the
        aberration due to the ellipticity of the orbit of the Earth. These terms,
        known as E-terms were almost constant, and in the newer FK5 catalog they
        are not included.
      - Precess from B1950 to 1984, January 1st, at 0h, using the parameters
        given by the Astronomische Rechen-Institut.
      - Apply the zero-point correction to the right ascensions to correct for the
        equinox error of the FK4. This is done for 1984, Jan 1st, at 0h.
      - Precess from 1984 Jan 1st at 0h, to J2000 using the new precessional
      This bug may seem not important since KStars produced (before this patch)
      a result which is almost correct, but since the conversion between B1950
      and J2000 is done very frequently among astronomers it needs to be corrected.
      Jason Harris has told me to go on with this commit since HEAD is opened again
      for these kind of fixes.
      CCMAIL: kstars-devel@kde.org
      svn path=/trunk/kdeedu/kstars/; revision=274130
  14. 19 Dec, 2003 1 commit
    • Jason Harris's avatar
      Fixes to LocationDialog: · 4e484b73
      Jason Harris authored
      + Adding a new city now records the correct time zone offset in the
      mycities.dat file.
      + Pressing the "Clear Fields" button now sets the TZ offset to "0.00"
      instead of "-2.00"
      (Both of these problems arose because I was assuming that the TZ
      listbox had 24 entries (one for each integer-hour TZ).  However, this
      is no longer true, we have some non-integer timezones as well.)
      + The TZ combobox no longer contains duplicate entries.  I had used
      setDuplicatesEnabled(false), but this doesn't affect entries added
      programmatically, so we have to check for duplicates manually.
      CCMAIL: kstars-devel@kde.org
      svn path=/trunk/kdeedu/kstars/; revision=273820
  15. 16 Dec, 2003 2 commits
    • Jasem Mutlaq's avatar
      Two important fixes: · e0dc871f
      Jasem Mutlaq authored
      1. The telescope port name is now stored in kstarsrc.
      2. The Telescope Connection Wizard no longer causes the celestron driver to crash upon connection.
      The celestron driver update frequency is at 1 Hz now (instead of 0.5 Hz), please test this with a celestron telescope. Use the Wizard and let it automatically scan ports, this should work now.
      CCMAIL: kstars-devel@kde.org
      CCMAIL: quinn@zdomain.com
      CCMAIL: alesan@manoweb.com
      svn path=/trunk/kdeedu/kstars/; revision=273426
    • Jasem Mutlaq's avatar
      A misplaced paranthesis caused the celestron driver to crash at occasions. Fixed. · b3383bed
      Jasem Mutlaq authored
      svn path=/trunk/kdeedu/kstars/; revision=273292
  16. 11 Dec, 2003 1 commit
  17. 08 Dec, 2003 3 commits
    • Jason Harris's avatar
      Fixing bug #64827: one user reported that pressing "n" (to go to the · 66a14d28
      Jason Harris authored
      north point above the horizon) resulted in a blank screen.  I suspected
      that the porblem was somehow related to the azimuth angle being set to
      exactly 0.0 degrees (although I don't really understand why that should
      cause a problem).  The reporter confirmed that changing the code to set
      Az=0.0001 fixes the problem.  Implementing this as a workaround.
      CCMAIL: kstars-devel@kde.org
      CCMAIL: 64827-done@bugs.kde.org
      svn path=/trunk/kdeedu/kstars/; revision=272011
    • Jason Harris's avatar
      Fixing bug #69288 (and then some). · 8bc668bd
      Jason Harris authored
      Bug report indicated that Hamburg, Germany had two entries in Cities.dat.
      Found and removed this one and another 38 duplicate entries.  When two
      entries for the same City had significantly different coordintes, I
      attempted to verify the correct location with a google search.
      CCMAIL: kstars-devel@kde.org
      CCMAIL: 69288-done@bugs.kde.org
      svn path=/trunk/kdeedu/kstars/; revision=272004
    • Jason Harris's avatar
      Now that 3.2beta2 is out, back to our regularly-scheduled bug squashing... · f1d33ab2
      Jason Harris authored
      Fixing bug #68401: The "Set Focus Manually" tool will now correctly handle
      decimal-point symbol l10n.
      Because the QString::toDouble() function requires a "." decimal point, we
      simply replace all instances of locale()->decimalSymbol() with "." before
      parsing the entry as a decimal value.
      I tested it by manually setting my decimal symbol to "," in the control
      center; it works fine for me now.
      CCMAIL: kstars-devel@kde.org
      CCMAIL: 68401-done@bugs.kde.org
      svn path=/trunk/kdeedu/kstars/; revision=271995
  18. 05 Dec, 2003 1 commit
  19. 01 Dec, 2003 1 commit
  20. 28 Nov, 2003 6 commits
  21. 21 Nov, 2003 1 commit
  22. 14 Nov, 2003 1 commit
  23. 10 Nov, 2003 1 commit
  24. 08 Nov, 2003 2 commits
    • Jason Harris's avatar
      Removed debug statement · 26011c96
      Jason Harris authored
      svn path=/trunk/kdeedu/kstars/; revision=265458
    • Jason Harris's avatar
      Fixed problems at RA=0, Dec=0. · 78950c9a
      Jason Harris authored
      The Earth was being selected as the clickedObject when clicking at RA=0,
      Dec=0.  Removed the Earth from PlanetCatalog::findClosest().
      There are several hundred objects in the NGC/IC catalog with no
      coordinates.  These were being drawn at RA=0, Dec=0.  Added a check to
      KStarsData::readDeepSkyData() that ignores lines with blank space in the
      coordinate fields.  Also, several dozen deep-sky objects had RA=00:00:00.0
      Dec=00:00:00, but these should have been blank also.  Fixed.
      CCMAIL: kstars-devel@kde.org
      svn path=/trunk/kdeedu/kstars/; revision=265456