Cartes Du Ciel - Umfangreiches Planetarium in V3.2

Status
Es sind keine weiteren Antworten möglich.

Euklid

Aktives Mitglied
Cartes Du Ciel - eines der wohl umfangreichsten freien Programme zur Darstellung des Nachthimmels ist gestern in einer neuen Version erschienen.

ScreenShots: http://www.ap-i.net/skychart/en/screenshot/start

Eine Auswahl der Features:
- Sternkartenerstellung: Hochkonfigurierbar, Einbindung eines Fotokatalogs zur realistischen Darstellung astron. Objekte möglich
- Kalender zum schnellen Auffinden von: Planeten, Kometen, Asteroiden, Mond- und Sonnenfinsternisse
- Zusatzkataloge für Doppelsterne, Veränderliche u.v.m. von der Projekthomepage kostenlos verfügbar
- Aktuelle Helligkeitskurven veränderlicher Sterne lassen sich direkt downloaden und werden automatisch dargestellt.
- Teleskopsteuerung über das Programm möglich

Cartes du Ciel ist freie Software und lässt sich kostenlos und vollständig von der folgenden Seite herunterladen:

http://www.ap-i.net/skychart/en/download

Mit der aktuellen Version verlässt Cartes Du Ciel das Beta-Stadium. Mehr Informationen dazu hier:

http://www.ap-i.net/skychart/en/news/version_3.2

Viele Grüße, Euklid
 
Hi Euklid + alle CdC Fans,

bin prizipiell ein Fan von solch tollen Dingen, keine Frage. Eine SW dieses Umfangs als Freeware zu bauen ist schon was, chapeau!

Ich muss aber bei der neuen Version auch mal ein paar Kleinigkeiten loswerden. Neue Version getestet hab ich mal auf einem Win 64bit QuadCore mit 4GB Ram. Läuft soweit super, aber...

Bedientechnisch ist man von anderen Programmen her verwöhnter ;)
Was mich persönlich bei CdC immer schon genervt hat ist, dass man 5 oder 6 Klicks benötigt, bis man zB die Sonne oder einen Planeten eingestellt bekommt. Gibt es da keine Shortcuts?
Weiters, dass man die Ansicht nicht "schieben/ziehen" kann. Auch ein Doppelklick geht nicht für zentrieren, man muss rechts klicken und "zentrieren" wählen. Aber gut, das ist Gewöhnungssache. Kann man da was anderes einstellen?

Des Weiteren bekomme ich Fehlermeldungen in der neuen Version, wenn ich ein Objekt wähle (zB Jupiter), und dann das Details-Fenster unten rechts größer ziehen will, weil nicht alle Daten reinpassten. Weil scrollen mit dem Mausrad geht nicht, keine Ahnung warum.

Sowas zB:

Code: 
TControl.InvalidatePreferredSize loop detected :TIpHtmlInternalPanel Bounds=l=0,t=0,r=391,b=468.
Mit Ok wird ignoriert und Dateninkonsistenz riskiert.
Mit Abbrechen wird das Programm abgebrochen.

Ich will hier nichts schlecht reden, nur mal eben meine Erfahrung posten. Noch wer Probleme ähnlicher Art? Was meint ihr?

cs,
harald

--




 
HI an alle,

Also das Programm läuft bei mir soweit ohne Fehlermeldungen bzw. habs noch nicht bis ins Detail ausprobiert.

Aber was ich festgestellt habe, dass wenn ich die Karte z.B. nach Süden ausrichte sie mir irgendwie wegdriftet bzw. ich sie nicht genau nach Süden ausrichten kann ..

Bei mehrmaligen drücken der rechten "Süd" Taste dreht sich die Karte um Süden herum und kommt nicht richtig zum Stehen .. werde das aber heute nochmal ausführlicher testen.

Gruß, Chris
 
Hi Harald,

als Hersteller eines kommerziellen Programms habe ich überhaupt keine Berechtigung, freie Software zu kritisieren. Ich will nichts schlechtreden, aber eine Meinung und ein paar Gedanken zu CdC habe ich schon. Wen es also stört dass die von einem kommerziellen Enrtwickler kommen sollte nun einfach zu lesen aufhören.

Als neugieriger Mensch kenne ich sehr viele Astroprogramme und bin immer wieder darüber erstaunt, wie geduldig viele Anwender sind und wie nachsichtig. CdC kam mir immer sehr umständlich vor und ich denke es ist einfach deswegen populär weil es nichts kostet und sehr viele Funktionen bietet.

Auffallend ist auch die hohe Anzahl von Fragen zum Programm in einschlägigen Foren. Wenn soviel gefragt wird ist das m.E. ein Indiz für unzureichende Dokumentation oder unklare Konzepte und Abläufe. Aber der Anwender hat die Wahl, wieviel ihm/ihr die eigene Zeit wert ist. Statt mit Freeware stundenlang herumzufriemeln würde ich lieber eine Software kaufen die funktioniert und gut dokumentiert ist (z.B. Guide 8). Aber das ist Geschmackssache.

Oft bekomme ich den Eindruck, dass viele Anwender tausende von Euro für ihre Montierung, Kameras und Optik ausgeben aber darauf bestehen, dass Software nichts kosten darf. Das scheint geradezu ein Glaubenssatz zu sein, fast schon ein Mantra. "Bitte empfehlt mir gute Software - selbstverständlich Freeware". Doch warum ist das für viele eigentlich selbstverständlich? Das kann ich bis heute nicht verstehen.

Eine seltsame Weltsicht, als ob gute Software auf wundersame Weise von alleine entsteht, ohne dass da jemand ebensoviel oder sogar mehr Zeit und Können investiert hat als z.B. in die Konstruktion einer guten Montierung einfließt. Dass es praktisch keine Materialkosten im Herstellungsprozeß von Software gibt ist richtig, aber nach der Logik müssten ja die meisten Dienstleistungen kostenlos sein. Geht mal zum Friseur und fragt nach einem kostenlosen Haarschnitt...

Sinnvoll wird Freeware dann, wenn man es einfach so sieht, dass kein Qualitäts- oder Nutzenversprechen dahinter stehen muss. Viele Programmierer haben Freude daran, ihre Produkte zur Verfügung zu stellen. Sie arbeiten aus Interesse an der Sache oder Spaß am Programmieren daran und mit Publikum macht ein Konzert erst Sinn. So gesehen ist das voll OK, aber man muss halt den Anspruch unterscheiden. Leider ist es manchmal so, dass kommerzielle Software die Anwender enttäuscht weil sie zwar bezahlt wurde, aber leider nicht viel taugt oder der Support bei Problemen nicht helfen kann oder gleich auf Sehrohrtiefe abtaucht. Wer damit Erfahrungen hat wird wohl denken "ich probiere es erst mal mit Freeware bevor ich Geld in den Sand setze". Da fasse ich mich durchaus an die eigene Nase, denn z.B. war Redshift eine glatte Fehlinvestition. Allerdings habe ich diesen Fehler nur mit Redshift 1 gemacht und danach die Finger davon gelassen ;-)

Zurück zu CdC und nun konkret.

Was mich da am meisten störte ist das Konzept der Kataloge, das allerdings auch die Mehrheit der kommerziellen Kartenprogramme auszeichnet. Warum muss man erst die richtigen Kataloge aktivieren, damit man bestimmte Objekte sehen kann? Die Zugehörigkeit zu einem Katalog ist keine beobachterisch relevante Eigenschaft. Wenn mich z.B. Kugelsternhaufen interessieren, dann soll eine Karte diejenigen anzeigen die man sehen kann. Ich will nicht ausprobieren müssen welche Kataloge man anschalten muss damit sie erscheinen. Und noch schlimmer: die doppelten oder sogar mehrfachen Einträge wenn ein Objekt mit minimal unterschiedlichen Daten in mehreren Katalogen gelistet ist.

Aber sogar teure Software wie Starry Night oder TheSky "leidet" unter den Katalogen. Einige Hersteller haben das Problem erkannt und versuchen bessere Wege zu gehen, aber ich weiß aus eigener Erfahrung um den enormen Aufwand den das verlangt.

Was mich wundert (aber vielleicht bin ich nur schlecht informiert): wenn so viele Sternfreunde CdC gut finden und die schlechte Dokumentation beklagen, warum leisten sie dann nicht "einfach" ihren eigenen Beitrag: gemeinsames Erstellen eines Handbuchs als OpenSource-Projekt? Die Ressourcen dafür bekommt man bei SourceForge kostenlos, dann sind nur noch einige hundert Stunden Arbeit zu investieren und schon hat man ein ordentliches Handbuch. Jeder der da mitmacht würde einen wirklich nützlichen Beitrag leisten. Ich meine das völlig ernst und in keiner Weise ironisch. So würde "Freeware" wirklich funktionieren, mit viel mehr Engagement der Anwender die quasi mit Eigenbeiträgen "zurückzahlen" - nicht nur an den Entwickler sondern auch an die Community. Aber "nur nehmen wollen" klappt halt nicht, es müssen sich auch Leute finden die was geben wollen und können.

Vielleicht ist dies ein Denkanstoß für CdC-Benutzer, mal selbst tätig zu werden.

Viele Grüße,
Tom
 
Zitat von h_c_greier:
Was mich persönlich bei CdC immer schon genervt hat ist, dass man 5 oder 6 Klicks benötigt, bis man zB die Sonne oder einen Planeten eingestellt bekommt. Gibt es da keine Shortcuts?
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Links neben dem Fernglas in der Icon-Leiste gebe ich "Sonne" ein, um sie zu finden. Einen schnelleren Weg kenne ich nicht. Wenn Du einen für sinnvoll hältst, kannst Du einen Patch an Patrick Chevalley senden oder alternativ einen Feature-Report machen: http://www.ap-i.net/skychart/en/bug_tracker

Dadurch teilst Du dem Autor Deine Wünsche mit und er kann sie berücksichtigen.

Gruß, Euklid
 
Zitat von Thomas_Pfleger:
Oft bekomme ich den Eindruck, dass viele Anwender tausende von Euro für ihre Montierung, Kameras und Optik ausgeben aber darauf bestehen, dass Software nichts kosten darf. Das scheint geradezu ein Glaubenssatz zu sein, fast schon ein Mantra. "Bitte empfehlt mir gute Software - selbstverständlich Freeware". Doch warum ist das für viele eigentlich selbstverständlich? Das kann ich bis heute nicht verstehen.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Diese oft anzutreffende Einstellung kann ich auch nicht nachvollziehen. Aber ich glaube, das liegt auch am gesellschaftlichen Wandel. Zeitungen und Verlage haben hier ähnliche Probleme wie die Software-Hersteller. Qualität lohnt sich in diesen Bereichen immer seltener, da von den Menschen ein falsches Selbstverständnis ausgeht.
Insbesondere im Bereich der Beobachtungsplanung sind qualitativ hochwertige Lösungen kommerziell.

In einem Punkt wiederspreche ich: Es gibt auch qualitativ sehr hochwertige freie Software. Das sind entweder Projekte mit einer großen Entwicklergemeinde (z.B. der FreePascal-Compiler oder viele KDE-Anwendungen) oder Firmen haben alternative Geschäftsmodelle entwickelt (z.B. Googles Android).

Bei Cartes Du Ciel handelt es sich um ein 1-Mann-Projekt: Patrick Chevalley entwickelt das Programm in seiner Freizeit. Da es OpenSource ist, können sich aber alle beteiligen, die das Projekt voran bringen wollen. Das ist denke ich eine wichtige Grundeinstellung, wenn man freie Software genießt. Man kann den Projekten wie Cartes du Ciel einen Teil dessen, was man durch das Program an Nutzen hinzubekommt, in das Projekt zurück fließen lassen, indem man sich aktiv beteiligt.
CdC wird beispielsweise mit einer sehr einfach zu bedienenden, delphi-ähnlichen Entwicklungsumgebung (genauer: Lazarus ) programmiert. Die Erlernung der Sprache (Pascal-Dialekt) ist einfach, die Einarbeitung in das Programm dürfte auch nicht allzu schwer sein.

Viele Grüße, Alexander
 
Hallo,

@Euklid

OK, die Suchen-Dropdown-Liste merkt sich die zuvor gemachten Einträge. Aber warum muss man ein Objekt erst eintippen?? Bei Guide zB ist das (beim Sonnensystem) nur einen Klick weit entfernt. Naja, macht ja nichts, bin ja nur am Testen. Wirklich verwenden tu ich CdC ohnehin selten bis gar nicht. Das mit dem Fehler des Detail-Fensters ist allerdings nervig.
Nach durchprobieren vielerlei SW in den letzten Jahren bin ich immer noch bei Guide, und in der Praxis schon mal E&T. Starry Night habe ich mir mal gekauft, verwende ich aber nicht mehr. TheSky hatte ich auch mal, mittlerweile gefällt mir das Konzept der Bezahlung nicht so recht. Redshift, hui weiß ich gar nimmer…sehe ich mittlerweile als „nettes Spielzeug“.

---

@Tom

Bin soweit d’accord was die Debatte „Freeware“ betrifft. Wollte mich nicht über CdC aufregen, prinzipiell ist das eine tolle Sache. Und wenn es eben Freeware ist, darf man sich über Details nicht beklagen ;). Nein, da hast du schon Recht, wenn man was verbessern will sollte man sich einbringen, soweit das (know-how)technisch möglich ist.
Das Konzept der Kataloge mutet mir bei CdC auch seltsam an. Ich bin kein Experte, aber die Konsolidierung solcher Datenbanken für praktische Beobachtungskarten dürfte äußerst schwierig und aufwändig sein.
Oft bekomme ich den Eindruck, dass viele Anwender tausende von Euro für ihre Montierung , Kameras und Optik ausgeben aber darauf bestehen, dass Software nichts kosten darf. Das scheint geradezu ein Glaubenssatz zu sein, fast schon ein Mantra. "Bitte empfehlt mir gute Software - selbstverständlich Freeware". Doch warum ist das für viele eigentlich selbstverständlich? Das kann ich bis heute nicht verstehen.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Keine Ahnung, warum das so ist. Ich weiß nicht wie viel Durchblick man haben muss um zu sehen, wie schnell der Arbeitsaufwand beim Programmieren wächst. So ein großes Projekt kann man alleine fast nicht bewältigen (Ich mache nur kleine Sachen, hauptsächlich für mich selbst bzw. zu Lehrzwecken). Wenn man dann auf der Freeware Schiene fährt, entledigt man sich auch gleich eines Supports, der User hat dann keinerlei Ansprüche darauf. Aber das mit der Doku ist schon richtig, der alte Spruch eine SW ist so gut wie....
Es gibt aber auch Freeware mit Schmackes! Allerdings sitzen dahinter dann meistens auch eine Vielzahl an Leuten.

---

Zu guter Letzt sehe ich aber nicht ein, warum man über Freeware nicht ab und an mal meckern dürfen sollte. Freilich kommt dann sofort die Antwort "machs besser" oder "mail dem Autor" oder "bring dich ein". Auch das ist legitim. Das was mich bei CdC stört sind vielleicht Kleinigkeiten im allgemeinen Sinn, aber nicht für mich. Wenn sich das Ding nicht vernünftig bedienen lässt dann nehme ich was anderes. Ganz einfach.

cs,
harald
 
Zuletzt von einem Moderator bearbeitet:
@ h_c_Greier:

Zitat von h_c_greier:
Das was mich bei CdC stört sind vielleicht Kleinigkeiten im allgemeinen Sinn, aber nicht für mich. Wenn sich das Ding nicht vernünftig bedienen lässt dann nehme ich was anderes. Ganz einfach.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Ok, dann wird es definitiv kommerziell. Nach meinem Recherchen ist Cartes Du Ciel das BESTE freie Programm dieser Art. Es gibt nichts vergleichbares.
Auch unter kommerzieller Software muss man genau hinschauen, um ähnlich gut konfigurierbare Programme zu finden. Dass man für etwas Geld bezahlt bedeutet eben NICHT, dass es dadurch automatisch gut ist. Gerade auf dem Markt der virtuellen Planetarien gibt es auch viel Schund. Andere kommerzielle Programme sind zwar schön aufgemacht, eignen sich aber eher zum Informieren denn zum Vorbereiten von Beobachtungen.

@ Tom:
Nun möchte ich mich zu den Katalogen doch noch äußern:
In meinen Augen sind hinzuladbare Kataloge bei Programmen, die über das Internet verteilt werden, sehr sinnvoll. Wären beispielsweise die Kataloge in Cartes Du Ciel bereits integriert, wäre es über 1 Gigabyte groß und kaum herunterzuladen.
Ich finde, dass CdC einen guten Mittelweg geht: Es kombiniert mehrere Kataloge in einer einzigen Installationsdatei. Ist die installiert, hat man mehr als die Hälfte der für CdC verfügbaren Kataloge auf der Platte.
Das Problem, dass wegen geringer Differenzen in den Positionsangaben ein Objekt bei mehreren geladenen Katalogen mehrfach in der Karte erscheint, tritt bei CdC kaum auf, da es bei den voreingestellten FOV nur einen der Kataloge zur jeweiligen Darstellunng verwendet (gilt zumindest für die Hauptkataloge).

Gruß, Euklid
 
Zuletzt von einem Moderator bearbeitet:
Hallo Tom,

das ist zwar ein wenig am Thema vorbei, aber zu deinen Gedanken wollte ich noch etwas anmerken.

Dass es praktisch keine Materialkosten im Herstellungsprozeß von Software gibt ist richtig...
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Das stimmt so nicht. Um dass Software entstehen kann, muss erst einmal Hardware und andere Software die notwendige Infrastruktur bereit stellen. Ich sehe Kosten für PC-Hardware und Lizenzkosten für z.B. das Betriebssystem oder die Entwicklungsumgebung als "Materialkosten" an. Der Friseur hat auch Materialkosten für Umhang, Kämme, Fön, Haargel usw.
Bei kostenloser Software sind dann aber die Materialkosten noch etwas geringer, da man sich meist wiederum auf andere kostenlose Software stützt.


Übrings bzgl. der Redshift Fehlinvestition:
Gute kommerzielle Software bietet eine Demoversion oder 30 Tage Testzeit an. Das ist auch schon ein Qualitätsmerkmal, wenn die Autoren keine Angst haben, dass ihre Software nicht überzeugen könnte...
 
Moin Tom,

wie so vieles hat die Freeware/kommerzielle Software-Debatte viele Facetten, und ein Vergleich hinkt quasi systemimmanent.
Es gibt viele Software, die nicht unbedingt intuitiv zu bedienen ist - auch jene aus dem großen Softwarehaus in Redmond gehört dazu.

An CdC habe ich mich nach und nach gewöhnt, wie auch an Giotto und Registax - jeweils eigene und "organisch gewachsene" Oberflächen, mit denen man aber eigentlich gut klarkommt.

Ich muss zugeben, dass mir auch Eye&Telescope in der Demo-Version zuerst "seltsam" vorkam, wenn man das Wesen aber erstmal - wie bei vielen Programmen - erfasst hat, ist plötzlich alles ganz einfach. Darum hab ich's mittlerweile auch (über diesen großen Distributor) bestellt - soviel Werbung für ein Forenmitglied sei mir erlaubt. :biggrin:

Nein, freie Software birgt sicherlich nicht den Anspruch automatisch gute Software zu sein - speziell wenn die Entwicklerbasis klein oder wie bei Patrick faktisch ein 1-Mann-Projekt ist. Sie bietet bei offenen Quellen die Möglichkeit - aber dadurch eben keine Zwangläufigkeit.

Das Katalogkonzept ist zum einen erstmal etwas gewöhnungsbedürftig, zum anderen aber auch sehr flexibel. Mittlerweile bekommt man zudem auch eine Warnung wie's scheint, wenn man "konkurrierende" (bekannte) Kataloge gleichzeitig aktiviert, was zu Doppeldarstellungen führen könnte. Der Tycho2 und UCAC3 wurden laut Webseite so abgestimmt, dass sie sich ergänzen und damit Doppeldarstellungen vermieden werden. Somit ist die Katalogeinstellung gegenüber früheren Versionen (bei denen ich noch den HSTGSC eingebunden hatte) effektiv transparenter geworden, da hatte ich mich noch über den Wirrwarr der Sterne gewundert :-)

Kurzum - ich mag das Programm, weil es für eine Orientirung am Himmel ziemlich hilfreich ist und dabei auf effekthascherische Darstellung wie ich's bei Starry Night empfunden habe, verzichtet, mehr eine elektronische Sternkarte eben. Wenn ich auch immer noch gern den Tirion zur Hand nehme und einfach mal darin herumgucke :pfeif:.
 
Hallo zusammen,

noch einmal zu den Katalogen, denn vielleicht war noch nicht klar genug beschrieben, was mich dort stört. Zunächst einmal ist es positiv, wenn man eine Software nicht gleich mit einem riesigen Datenbestand ausliefert, den manche Benutzer eventuell gar nicht brauchen. Wer als Einsteiger am Himmel unterwegs ist, wird von UGC, PCG, ESO und MCG eher verwirrt als dass es weiterhilft. Und je mehr Daten ein Programm im Bauch hat, desto länger dauert es, beim Kartenzeichnen die passende Auswahl zu finden.

In der Astronomiegeschichte gab und gibt es keine Institution, die für die zentrale Vergabe von Objektnamen zuständig ist. So kam und kommt es zum Thema Cross-Ref, also dem ganzen Wust an Aliasnamen von Objekten. Prominente Galaxien haben schon mal mehr als 10 Bezeichnungen.

Wenn man nun Doppel- oder Mehrfacheintragungen auf der Karte einfach dadurch vermeidet, dass man fallweise nur einen Katalog aktiviert, dann ist das nur ein Kurieren an Symptomen. Was ich mir wünsche (und selbst so gut wie es geht realisiere) ist eine integrierte Datenbank, die die Bezeichnungen und Aliasnamen kennt, möglichst aber keine Dupletten von Daten beeinhaltet. Das ist nicht einfach und ich bin sicher, dass auch die E&T-Datenbank trotz des Bemühens von Ronald Stoyan und mir noch Dupletten aufweist. Wenn man die findet kann man sie aber immerhin für die eigene Installation loswerden.

Import in einen vereinheitlichten Datenbestand ist möglich, aber komplex. Bei E&T gilt das Axiom "Namen sind eindeutig". Es darf also zu einem Namen immer nur genau ein Objekt geben. Nur damit ist es möglich, bei einem Import eine Objektliste zu verarbeiten, ohne wegen Mehrdeutigkeiten beim Benutzer nachfragen zu müssen. Doch dafür zahlt man den Preis, dass manche z.B. im NGC doppelt vergebene Namen (davon gibt es zahlreiche Fälle) dann nur einem der beiden Objekte zugeordnet werden dürfen. Man verliert also die Information, dass NGC xy eigentlich *zwei* Objekte bezeichnet, was wohl durch fehlerhafte Identifikation beim Zusammenstellen des NGC aus seinen Quellen passiert ist.

Und manchmal ist die Forderung nach eindeutigen Objektnamen wirklich gemein: es gibt Doppelsternbezeichnungen nach Barnard, und natürlich fallen uns auch die Dunkelnebel ein. Also musste ich die Dunkelnebel alle mit "Barnard..." benennen statt mit dem üblichen kurzen "B...". Denn Barnard-Doppelsterne auf "B" gibt's noch viel mehr. Analog gilt das für die Planetarischen Nebel und die Galaxienhaufen von Abell. Letztere habe ich daher auf AGC... umbenannt um Kollisionen zu vermeiden.

Mit diesen kleinen Einblicken in die Freuden beim Zusammenstellen einer Objekt-Datenbank glaubt ihr mir nun wahrscheinlich, dass das eine komplizierte, zeitaufwändige und auch sehr fehlerträchtige Aufgabe ist. Deswegen drücken sich die meisten Softwareentwickler gerne darum, doch ich finde das nicht richtig. Eine ernnstgemeinte Software sollte sich nicht an den Bedürfnissen und Fähigkeiten des Programmierers orientieren sondern die Bedürfnisse des Anwenders möglichst gut zu bedienen versuchen.

OpenSource: ja, prinzipeill stimmt es natürlich dass man als Programmierer fremden Code modifizieren kann. Doch darf man fragen, wieviele Leute die das vorschlagen es schon mal selbst versucht haben? Ich habe mir den Code von CdC nicht angeschaut, aber es ist wohl nicht ganz verkehrt davon auszugehen, dass es etwa so viel wie bei E&T sein könnte. E&T wird aus mehr als 700 Quelldateien gebaut, zusammen mehr als 125000 Programmzeilen (von einem Tool gezählt). Das ist eine Menge Stoff und vieles davon ist nicht so einfach dass man es sofort versteht. Vor allem muss man bei einem Fehler oder Änderungsvorhaben genau wissen, wo man eingreifen muss. Und dort sehe ich das Problem, speziell bei fremdem Code. Man kann Quelltexte lesen und stückweise versteht man, worum es da geht. Doch oft bleibt unklar, wozu das gemacht wird, wann und warum es aufgerufen wird u.s.w. So habe ich mir bei E&T schon manches Mal selbst in den Fuß geschossen, weil so vieles mit so vielem zusammenhängt. Man klickt irgendwo hin und die Maschinerie rödelt los: neue Daten hier berechnen und darstellen, dort und da drüben muss auch noch aktualisiert werden. Wenn dann die Bearbeitung einer Aktualisierung (ein "Event-Handler") wiederum neue Änderungsbenachrichtigungen rausschickt kann es zu einem Zirkelschluss kommen. Den muss man durch Umorganisation (geht oft nicht) oder Tricks (geht immer) vermeiden. Langer Rede kurzer Sinn: ich kann mir nicht vorstellen, dass jemand E&T warten oder weiterentwickeln könnte, wenn er nur über den Code verfügte. Ohne mein Zusatzwissen der Zusammenhänge geht das nicht. Und wahrscheinlich ist das beim Linux-System oder CdC nicht viel anders. Meiner Meinung nach ist das "nimm den Code, er ist frei und verfügbar"-Argument zu theoretisch. Das funktioniert nur bei kleineren Programmen bis vielleicht 20000 Zeilen. Doch sicher hat CdC *viel* mehr.

Deswegen habe ich auch vorgeschlagen, ein gemeinsames Dokumentationsprojekt aufzusetzen.

Gruß,
Tom
 
Hallo,

Zitat von Thomas_Pfleger:
OpenSource: ja, prinzipeill stimmt es natürlich dass man als Programmierer fremden Code modifizieren kann. Doch darf man fragen, wieviele Leute die das vorschlagen es schon mal selbst versucht haben?
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Da gab es schon ein paar:
Vor ziemlich genau zwei Jahren schien die Entwicklung bei CdC still zu stehen - ein halbes Jahr lang wurde der Bugtracker nicht bearbeitet und das SVN schien still zu stehen. Wir hatten diese Entwicklung auf einem Treffen des Deutschen Lazarusforums (Lazarus ist die Entwicklungsumgebung von CdC) im Rahmen astronomieinteressierter Entwickler diskutiert. Es war zu befürchten, dass Patrick Chevalley das Projekt nicht mehr weiter entwickelt. Daher prüften wir die Übernahme von zumindest einen Teil der Entwicklung durch uns und studierten den Quelltext zu diesem Zweck relativ intensiv auf dem Treffen. Bei Lazarus werden die Forms des Programms samt Inhalt während der "Design-Time" (also der Zeit, in der man an neuem Quelltext schreibt) angezeigt. Möchte man wissen, welcher Quelltext hinter einem Buttonclick steht, klickt man im sogenannten Objektinspektor auf das zugehörige OnClick-Ereignis und Datei und Quelltextstelle werden automatisch angezeigt. Dies erleichterte uns das Einsteigen in den Code. Patrick Chevalley ist zudem sehr strukturiert vorgegagen, so dass ich denke, dass eine Weiterentwicklung durch einen gewillten Personenkreis mit Vorerfahrungen in den Bereichen Astronomie, Geometrie und Kenntnissen bezüglich der Programmiersprache Pascal möglich wäre, wenn auch unter großem Aufwand.
Wir entschieden damals für den Fall, dass das Projekt nicht weiter gepflegt wird und der Autor nicht mehr erreichbar ist, einen Fork zu erstellen (bevor die offiziellen CdC-Seiten nicht mehr erreichbar gewesen wären) und einen Teil unserer Kapazitäten der Bugbereinigung von CdC zu widmen. Glücklicherweise wurde dies nicht notwendig und CdC wurde von seinem Hauptautor recht schnell und dann auch kontinuierlich zur ersten stabilen Version 3.2 weiterentwickelt.

Ich denke ein großer Vorteil von OpenSource ist, dass Projekte nicht sterben, wenn sich die Initiatoren ihnen nicht mehr widmen können, sie dennoch eine ausreichend große Anhängerschaft haben.

Gruß, Alexander

Edit: CdC hatte zum damaligen Zeitpunkt etwa 45000 Quelltextzeilen - für die, die es interessiert.
 
Zuletzt von einem Moderator bearbeitet:
Hallo Thomas,

das mit den Katalogen ist schon ein Knackpunkt. Das Prinzip ein Objekt - eine eindeutige Bezeichnung geht aber dennoch. Z.B. in dem die Katalogbezeichnung dann ein Anhängsel A, B, C usw. bekommt. Damit wäre dann wieder alles eindeutig und Informationen gehen auch keine verloren.
Bei den Sternkatalogen ist es ja häufig auch so, dass eine HIP-Nr. auf mehrere Objekte verweist (z.B. beim Doppelsternsystem). Kann man dann die einzelnen Komponenten nicht optisch auflösen (oder später werden weitere Komponenten entdeckt), ist auch eine Positionsangabe im Katalognamen zu ungenau. Da helfen dann nur die Anhängsel zum Unterscheiden.

Bzgl. Open Source:
Fremder Quellcode muss auch bei kommerzieller Software verstanden werden, sobald mehr als 1 Entwickler beteiligt ist. Da gibt es keine Unterschiede. Mit Clean Code und hoher Testabdeckung sollte das meiste klar verständlich sein. Die größeren oder kritischen Zusammenhänge bzw. Fachkonzepte müssen bzw. sollten ja ohnehin irgend wo dokumentiert sein. Fremden Quellcode zu verstehen wird nur dann scheitern, wenn entweder Chaosprogrammierer am Werk waren oder der Quellcode bewusst verschleiert wurde.

Sind denn bei den 125k Zeilen Code für E&T die Tests mit eingerechnet?
 
Hallo Gerd,

Zitat von Marfir:
Sind denn bei den 125k Zeilen Code für E&T die Tests mit eingerechnet?
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Nein. Es gibt keine automatischen Tests.

Ich kenne mich damit zwar aus, aber bis heute konnten mir nicht einmal die Experten in unserer Firma sagen, wie man eine stark grafik- und GUI-lastige Software automatisch testet. Wie greift die Testroutine die Istwerte ab? Bei einer reinen Berechnung ist das klar, bei Tests der Persistenz kann man z.B. per SQL gegenlesen ob alles wie erwartet verspeichert wurde. Aber wie testest Du automatisch, ob eine Grafik richtig aussieht?

Zudem eignet sich nicht jede Programmierumgebung gleichermaßen gut für eine Testautomatisierung. Am einfachsten geht es mit Webanwendungen (weil man dem erzeugten HTML ohne umschweife entnehmen kann, ob's passt). Mit einer reinen Windows-Anwendung ist es viel schwieriger, einen "Request" abzusetzen, weil man dazu Ereignisse generieren muss und oft Kenntnis der internen Fensterstruktur braucht. Und dann muss man den zu prüfenden Zustand herausbekommen, auch nicht trivial.

Vor Jahren habe ich bei einem Workshop mit der Rational Test Suite (Rational Robot u.a.) mal gesehen wie das geht. Die Software erlaubt zwar Capture & Replay, aber das Abholen und Prüfen des Programmzustands erfolgte dort in einer eigenen Skriptsprache. Und wo programmiert wird, entstehen wieder Fehler. Wer sichert die Qualität des qualitätssichernden Codes?

Aktuell mache ich komplett neue Funktionen, da fehlen mir vor allem die entsprecheden Beobachtungen zum Vergleich.

Das alles heisst nicht, dass mir Tests egal sind oder ich nichts davon halte. Die Erfahrung zeigt mir aber dass es im Falle von E&T nichts besseres gibt, als die Verwendung der in Test befindlichen Version im Praxiseinsatz. Ich staune oft was ich noch am Fernrohr in E&T finde das mir zuhause am Schreibtisch entgangen ist. Und wenn's nur Usability-Themen sind.

Noch ein Haken: wenn ich versuchen würde, eine automatisierte Testsuite für E&T aufzubauen gäbe es jahrelang keinerlei Fortschritt mehr. Dem steht gegenüber, dass E&T nicht unbedingt im Ruf steht, besonders buggy zu sein. Ab und zu schmiert es mal ab, aber das ist wirklich selten. Weil ich dafür inzwischen automatische Speicherdumps bekomme kann ich relativ oft die Ursache herausfinden. Nur leider klappt das nicht so gut mit den Meldungen von fremden Rechnern, denn da fehlen oft die für die Diagnose notwendigen Windows-Symboldateien. Man weiß dann zwar, wo das Programm ausstieg, aber wenn das in der Kernel- oder User-DLL war und nicht klar ist, wo der letzte selbst geschriebene Code war steht man dumm da.

Viele Grüße,
Tom

 
etwas vom Thema abgekommen

Moin liebe Diskutanten (oder wie immer man das nennt)

Tom - ich persönlich bin froh, dass E&T nicht im Test-Code ertrinkt, und der "Anwendertest" ist eigentlich durch nichts zu ersetzen. Korrektheit ist eine Sache und lässt sich ansatzweise modular in der Entwicklung testen, das Zusammenspiel der Einzelkomponenten ist aber nach meiner Erfahrung eher ein evolutionärer Prozess, ebenso wie die Mensch-Maschine Schnittstelle.

Vor allem bin ich zufrieden, dass du nicht nur {<entwickel> <test>}* -Schleifen durchläufst, sondern auch lieber mal der Astronomie als solcher nachgehst und dann höchstens "anwendest" (was nicht negativ gemeint ist!). :biggrin:

Automatische Tests können immer nur das testen, worauf sie gedrillt sind, decken dabei aber nur einen Teil des Gesamtkunstwerks ab - und sind fast hinderlich, wenn es um ein Redesign geht ("och nöö, lieber nicht umbauen, dann müssten die ganzen Tests neu implementiert werden").

Um die Schleife zum Ursprung des Threads zurückzudrehen - ich glaube nicht, dass Patrick Chevalley das Neuaufsetzen von CdC (ist ja in Release 3 umfangreich neugebaut worden, wenn ich das richtig verfolgt habe) gewagt hätte, wenn er dabei eine komplette Testsuite hätte neu abbilden müssen.
Dass die Grundkonzepte (das leidige Thema Kataloge ;) ) beibehalten wurden, ist IMHO dabei nicht unbedingt ein Fehler, die - weltweite - Akzeptanz seines Ansatzes spricht durchaus für sich, auch wenn man es sicherlich besser machen könnte.

Aber, mon Dieu, es ist halt kein perfektes, aber sehr gut brauchbares Programm, das für viele gut genug funktioniert. Alternativen gibt es sicherlich - und nein, ich scheue mich nicht, Geld auszugeben für gute Programme. Allein - für meine Belange reicht es, andere Astronomie-Kollegen schwören eher auf "Guide", "The Sky" oder ähnliches, wenn die Ansprüche höher liegen.

Ein anderes Beispiel aus dem ImageProcessing-Bereich - ein Freund mit größerem Equipment und entsprechender CCD schwört auf AstroStack und findet Giotto so furchtbar, während ich persönlich mit AstroStack und kleinen Planetenscheibchen auf meiner Webcam nicht so gut klar komme, da ist für mich Giotto besser.

Eine Software ist halt dann subjektiv gut, wenn man subjektiv mit ihr das erreicht, was man möchte.

In diesem Sinne - klare Nächte
Micha
 
Hi Tom,

deiner Antwort entnehme ich, dass es in E&T keine automatischen Tests gibt, sondern alles von dir per Hand getestet wird?

Wenn du in E&T bereits Persistenz und Logik automatisch abgetestet hast, dann ist schon mal ein wichtiger Bereich abgedeckt. Dein internes Datenmodell zur Darstellung eines Bildes kannst du ebenfalls abtesten. Beim letzten Rest (das erzeugen des Bildes aus dem internen Datenmodell) kann ja dann kaum noch etwas schief gehen. Die Grafik dann selbst noch einmal abzutesten halte ich auch für reichlich nutzlos. Ein automatischer Test kann dann ohnehin nicht entscheiden, ob das generierte Bild für den Nutzer einen Nutzen hat und optisch was her macht.

Der Aufwand für das Abtesten der Darstellung steht in keinem Verhältnis zum Nutzen. Tests für die fachlichen Vorgänge sind aber wichtig. Ich sehe immer wieder wie in der Praxis viel Zeit in Fehlersuche verschwendet wird, was nicht notwendig wäre, wenn es einen automatischen Test gäbe, der die korrekte Funktion (einer Methode) ein für alle mal sicher stellt. Die Wahrscheinlichkeit, dass Test und Implementierung gleichermaßen falsch implementiert wurden, ist recht gering. Kann aber minimiert werden, wenn der Test von einem anderen Entwickler geschrieben wird, als die folgende Implementierung (oder Test per pair programming schreiben).

Bezüglich deiner Bedenken:
Eigentlich schreibt man ja erst den Test und dann die Implementierung. Wenn man sich daran hält, dann gibt es auch kein langes Release-Loch. Hat man es falsch gemacht, dann kann man aber die Tests auch Schritt für Schritt nach ziehen. Wäre denn der Aufwand so groß, z.B. für alle neuen Funktionen Tests zu schreiben?
Mag sein, dass dadurch erst einmal deine velocity geringer wird, aber dafür verbrauchst du später auch weniger Zeit beim Nachstellen und fixen von Bugs. Und natürlich musst du auch nicht mehr so intensiv manuell Testen, was auch viel Zeit kostet (Als Programmierer ist man eigentlich ohnehin bestrebt ständig wiederkehrende Tätigkeiten zu automatisieren).

Bzgl. Speicherdumps:
Mein Beileid ;-)
 
Re: etwas vom Thema abgekommen

Hi Micha,

Automatische Tests können immer nur das testen, worauf sie gedrillt sind, decken dabei aber nur einen Teil des Gesamtkunstwerks ab - und sind fast hinderlich, wenn es um ein Redesign geht ("och nöö, lieber nicht umbauen, dann müssten die ganzen Tests neu implementiert werden").
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Das ist richtig, aber wie willst du sonst permanent sicher stellen, dass dein (re)design funktioniert und kein totaler Müll ist?

Eine Software ist halt dann subjektiv gut, wenn man subjektiv mit ihr das erreicht, was man möchte.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Das ist der Zweck eines jeden Produkts. Genauso sollte Software auch angesehen werden. Ein Auto wird vor der Auslieferung auch im Werk durchgetestet. Ich bin mir sicher bei der Elektronik und bestimmten mechanischen Bauteilen ist das auch automatisiert.
 
Re: etwas vom Thema abgekommen

Zitat von mibi:
Vor allem bin ich zufrieden, dass du nicht nur {<entwickel> <test>}* -Schleifen durchläufst, sondern auch lieber mal der Astronomie als solcher nachgehst und dann höchstens "anwendest" (was nicht negativ gemeint ist!). :biggrin:
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Hallo Micha,

nur aus der Praxis heraus findet man die Funktionalität die man wirklich braucht. Mich freut es dass Anwender akzeptieren, dass ich E&T nicht mit Funktionen zupflastern möchte, die zwar einfach zu realisieren wären und die Funktionenliste werbewirksam verlängern würden, die man aber auch in einem anderen Programm findet und dort benutzen kann. So gesehen war und ist für mich CdC stets die gute und freie Alternative auf die man zurückgreifen kann, wenn E&T etwas nicht anbietet. Aus diesem Grund gibt es die Anbindung an CdC schon seit langer Zeit (um wieder zum Ausgangsthema zu kommen).

Meine persönliche Empfehlung für das "Ergänzungsprogramm" zu E&T ist allerdings Guide 8. Deswegen ist da die Kopplung sogar bidirektional und bietet besonderen Komfort.

@Euklid: fand ich sehr interessant was Du über die Entwicklungen bei CdC geschrieben hast!

Gruß,
Tom
 
Danke Euklid,

Der Update wurde aber auch fällig. Ich habe mir gleich das ganze Paket runter geladen. Ich benutze zwar auch Guide8 aber CdC finde ich auch super, gerade wenn man z.B. Doppelsterne beobachten möchte, die Sache mit dem Fähnchen finde ich Klasse. Auch der Ausdruck er Karten hat sich stark aber Version 3.1 verbessert.

Gruß
Lots
 
Moin allerseits,

ich habe mir auch das Update von CdC installiert und werde nun nur noch diese Version nutzen anstelle der bislang alten, 2.76.

Angeregt durch Thomas hab ich auch wieder Guide 8 aufgerufen. Aber die ganze Haptik liegt mir nicht und ich bin nun mal ein Typ der eher intuitiv an solche Programme rangeht und erwartet, dass es so läuft wie ich es erwarte und zB dasMausrad zoomt usw.

Daher hab ich also E&T3.1 mit CdC verknüpft und bin zufrieden.

Viele Grüße
Heiner

 
Hallo,

@Mario + Frank,

OK, danke, damit wäre das schon mal geklärt. Leider bekomme ich diesen Fehler im Details-Fenster nicht weg:

Code: 
TControl.InvalidatePreferredSize loop detected :TIpHtmlInternalPanel Bounds=l=0,t=0,r=569,b=524.
Mit Ok wird ignoriert und Dateninkonsistenz riskiert.
Mit Abbrechen wird das Programm abgebrochen.

Man kann zwar "OK" klicken oder einfach die Return-Taste, bis das Fenster verschwindet, und dann gehts wieder. Auch kann man nicht scrollen. Es erscheint ein Scrollbalken, auch wenn keiner notwendig ist, oder er ist notwendig, lässt sich aber nicht verwenden...weder mit Mausrad noch durch "Ziehen". Man muss das Fenster vergrößern, um alle Daten zu sehen, und dann kommt o.g. Fehler. Weiß vielleicht jemand Genaueres?

cs,
harald

 
Hallo Harald,

ich bin kein Experte für cartes du ciel, erst recht nicht für solche Fehlermeldungen. Nachem ich im Laufe der Zeit einige Probleme unter anderem mit Katalogzugriffen hatte, habe ich vorgestern kurzerhand cartes du ciel komplett deinstalliert und neu installiert, was wirklich ruck zuck geht - und es läuft perfekt.

Gruß und cs,

Martin
 
Status
Es sind keine weiteren Antworten möglich.
Zurück
Oben