KStars ist eine kostenlose, plattformübergreifende Open-Source-Astronomiesoftware.
Es bietet eine genaue grafische Simulation des Nachthimmels, von jedem Ort auf der Erde, zu jedem Datum und zu jeder Uhrzeit. Die Ausstellung umfasst bis zu 100 Millionen Sterne, 13.000 Deep-Sky-Objekte, alle 8 Planeten, Sonne und Mond sowie Tausende von Kometen, Asteroiden, Supernovae und Satelliten.
Für Schüler und Lehrer unterstützt es einstellbare Simulationsgeschwindigkeiten, um Phänomene zu betrachten, die über lange Zeiträume auftreten, den KStars-Astrorechner zur Vorhersage von Konjunktionen und viele gängige astronomische Berechnungen. Für den Amateurastronomen bietet es einen Beobachtungsplaner, ein Himmelskalender-Tool und einen FOV-Editor, um das Sichtfeld der Ausrüstung zu berechnen und anzuzeigen. Finden Sie interessante Objekte im Tool „Was ist heute Abend los“, zeichnen Sie Höhen-Zeit-Diagramme für jedes Objekt, drucken Sie hochwertige Himmelskarten und erhalten Sie Zugriff auf zahlreiche Informationen und Ressourcen, die Ihnen bei der Erkundung des Universums helfen!
Im Lieferumfang von KStars ist die Astrofotografie-Suite Ekos enthalten, eine komplette Astrofotografielösung, die alle INDI-Geräte steuern kann, darunter zahlreiche Teleskope, CCDs, DSLRs, Fokussierer, Filter und vieles mehr. Ekos unterstützt hochpräzises Tracking mithilfe von Online- und Offline-Astrometrie-Lösern, Autofokus- und Autoguiding-Funktionen sowie die Erfassung einzelner oder mehrerer Bilder mithilfe des leistungsstarken integrierten Sequenzmanagers.
Copyright (c) 2001 - 2024 beim KStars-Team:
KStars ist freie Software, die unter der GNU Public License veröffentlicht wird. Informationen zur GPL-Lizenz finden Sie unter KOPIEREN.
KStars ist für Windows, MacOS und Linux verfügbar. Sie können die neueste Version von der offiziellen Website von KStars herunterladen.
Unter Linux ist es für die meisten Linux-Distributionen verfügbar.
Die neueste stabile Version ist v3.6.8
Die KStars-Homepage
KStars Git-Repository
KStars-Webchat
Forum, in dem oft über KStars diskutiert wird
Das KStars-Handbuch finden Sie in Ihrem Verzeichnis $(KDEDIR)/share/doc/HTML//kstars/. Sie können es auch einfach über das Hilfemenü aufrufen, indem Sie die Taste [F1] drücken oder https://docs.kde.org/?application=kstars besuchen. Leider ist es etwas veraltet. Wir freuen uns über Freiwillige, die bei der Aktualisierung helfen.
Darüber hinaus gibt es folgende README-Dateien:
README: Diese Datei; Allgemeine Informationen README.planetmath: Erläuterung der Algorithmen zur Berechnung von Planetenpositionen README.customize: Erweiterte Anpassungsoptionen README.images: Copyright-Informationen für in KStars verwendete Bilder. README.i18n: Anleitung für Übersetzer
Über das KStars-Repository kann Code geklont, angezeigt und Zusammenführungsanfragen gestellt werden. Wenn Sie mit Remote-Git-Repositorys noch nicht vertraut sind, lesen Sie bitte den Abschnitt „Git-Tipps“ unten. Hinweis: Bisher verwendete KStars Phabricator für seine Zusammenführungsanfragen. Dieses System wird nicht mehr verwendet.
Wenn Sie vorhaben, KStars zu entwickeln, wird dringend empfohlen, eine IDE zu verwenden. Sie können jede IDE Ihrer Wahl verwenden, wir empfehlen jedoch QtCreator (https://www.qt.io/product) oder KDevelop (https://www.kdevelop.org), da sie besser für die Qt/KDE-Entwicklung geeignet sind.
Um KStars in QtCreator zu öffnen, wählen Sie die Datei CMakeLists.txt im KStars-Quellordner aus und konfigurieren Sie dann den Build-Speicherort und -Typ.
Vorausgesetzte Pakete
Um KStars zu erstellen und zu entwickeln, sind möglicherweise mehrere Pakete Ihrer Distribution erforderlich. Hier ist eine Liste.
Erforderliche Abhängigkeiten
GNU Make, GCC – Wesentliche Werkzeuge zum Erstellen
cmake – von KDE verwendetes Buildsystem
Qt-Bibliothek > 5.12.0
Mehrere KDE-Frameworks: KConfig, KDocTools, KGuiAddons, KWidgetsAddons, KNewStuff, KI18n, KInit, KIO, KXmlGui, KPlotting, KIconThemes
eigen – lineare Algebra-Bibliothek
zlib – Komprimierungsbibliothek
StellarSolver – siehe https://github.com/rlancaste/stellarsolver
Optionale Abhängigkeiten
libcfitsio – FITS-Bibliothek
libindi – Instrumentenneutrale verteilte Schnittstelle zur Steuerung von Geräten.
xplanet
astrometry.net
libraw
wcslib
libgsl
qtkeychain
Voraussetzungen installieren
Debian/Ubuntu
Der Befehl apt-add-respository wird für den libstellarsolver-dev von apt-get benötigt. Alternativ können Sie das apt-add-repository überspringen, libstellarsolver-dev aus apt-get entfernen und stellarsolver von https://github.com/rlancaste/stellarsolver erstellen und installieren.
sudo apt-add-repository ppa:mutlaqja/ppa sudo apt-get -y install build-essential cmake git libstellarsolver-dev libxisf-dev libeigen3-dev libcfitsio-dev zlib1g-dev libindi-dev extra-cmake-modules libkf5plotting-dev libqt5svg5-dev libkf5xmlgui-dev libkf5kio-dev kinit-dev libkf5newstuff-dev libkf5doctools-dev libkf5notifications-dev qtdeclarative5-dev libkf5crash-dev gettext libnova-dev libgsl-dev libraw-dev libkf5notifyconfig-dev wcslib-dev libqt5websockets5-dev xplanet xplanet-images qt5keychain-dev libsecret-1-dev breeze-icon-theme libqt5datavisualization5-dev
Fedora
yum install cfitsio-devel eigen3-devel stellarsolver-devel cmake extra-cmake-modules.noarch xisf-devel kf5-kconfig-devel kf5-kdbusaddons-devel kf5-kdoctools-devel kf5-kguiaddons-devel kf5-ki18n-devel kf5-kiconthemes-devel kf5-kinit-devel kf5-kio-devel kf5-kjobwidgets-devel kf5-knewstuff-devel kf5-kplotting-devel kf5-ktexteditor-devel kf5-kwidgetsaddons-devel kf5-kwindowsystem-devel kf5-kxmlgui-devel libindi-devel libindi-static qt5-qtdeclarative-devel qt5-qtmultimedia-devel qt5-qtdatavis3d-devel qt5-qtsvg-devel wcslib-devel xplanet zlib-devel
Kompilieren
Öffnen Sie eine Konsole und führen Sie die folgenden Befehle aus:
mkdir -p ~/Projects/build/kstars cd ~/Projects git clone https://invent.kde.org/education/kstars.git cd build/kstars cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=RelWithDebInfo ~/Projects/kstars make -j16 sudo make install
Um KStars auszuführen, geben Sie einfach kstars in das Terminal ein.
KStars verwendet Artistic Style, um alle C++-Quelldateien zu formatieren. Bitte stellen Sie sicher, dass Sie die folgenden Astyle-Regeln auf jeden Code anwenden, der an INDI übermittelt wird. Unter Linux können Sie eine Datei ~/.astylerc erstellen, die die folgenden Regeln enthält:
--style=allman --align-reference=name --indent-switches --indent-modifiers --indent-classes --pad-oper --indent-col1-comments --lineend=linux --max-code-length=124
Einige IDEs (z. B. QtCreator) unterstützen die automatische Formatierung des Codes jedes Mal, wenn Sie die Datei auf der Festplatte speichern.
Führen Sie unter Linux Folgendes aus, um die erforderlichen Programme zu installieren:
sudo apt-get install docbook docbook-utils
Die Quelle für das Handbuch befindet sich in kstars/doc. Sie können diese Dateien bearbeiten und sie wie C++-Dateien in Commits und MRs einbinden (siehe unten). Sie können das Markup anhand eines Beispiels herausfinden oder aus dem Online-Dokument für Docbook lernen. Im Allgemeinen ist es am besten, zuerst das gesamte Verzeichnis kstars/doc in ein temporäres Verzeichnis zu kopieren und dort das Handbuch zu bearbeiten und zu generieren, denn wenn Sie meinproc im Hauptquellverzeichnis ausführen würden, würden Sie dort viele .html-Dateien generieren und Sie Sie möchten die generierten Dateien nicht in Ihr Git-Repository übertragen.
cp -pr kstars/doc ~/DOCBOOK cd ~/DOCBOOK meinproc5 index.docbook
Das Obige sollte HTML-Dateien generieren. Dann können Sie in einem Browser einfach DOCBOOK/index.html öffnen und zu dem gewünschten Teil navigieren, z. B. geben Sie einfach etwas Ähnliches in die URL-Leiste von Chrome ein: file:///home/IHR_BENUTZERNAME/DOCBOOK/ doc/tool-ekos.html Nehmen Sie Änderungen an einigen der .docbook-Dateien in ~/DOCBOOK/*.docbook vor. Generieren Sie die HTML-Dateien neu und sehen Sie sich Ihre Änderungen wie zuvor im Browser an. Iterieren.
Um die Syntax zu überprüfen, möchten Sie möglicherweise Folgendes ausführen:
checkXML5 index.docbook
Wenn Sie zufrieden sind, kopieren Sie Ihre geänderten Dateien zurück nach kstars/doc und behandeln Sie die bearbeiteten/neuen Dateien wie gewohnt mit Git, einschließlich Ihrer geänderten Dateien in einem neuen Commit und schließlich einer neuen Zusammenführungsanforderung.
Im folgenden Abschnitt, Git-Tipps, finden Sie technische Einzelheiten zum Generieren einer Zusammenführungsanforderung. Bei der Antragstellung müssen Sie die Anfrage beschreiben. Bitte verwenden Sie ein ähnliches Format, das Abschnitte für eine Zusammenfassung dessen enthält, was getan wurde, was in den einzelnen Dateien geändert wurde, andere relevante Hinweise und wie Sie Ihre Änderungen testen können.
Sie müssen mit Git vertraut sein, um Änderungen an KStars vorzunehmen, und dies ist nicht der Ort für ein solches Tutorial. Dafür gibt es im Internet viele hervorragende Ressourcen. Der folgende Absatz gibt jedoch einen Überblick über eine Möglichkeit, eine Zusammenführungsanfrage zu stellen, vorausgesetzt, Sie verfügen bereits über ausreichende Git-Erfahrung, um KStars zu klonen, einen lokalen Zweig zu erstellen, den Code nach Ihren Wünschen zu ändern, Ihre Änderungen in Ihren lokalen Zweig zu übernehmen, und testen Sie Ihren Code gründlich.
Hier ist eine gute Ressource für einen Fork-Branch-Git-Workflow, um KStars-Änderungen vorzunehmen. Die folgenden Schritte sind von dieser Seite inspiriert.
Einmalige Einrichtung der KStars-Git-Umgebung.
Erstellen Sie Ihre KDE-Identität
Login. Gehen Sie zur KStars-Gitlab-Seite und melden Sie sich in der oberen rechten Ecke an.
Forken Sie das Projekt. Klicken Sie dann, immer noch auf der Gitlab-Seite von KStars, oben rechts auf FORK, um Ihren eigenen Fork des Projekts zu erstellen.
Kopieren Sie Ihre URL. Notieren Sie sich die URL Ihres Forks. Es sollte https://invent.kde.org/YOUR_KDE_NAME/kstars sein
KStars klonen. Führen Sie diese Befehle auf Ihrem Computer aus
mkdir -p ~/Projekte
cd ~/Projekte
Git-Klon https://invent.kde.org/YOUR_KDE_NAME/kstars
CD kstars
Fügen Sie Ihren Upstream hinzu. Fügen Sie das KStars-Hauptrepo zu Ihrem gespaltenen Repo hinzu.
git remote upstream hinzufügen https://invent.kde.org/education/kstars
Sie sind jetzt eingerichtet.
Für jede Änderung verwendete Schritte. Nach der einmaligen Einrichtung (oben) können die folgenden Schritte für jede neue Feature-Einreichung verwendet werden. Zusammenfassend erstellen Sie einen Feature-Zweig in Ihrem lokalen Repository, nehmen dort die gewünschten Änderungen vor und testen sie, übertragen sie auf Ihren Fork, erstellen eine Anfrage zum Zusammenführen Ihres Forks mit dem Haupt-KStars-Repo, warten auf Feedback und iterieren möglicherweise auf Ihrem Änderungen in der Hoffnung auf die Zustimmung einer Behörde.
Erstellen Sie Ihren Feature-Zweig.
git checkout -b YOUR_BRANCH_NAME
Nehmen Sie Ihre Änderungen vor
Übernehmen Sie Ihre Änderungen
git commit -a
Übertragen Sie Änderungen an Ihr geforktes Repo.
Git-Push-Ursprung YOUR_BRANCH_NAME
Erstellen Sie eine Zusammenführungsanforderung
Besuchen Sie mit Ihrem Browser Ihr geforktes Repo unter https://invent.kde.org/YOUR_KDE_NAME/kstars
Sie sollten eine Option zum Erstellen einer Zusammenführungsanfrage für YOUR_BRANCH_NAME sehen. Geben Sie die Details ein (siehe Abschnitt oben).
Sie sollten eine neue URL für diese Zusammenführungsanforderung sehen können.
Nehmen Sie einige Änderungen vor. Möglicherweise erhalten Sie Anfragen, einen Teil Ihres Codes zu ändern.
Wenn ja, gehen Sie einfach zu Ihrer örtlichen Zweigstelle zurück, nehmen Sie Ihre Änderungen vor und testen Sie sie.
Übernehmen Sie Ihre Änderungen wie oben beschrieben in Ihrem Zweig mit: git commit -a
Übertragen Sie die Änderungen Ihres Zweigs wie oben beschrieben in Ihr gespaltenes Repo mit: git push origin YOUR_BRANCH_NAME
Ihre Änderungen sollten automatisch zu Ihrer Zusammenführungsanfrage hinzugefügt werden. Schauen Sie zur Sicherheit auf der Seite der Zusammenführungsanforderung nach.
Möglicherweise müssen Sie Ihren Code umbasieren – Einzelheiten finden Sie weiter unten.
Rebasieren Sie Ihre Änderungen. Andere nehmen möglicherweise Änderungen an KStars vor, während Sie an Ihrer Funktion arbeiten. Beim Rebasing handelt es sich um die Aktualisierung Ihrer KStars-Version und Ihrer spezifischen Änderungen, sodass es so aussieht, als ob Sie die neueste KStars-Version geändert hätten, z. B. Änderungen an der Codebasis widerspiegeln, die vorgenommen wurden, nachdem Sie Ihre eigene KStars-Kopie geklont oder aktualisiert haben. Dies ist ein wichtiges Thema, das Sie googeln können, aber die folgenden Anweisungen funktionieren meistens.
Beachten Sie, dass dies geschieht, bevor Sie Ihre Zusammenführungsanforderung erstellen, wenn Sie der Einzige sind, der Ihre Codeänderungen sieht. Sobald Sie Ihre Zusammenführungsanforderung gestartet haben, ist Ihr Code „öffentlich“ und Sie sollten statt einer Neubasierung dem nachstehenden Zusammenführungsverfahren folgen.
cd ~/Projects/kstars git checkout master git pull upstream master # Get the master from the main KStars repo onto your local clone git push origin master # Then push your updated local clone into your forked repo git checkout YOUR_BRANCH_NAME git rebase master git push origin YOUR_BRANCH_NAME -f
Wenn es beim Rebase zu Komplikationen kommt, macht Git Vorschläge zur Behebung der Probleme.
Die Änderungen anderer zusammenführen. Sobald Sie eine Zusammenführungsanfrage senden, kann Ihr Code von anderen gesehen (und bearbeitet) werden. Obwohl Sie zu diesem Zeitpunkt möglicherweise noch auf die neueste KStars-Version aktualisieren müssen, werden durch die Neubasierung Änderungsinformationen zerstört und die Aktionen anderer können überschrieben werden. Stattdessen ist es am besten, die aktuelle Version von KStars in Ihren Code einzubinden.
cd ~/Projects/kstars git checkout master git pull upstream master # Get the master from the main KStars repo onto your local clone git push origin master # Then push your updated local clone into your forked repo git checkout YOUR_BRANCH_NAME git merge master git push origin YOUR_BRANCH_NAME
Die Unterschiede zum Rebase-Abschnitt sind die letzten beiden Befehle: „git merge master“ wird anstelle von „git rebase master“ verwendet. Außerdem verwendet „Git Push“ nicht die Option -f. Wenn Sie „git push“ zum ersten Mal ausführen, werden Sie möglicherweise von Git aufgefordert, „set-upstream origin“ zum Befehl hinzuzufügen. Befolgen Sie in diesem Fall diese Anweisungen.
Wenn Sie diesem Verfahren folgen, wird dem Git-Protokoll Ihrer Zweigstelle ein neues „Merge-Commit“ hinzugefügt.
Ihre nächste Änderung . Sobald Ihre Zusammenführungsanfrage abgeschlossen (und möglicherweise in KStars integriert) ist, möchten Sie möglicherweise weitermachen und sich erneut weiterentwickeln. Bei der nächsten Änderung wird ein weiterer (neuer) Feature-Zweig verwendet, und der erste Feature-Zweig könnte gelöscht werden. Möglicherweise möchten Sie Folgendes regelmäßig ausführen, um Ihren Master-Zweig mit KStars auf dem neuesten Stand zu halten.
cd ~/Projects/kstars git checkout master git pull upstream master # Get the master from the main KStars repo onto your local clone git push origin master # Then push your updated local clone into your forked repo
Tests werden im Ordner Tests
gespeichert und verwenden QTest als Support-Framework:
Einheitliche Tests finden sich in auxiliary
, capture
“, fitsviewer
“ usw. Sie versuchen, das Verhalten einer minimalen Menge von Klassen zu überprüfen und unterstützen die Funktionsentwicklung.
UI-Tests finden Sie in kstars_lite_ui
und kstars_ui
. Sie führen Anwendungsfälle so aus, wie es der Endbenutzer über die Benutzeroberfläche tun würde, und konzentrieren sich auf die Verfügbarkeit von visuellem Feedback und die Stabilität der Verfahren.
Entscheiden Sie, wo Ihr neuer einheitlicher Test unter Tests
gespeichert werden soll. KStars-Klassen sollten sich in einem Ordner befinden, der ihrem Ursprung entspricht: Hilfsklassentests befinden sich beispielsweise in auxiliary
. Finden Sie einen geeigneten Ort für Ihren Test, basierend auf dem Teil des Systems, der getestet werden soll. Als Beispiel ein Ordner mit dem Namen thatkstarscategory
.
Erstellen Sie eine neue Einheitstestklasse oder kopieren Sie einen vorhandenen Einheitstest und fügen Sie ihn in einen neuen ein. Schauen Sie sich als Beispiel Tests/kstars_ui_tests/kstars_ui_tests.h
an. Benennen Sie die .h
und .cpp
Dateien als „test[lowercase kstars class]“ (z. B. „testthatkstarsclass“) und aktualisieren Sie sie so, dass sie wie folgt übereinstimmen:
/* [Author+Licence header] */ #ifndef TESTTHATKSTARSCLASS_H #define TESTTHATKSTARSCLASS_H #include <QtTest> #include <QObject> class TestThatKStarsClass: public QObject { Q_OBJECT public: explicit TestThatKStarsClass(QObject *parent = null); private slots: void initTestCase(); // Will trigger once at beginning void cleanupTestCase(); // Will trigger once at end void init(); // Will trigger before each test void cleanup(); // Will trigger after each test void testThisParticularFunction_data(); // Data fixtures for the test function (Qt 5.9+) void testThisParticularFunction(); // Test function } #endif // TESTTHATKSTARSCLASS_H
/* [Author+Licence header] */ #include "testthatkstarsclass.h" TestThatKStarsClass::TestThatKStarsClass(QObject* parent): QObject(parent) {} TestThatKStarsClass::initTestCase() {} TestThatKStarsClass::cleanupTestCase() {} TestThatKStarsClass::init() {} TestThatKStarsClass::cleanup() {} TestThatKStarsClass::testThisParticularFunction_data() { // If needed, add data fixtures with QTest::AddColumn/QTest::AddRow, each will trigger testThisParticularFunction } TestThatKStarsClass::testThisParticularFunction() { // Write your tests here, eventually using QFETCH to retrieve the current data fixture } QTEST_GUILESS_MAIN(TestThatKStarsClass);
Sie können eine einzelne Datei verwenden, um sowohl die Deklaration als auch die Definition zu speichern. Sie müssen jedoch #include "testthatkstarsclass.moc"
.
Aktualisieren Sie die CMake-Konfiguration, um Ihren Test hinzuzufügen. Wenn Sie einen neuen Ordner erstellt haben, erstellen Sie eine neue CMakeLists.txt
um Ihren Test hinzuzufügen:
ADD_EXECUTABLE( testthatkstarsclass testthatkstarsclass.cpp ) TARGET_LINK_LIBRARIES( testthatkstarsclass ${TEST_LIBRARIES}) ADD_TEST( NAME ThatKStarsClassTest COMMAND testthatkstarsclass )
Sorgen Sie dafür, dass die CMakeLists.txt
, die sich einen Ordner weiter oben im Dateisystem befindet, diese CMakeLists.txt
einbezieht, indem Sie Folgendes hinzufügen:
include_directories( ... ${kstars_SOURCE_DIR}/kstars/path/to/the/folder/of/the/kstars/class/you/are/testing ) ... add_subdirectory(thatkstarscategory)
Stellen Sie sicher, dass Sie Ihr add_subdirectory
in der richtigen Abhängigkeitsgruppe hinzufügen. Ekos-Tests erfordern beispielsweise INDI_FOUND
.
Schreiben Sie Ihre Tests. Stellen Sie sicher, dass Sie das Verhalten Ihrer Tests dokumentieren. Wenn Sie einen Fehler finden, beheben Sie ihn nicht, sondern markieren Sie ihn mit einem QEXPECT_FAIL
-Makro. Der Test dokumentiert das fehlerhafte Verhalten, während der Fehler aktiv ist, und schlägt fehl, wenn der Fehler behoben ist. Erst danach darf der Test aktualisiert werden. Achten Sie auch auf die Versionsunterstützung der Qt-Bibliothek. Für Datenerfassungen ist beispielsweise Qt 5.9+ erforderlich.
Befolgen Sie die gleichen Schritte wie für einheitliche Tests, suchen Sie Ihre Testklassen jedoch in kstars_ui_tests
.
Eine wichtige Sache bei UI-Tests ist, dass sie alle QStandardPaths::setTestModeEnabled(true)
verwenden müssen, damit sie mit einer separaten Benutzerkonfiguration ausgeführt werden, die zunächst leer ist. Benutzeroberflächentests erfordern daher eine vorläufige Einrichtung, um ordnungsgemäß zu funktionieren, z. B. die Verwendung des neuen Konfigurationsassistenten oder die Einrichtung des geografischen Standorts. Aus diesem Grund müssen Sie die Ausführung Ihres Tests in Tests/kstars_ui_tests/kstars_ui_tests.cpp
in main()
nach der Ausführung von TestKStarsStartup
hinzufügen.
Ein zweiter wichtiger Aspekt von QTest im Allgemeinen ist, dass Testfunktionen keinen Rückkehrcode haben. Man muss daher Makros schreiben, um duplizierten Code zu faktorisieren. In den Header-Dateien der kstars_ui_tests
Testklassen finden Sie viele vorhandene Makros, um Gadgets abzurufen, auf Schaltflächen zu klicken oder QComboBox
Widgets zu füllen ...
Ein dritter wichtiger Aspekt der KStars-Benutzeroberfläche ist, dass sie KDE- und Qt-Benutzeroberflächenelemente vermischt. Daher erfordern Tests manchmal, dass Verifizierungscode in einen QTimer::singleShot
-Aufruf verschoben wird, und manchmal muss sogar das Klicken auf eine Schaltfläche asynchron gemacht werden, damit der Test die Kontrolle behält (modale Dialoge). Glücklicherweise verändern diese Hacks die Ausführung des getesteten Codes nicht.
Beim Testen müssen Sie sicherstellen, dass Sie immer Elemente verwenden, die der Endbenutzer verwenden kann. Wenn für einen Test ein Setup erforderlich ist, das eigentlich nicht Teil der interessanten Anrufe ist, können Sie natürlich einen direkten Anruf hacken. Beispielsweise verwenden einige Ekos-Tests, bei denen der Teleskopsimulator auf einen bestimmten Standort zeigen muss QVERIFY(Ekos::Manager::Instance()->mountModule()->sync(ra,dec))
. Denken Sie daran, dass Sie manchmal Zeit einplanen müssen, damit asynchrone Signale gesendet und abgefangen werden können.
Jason Harris [email protected]
Jasem Mutlaq [email protected]
Akarsh Simha [email protected]
Alexey Khudyakov [email protected]
Artem Fedoskin [email protected]
Carsten Niehaus [email protected]
Chris Rowland [email protected]
Csaba Kertesz [email protected]
Eric Dejouhanet [email protected]
Harry de Valence [email protected]
Heiko Evermann [email protected]
Hy Murveit [email protected]
James Bowlin [email protected]
Jérôme Sonrier [email protected]
John Evans [email protected]
Joseph McGee [email protected]
Mark Hollomon [email protected]
Martin Piskernig [email protected]
Médéric Boquien [email protected]
Pablo de Vicente [email protected]
Prakash Mohan [email protected]
Rafał Kułaga [email protected]
Rishab Arora [email protected]
Robert Lancaster [email protected]
Samikshan Bairagya [email protected]
Thomas Kabelmann [email protected]
Valentin Boettcher [email protected]
Victor Cărbune [email protected]
Vincent Jagot [email protected]
Wolfgang Reissenberger [email protected]
Yuri Chornoivan [email protected]
Die meisten Katalogdaten stammten vom Astronomical Data Center der NASA. Die Website ist: http://adc.gsfc.nasa.gov/
NGC/IC-Daten werden von Christian Dersch aus der OpenNGC-Datenbank zusammengestellt. https://github.com/mattiaverga/OpenNGC (CC-BY-SA-4.0-Lizenz)
Die Supernova-Daten stammen aus dem Open Supernova Catalogue-Projekt unter https://sne.space. Weitere Informationen finden Sie im veröffentlichten Artikel hier: http://adsabs.harvard.edu/abs/2016arXiv160501054G
KStars-Links zu den hervorragenden Bildsammlungen und HTML-Seiten, die von den Students for the Exploration and Development of Space zusammengestellt wurden, finden Sie unter: http://www.seds.org
KStars verlinkt auf die Online-Bilder der Digitized Sky Survey, die Sie unter http://archive.stsci.edu/cgi-bin/dss_form abfragen können
KStars verlinkt auf Bilder aus dem HST Heritage-Projekt und aus HST-Pressemitteilungen: http://heritage.stsci.edu http://oposite.stsci.edu/pubinfo/pr.html
KStars verlinkt auf Bilder des Advanced Observer Program am Kitt Peak National Observatory. Wenn Sie sich für Astrofotografie interessieren, sollten Sie einen Blick auf das Programm werfen: http://www.noao.edu/outreach/aop/
Die Credits für jedes im Programm verwendete Bild sind in README.images aufgeführt
KStars ist eine Arbeit voller Liebe. Es begann als persönliches Hobby von mir, aber schon bald nachdem ich den Code zum ersten Mal auf Sourceforge gepostet hatte, fing es an, andere Entwickler anzulocken. Ich bin einfach völlig beeindruckt und zufrieden mit meinen Mitentwicklern. Ich könnte mir kein talentierteres, freundlicheres Team wünschen. Es versteht sich von selbst, dass KStars ohne ihre Bemühungen bei weitem nicht das wäre, was es heute ist. Gemeinsam haben wir etwas geschaffen, auf das wir alle stolz sein können.
Wir haben (hauptsächlich) zwei Bücher als Leitfaden zum Schreiben der in KStars verwendeten Algorithmen verwendet:
„Praktische Astronomie mit Ihrem Taschenrechner“ von Peter Duffett-Smith
„Astronomische Algorithmen“ von Jean Meeus
Vielen Dank an die Entwickler von Qt und KDE, deren unvergleichliche API KStars ermöglicht hat. Dank auch an den unermüdlichen Einsatz der KDE-Übersetzungsteams, die KStars einem weltweiten Publikum zugänglich machen.
Vielen Dank an alle in den KDevelop-Foren und auf irc.kde.org für die Beantwortung meiner häufigen Fragen.
Vielen Dank auch an die vielen Benutzer, die Fehlerberichte oder sonstiges Feedback abgegeben haben.
Du liest das immer noch? :) Nun, das war's auch schon. Ich hoffe, dass Ihnen KStars gefällt!
Jason Harris [email protected]
KStars Development-Mailingliste [email protected]
Schicken Sie uns Ideen und Feedback!