Modulare erweiterbare Beobachtungssoftware

[Lorchi]

Hallo liebe Kollegen.

Ich möchte eine Idee in den Raum stellen, zu einem Thema das mir seit einiger Zeit im Kopf rumspukt:

wie wärs mit einem Softwareprojekt, das einfach zu erweitern ist, so dass viele Leute ihre Fähigkeiten einbringen könnten!? Im Moment stellt sich die Softwarelandschaft für mich so dar: viele Programmierer die eine Idee haben, setzen eigene Programme auf und verwirklichen sie. Es ist aber fast unmöglich, dann allen Aspekten Rechnung zu tragen.

Ein Beispiel, Autoguiding-SW: Es gab bisher mehrere schöne Programme für diese Aufgabe. Manche Programmierer haben ihre Kenntnisse von Kameras umgesetzt, andere wiederum die von robusten Tracking-Algorithmen. Aber mit einer speziellen Kamera (solange es keine Standard-Toucam ist) findet man selten ein passendes Programm. Als Beispiel die Meade-DSI Pro Kamera (eigene Erfahrung), nur wenige Programme können sie ansteuern, darunter K3CCD und Astroart, aber beide haben leider Schwächen beim Deinterlacing (Maxim habe ich nicht testen können), also dann wieder auf der Algorithmenseite.
Vielfach ist ein Projekt auch einfach zu komplex, um von einer oder wenigen Personen umgesetzt werden zu können (und sei es rein zeitlich).

Ich hatte die Idee eines Projekts, das unter anderem folgende Kriterien erfüllen sollte:

• Einfach zu erweitern, sowohl Treiberseitig, als auch die GUI, als auch Verarbeitungsprozesse, open-source
• Einfach zu bedienen bei Nacht (z.B. ausreichend große Knöpfe, die man auch auf einem Touchscreen mit dem Finger treffen könnte, zumindest die Grundfunktionen)
• Portabel

Solch ein Programm könnte irgendwann folgende Funktionen erfüllen:
- Einbindung einer Planetariums-SW
- Teleskop-, Fokus-, Domsteuerung
- Webcam/Videoaufnahme
- DSLR-Fokussierung
- Autoguiding, Scheinern
- Bildverarbeitung (RAW-Aufnahme, automatische Flatfield- und Darkframe-Verwaltung sowie Korrektur, Alignment, Stacking, WCS-Koordinaten, FITS-Files etc...)
- automatisierbare Abläufe
- und vieles mehr...

Dafür braucht man natürlich Manpower. Aber vor allem ein paar Leute, die die Koordination übernehmen, und die Schnittstellen definieren. D.h. z.B. wie neue Module einzubinden sind (Treiber, GUI, Algorithmen).
Dafür wären templates zu erstellen, die man dann um entsprechende Funktionen erweitern kann.

Ein Ansatz könnte Java sein.

Ein anderer Ansatz wäre eine Kombination aus Tcl/Tk und einer numerischen Skriptsprache (z.B. www.r-project.org). Diese Skriptsprache kann man beliebig erweitern mit z.B. C-Bibliotheken mit schnellen Routinen und Treibern und Interfaces. Das würde auch nicht-hardcore-Programmierern die Chance geben, eigene Ideen zuhause zu verwirklichen, und wenn sie funktionieren, auch anderen bereitzustellen. Oder einfach Sachen zu verbessern.

Man könnte auch auf dem RTD (real time display) vom ESO aufsetzen, das in Tcl geschrieben ist, und im Prinzip schon eine modulare GUI ist.

So. Spinn ich? Soll ich Maxim kaufen gehen? Oder wäre das tatsächlich eine Grundidee, über die man nachdenken könnte? Ich selbst möchte das aber auch nicht koordinieren müssen... spinn ich noch immer nicht? <img src="/phpapps/ubbthreads/images/graemlins/grin.gif" alt="" />

Bibliotheken mit dafür nützlichen Funtionen gibt es viele, man müsste ja nicht bei Null anfangen...

Sodala, sagt mal was dazu...

Grüße, Henning

 

[Marfir]

Hallo Henning!

Ich hatte die Idee eines Projekts, das unter anderem folgende Kriterien erfüllen sollte:

* Einfach zu erweitern, sowohl Treiberseitig, als auch die GUI, als auch Verarbeitungsprozesse, open-source
* Einfach zu bedienen bei Nacht (z.B. ausreichend große Knöpfe, die man auch auf einem Touchscreen mit dem Finger treffen könnte, zumindest die Grundfunktionen)
* Portabel

Generell klingt das erst mal gut und sinnvoll.
Um das ganze einfach und erweiterbar zu halten müsste das Programm z.B. nach dem MVC-Paradigma aufgebaut sein. Und für die Plattformunabhängigkeit wäre Java, wie du schon vorgeschlagen hast, eine gute Idee.
Vorallem muss das Projekt sehr gut Dokumentiert werden, wenn mehrere daran arbeiten und dies später auch weiter entwickelt werden soll!


Ist dein Beispiel mit der Autoguiding-SW dein eigentliches Ziel soetwas zu programmieren, oder hattest du noch an etwas anderes gedacht?

Gruß,
Marfir

 

[Lorchi]

Hallo Marfir,

ja genau, MVC klingt gut.

Richtig, die Dokumentation ist eigentlich das wichtigste, wichtiger als einzelne Funktionalitäten. Das beinhaltet die Schnittstellendefinitionen sowie Templates etc...

Mein Favorit wäre Tcl/Tk als Frontend, weil es einfach und robust genug ist, um wirklich von vielen Leuten erlernbar zu sein. Aber das ist nur mein Vorschlag, sollte so ein Projekt tatsächlich zustande kommen, wäre das nur mein Voting. Ich werde mir demnächst beruflich das ESO RTD ansehen, ich weiß noch nicht ob es auf Windows portabel ist, aber es hätte den Vorteil, dass es schon ein vollständiges Frontend ist, das zu demselben Zweck entwickelt wurde, und bereits dokumentiert ist. Wäre schön, wenn man das Rad nicht neu erfinden müsste.

Mein Beispiel der Autoguiding-SW war der Auslöser für die Idee (aus teilweise genannten Gründen... es gibt wirklich schöne Guidingprojekte, aber alle kränkeln an der Erweiterbarkeit). Weitere eigene Motivationspunkte waren automatisierte Prozesse, die sich die (RAW-)Kamerabilder vornehmen.

Daher kam dann meine Idee, einen numerischen Interpreter als Hintergrundsystem zu verwenden. Zeitkritische Prozesse kann man als eigene Erweiterung einbinden. Ansonsten lassen sich damit schnell robuste Vorgänge definieren. Ich denke, Einfachheit ist wichtiger als das letzte Quentchen Performance. Ich schreibe beruflich Verarbeitungsalgorithmen in C, aber das ist aufwändig, ich würde eine Makrosprache bevorzugen, weil sie einfach flexibler ist. Numerische Interpreter sind ja mittlerweile sehr mächtig, bieten Klassendefinitionen etc. Aber ich habe (noch) keine Ahnung von Java und kann es nicht vergleichen.

Gruß, Henning

 

[circushund]

Hi Hennig,
Klingt gut was du da vorhast, obwohl ich nur die Häfte vestehe (passiert mir manchmal wenn ich nur Abkürzungen lese <img src="/phpapps/ubbthreads/images/graemlins/smile.gif" alt="" /> ).
Ok, wenn du magst log ich mich da ein undwar würde ich NUR die GUI übernehmen, also fast nix programmieren sondern nur die Steuerelmente sprich Buttons, Icons ect. machen und an die richtigen Stellen setzen.
Mein Spezialgebiet ist die Software-Ergonomie und ich würde mich gerne nur auf diesen Bereich beschränken da er mir am meisten liegt und auch am leichtesten fällt.
GUI und Software Ergonomie Appartment: Don alias Circushund

 

[Lorchi]

Hallo Don,

das ist prima! Ergonomie ist sehr wichtig. Klar und jeder macht nur das, was ihm liegt und was er kann.

Ich muss jedoch sehr vorsichtig sein: ich wollte hauptsächlich die Idee ausbreiten. Ich selbst könnte das nicht leiten oder koordinieren, weil es oft passiert dass ich mal gar keine Zeit habe. So ein Projekt darf, wenn es mal eine gewisse Stufe erreicht hat, nicht von einer Person abhängig sein. Daher möchte ich es auch nicht als mein Vorhaben ansehen.

So wie ich das sehe, müsste man folgende Aufgaben verteilen (mal unabhängig von den Anwendungen), ohne Anspruch auf Richtigkeit:
- Konzept, Definitionen (das muss jemand erfahrenes sein!)
- Treiber- bzw. Schnittstellenkonzept und -programmierung (Webcams, CCDs, DSLR, Teleskop & Dom & Fokussierer (Ascom), andere I/Os (Webcam Langzeit, Guider-Relaisbox etc.) mit universeller Schnittstelle und was sonst noch so kommt
- Prozesse, Algorithmen
- GUI (zur GUI-Entwicklung gehört auch ihre Modularisierung)
- Dokumentation, Templates für Zusatzmodule
- universelle Datenbank (Einstellungen, Objektkatalog-Einbindung, aufgenommene Bilder und Filme mit entsprechenden Tags)
- Konzept für automatisierte Bildvorverarbeitung (z.B. automatische Flatfield- und Darkframe-Auswahl aus der Datenbank und Korrektur auf RAW-Datenebene, evt. auch nach der Beobachtungssession automatisch Aufnahme der benötigten Darkframes, z.B. während der Autofahrt), evt. scripting-fähig

Ich selbst sehe mich bei den Prozessen und Algorithmen, darin kenne ich mich am besten aus.

Was mir sonst noch so einfällt an technischen Details (also als Vorgriff):
- die GUI muss selbst erkennen, welche Softwaremodule vorhanden sind, und diese als Funktion anbieten
- die einzelnen Softwaremodule stellen ihre eigene(n) GUI(-Elemente), welche eingebettet wird/werden
- es gibt eine (!) Klasse als Bilddateneingang, welche von den Softwaremodulen angesprochen werden kann, und die Kameras in sich versteckt
- Selten zu treffende Einstellungen können in Konfigurationsmenüs versteckt sein. Alles was man nachts braucht, sollte so einfach wie möglich zu bedienen sein, und möglichst wenig/keine Tastatureingaben erfordern (Stichwort Touchscreen als einziges Bedienelement bei Nacht, das ist mein persönlicher Traum).
- Ein einziges Hauptfenster, kein zufälliges Chaos von sich verdeckenden Popups und Zusatzfenstern, und im Hauptfenster auch Ordnung, z.B. mithilfe von Tabulatoren. So dass die Anwendung "self-contained" den Bildschirm ausfüllen kann und man sonst nichts mehr braucht, so zuverlässig und integriert wie ein Meßgerät.
- Die einzelnen Softwaremodule müssen natürlich parallel laufen können, Stichwort DSLR-Aufnahme und Guiding

Folgende Softwaremodule könnten nach und nach kommen:
- Guiding, Scheinern, PE-Aufnahme
- Webcam/CCD/DSLR-Fokus und Aufnahme, automatische Aufnahmesequenzen (natürlich mit manuellem Eingreifen)
- Anzeige der aktuellen Daten (Ephemeriden, Sternzeit, Drehung Polaris etc etc)
- Objektkatalog Anzeige
- Beobachtungs-Logbuch (mit automatischen Einträgen/Vorschlägen bei GoTo oder Decodern)
- Planetarium (ok jetzt fange ich an zu spinnen, aber wenn sich das Projekt ein paar Jahre hält und nicht gleich wieder stirbt, könnte es realistisch werden, obwohl ich z.B. CDC sehr schätze)
- Bildverarbeitung: Korrekturen, Kontrastangleichungen, Stacking, Mosaiking

Mir ist bewusst, dass sich diese Idee mit anderen Projekten überlappt, und dadurch nicht nur Freunde gewinnen könnte. Aber es wäre ein neuer Versuch, etwas dauerhaftes zu starten. Und das hängt fast einzig an jemandem, der ein gutes Konzept aufstellt. Das schließt leider ein, dass schnelle Hacks nicht mitaufgenommen werden können, sondern alles sich diesen Spielregeln zu unterwerfen hat (Stichwort Schnittstellen sowie Dokumentation).

Grüße, Henning

 

[Lorchi]

Nochmal ich <img src="/phpapps/ubbthreads/images/graemlins/wink.gif" alt="" />

Don, ich habe mir gerade Dein online-Planetarium angesehen, das sieht echt hübsch aus!!

In unserem Fall müsste, da es ja modularisierbar sein soll, für eine nicht komplett den Defaultknöpfen entsprechende Oberfläche, ein zusätzlicher dokumentierter Abstraktionslayer eingeführt werden. Aber das muss er wahrscheinlich bei fast jeder Schnittstelle in so einem Projekt.

Gruß, Henning

 

[circushund]

... für eine nicht komplett den Defaultknöpfen entsprechende Oberfläche, ein zusätzlicher dokumentierter Abstraktionslayer eingeführt werden. Aber das muss er wahrscheinlich bei fast jeder Schnittstelle in so einem Projekt.

hä ? - Von was redest du ? Ich glaub du kommst da mit deiner Wortwahl etwas durcheinander ?

- Ein einziges Hauptfenster, kein zufälliges Chaos von sich verdeckenden Popups und Zusatzfenstern, und im Hauptfenster auch Ordnung, z.B. mithilfe von Tabulatoren. So dass die Anwendung "self-contained" den Bildschirm ausfüllen kann und man sonst nichts mehr braucht, so zuverlässig und integriert wie ein Meßgerät.

Wird vom GUI Appartment nicht genehmigt <img src="/phpapps/ubbthreads/images/graemlins/smile.gif" alt="" />, wirkt zu technisch und Benutzerunfreundlich. Auf ein Fenster wird man nicht alles unterbringen können, höchstens das Wichtigste. Für Zusatzfunktionen werden immer spezialle Fenster notwendig sein! Steuerung per Voice Over ( bei Mac ein Verfahren wo man durch Spechen ein Befehl an das Programm bzw. den Computer gibt ) und Bildschirmtastatur sind alternative Eingabe-Möglichkeiten.
Und was meinst du speziell mit Modularisierung der GUI ? Ich meine, man könnte verschieden Icon-Themes machen oder sich evtl. verschieden Hintergründe der Fenster ect. einstellen können. Ich betrachte die Software eigentlich mehr aus ergonmischen Aspekten sprich "Wo ist was zu finden ? Was muss man machen um ? Wie einfach/schnell ist es dies oder jenes einzustellen? ect..
Ich weiss nicht, Modularisierung ist da doch eher nicht so angebracht ? Extra ein Klasse, Modul odersonstwas zu programmieren, um sich zB. eigene Buttons ect. bauen zu könne, ist wohl recht kompliziert und wenn, das ist eure Aufgabe <img src="/phpapps/ubbthreads/images/graemlins/wink.gif" alt="" />. Eine Java-Anwendung wir niemals wie ein Flashfilm aussehen und umgekehrt.

Summasumarum:
Viele der Dinge ( so bezeichne ich sie jetzt mal ), die du in deiner Philosophie
aufzählst sind "Arbeit der Programmierer" und ich sag mal, darüber könnt ihr euch streiten. Mir geht es einzig und allein um die Schnittstelle (nicht Computer-Schnittstelle) von Comuter und Mensch.
Ich könnte es auch in einem Wort sagen: Optik.

 

[Marfir]

Hallo Henning,

deine Ideen sind zwar sehr konkret, werden wohl aber an der Dimension scheitern.

Beispiel Treiber:
Wenn das Tool Plattformunabhängig sein soll, dann bräuchtest du für jedes Betriebssystem einen, der Treiber programmiert. Gerade unter Windows wird das nicht gerade einfach.

Beispiel Dokumentation:
Hier sollte jeder seinen Teil selbst Dokumentieren. Einen abzustellen der das als einzige Aufgabe hat geht daneben...

Beispiel universelle Datenbank:
Nettes Vorhaben. Aber auch hier brauchst du Leute die das DB Modell machen, sich z.B. mit XML beschäftigen (zum Datenaustausch) und das ganze programmieren. Ggf. noch ne Update-Funktion übers Internet programmieren.

Beispiel Konzept, Definitionen:
Auch das kann nicht einer alleine machen. Hier wäre eine Gruppenarbeit mit aktiven Diskutieren wichtig.


Wenn ich mir alles so anschaue brauchst du ne ganze Fußballmanschaft. Wo willst du die her nehmen?
Das sich jmd. hier für die GUI zur Verfügung stellt, ist ja schon das aller größte! Fraglich ob du für den Rest auch noch Leute findest.

Ich wünsch dir aber trotzdem viel Erfolg! <img src="/phpapps/ubbthreads/images/graemlins/Spitze.gif" alt="" />


PS:

die GUI muss selbst erkennen, welche Softwaremodule vorhanden sind, und diese als Funktion anbieten

Die GUI erkennt gar nix! Siehe MVC-Paradigma. Die Module zu "erkennen" und in die GUI einzubinden obliegt dem Control-Teil. Entweder du baust für die GUI Interfaces und lädst dynamisch Klassen nach (bei Java) oder baust das irgend wie anders. Der Control-Teil kann ja auch abhängig der installierten Pakete die GUI "erzeugen".

 

[Lorchi]

Gut gut,

deine Ideen sind zwar sehr konkret, werden wohl aber an der Dimension scheitern.

Vielleicht wird es an mangelnden Interessenten scheitern.

Aber die Grundidee setzt absolut ein modulares Konzept voraus. Und das bedeutet, dass die "Dimension" wachsen kann, es soll nach oben offen sein, das ist der Kern. Damit kann man langsam anfangen.

Aber ich muss schon zustimmen:

Wenn das Tool Plattformunabhängig sein soll, dann bräuchtest du für jedes Betriebssystem einen, der Treiber programmiert. Gerade unter Windows wird das nicht gerade einfach.

Musstest Du mich daran erinnern <img src="/phpapps/ubbthreads/images/graemlins/grin.gif" alt="" /> Ja stimmt, aber es muss ja nicht alles auf einmal sein. Beispiel Webcam-Treiber unter Windows, wie weit es da z.B. linux-mäßig ist weiß ich grad nicht. Aber das ist ein prima Beispiel: man muss eine gute Schnittstelle definieren, die dann auf jedem System benutzt würde. Hinter diese käme (nach meiner naiven Vorstellung) einfach noch eine Ebene, die zu den vorhandenen Systemtreibern übersetzt.

Beispiel Dokumentation:
Hier sollte jeder seinen Teil selbst Dokumentieren. Einen abzustellen der das als einzige Aufgabe hat geht daneben...

Volle Zustimmung, keine Frage.

Beispiel universelle Datenbank:
Nettes Vorhaben. Aber auch hier brauchst du Leute die das DB Modell machen, sich z.B. mit XML beschäftigen (zum Datenaustausch) und das ganze programmieren. Ggf. noch ne Update-Funktion übers Internet programmieren.

Auch das ist richtig. Aber auch hier könnte man mit einem geringen Funktionsumfang anfangen, bzw. vorhandenes nutzen und Schnittstellen bauen.

Wenn ich mir alles so anschaue brauchst du ne ganze Fußballmanschaft. Wo willst du die her nehmen?
Das sich jmd. hier für die GUI zur Verfügung stellt, ist ja schon das aller größte! Fraglich ob du für den Rest auch noch Leute findest.

Großes Auto -> Fußballplatz -> Tür auf -> Fußballmannschaft rein -> Tür zu -> und los <img src="/phpapps/ubbthreads/images/graemlins/grin.gif" alt="" />
Im Ernst, im glaube dass 4-5 Programmierer einen Start möglich machen würden.

Die GUI erkennt gar nix! Siehe MVC-Paradigma. Die Module zu "erkennen" und in die GUI einzubinden obliegt dem Control-Teil. Entweder du baust für die GUI Interfaces und lädst dynamisch Klassen nach (bei Java) oder baust das irgend wie anders. Der Control-Teil kann ja auch abhängig der installierten Pakete die GUI "erzeugen".

Stimmt, war sehr nachlässig ausgedrückt. Aber Du hast es gut angedeutet. Eine sehr simple Möglichkeit wäre ein Rahmen in der GUI, dessen Inhalt je nach vorhandenen Modulen erzeugt/gefüllt wird. Mit einem Reiter könnte man zwischen den Modulen umschalten...

Viele Grüße, Henning

 

[Lorchi]

hä ? - Von was redest du ? Ich glaub du kommst da mit deiner Wortwahl etwas durcheinander ?

Ummm ich habs gewusst <img src="/phpapps/ubbthreads/images/graemlins/grin.gif" alt="" />, ich meinte folgendes: wenn Du so schöne bunte Knöpfchen machen wolltest, müsste wohl eine Ebene dazwischen. Aber ich gebe Dir recht, dass das total überflüssig ist.

Wird vom GUI Appartment nicht genehmigt <img src="/phpapps/ubbthreads/images/graemlins/smile.gif" alt="" />

Meinst Du Department <img src="/phpapps/ubbthreads/images/graemlins/cool.gif" alt="" />

Ähmmm klar, ALLES passt nicht in ein Fenster. Um ein Beispiel zu nennen: kennst Du Gimp? Das finde ich von der Bedienung her katastrophal, weil alles immer irgendwo im Hintergrund verschwindet, und ich mir die Teile in der Taskleiste wieder zusammensuchen muss.

Was ich persönlich zu verschiedenen GUIs meine:
Photoshop z.B. ist schon wesentlich schöner als Gimp, denn es bleibt alles in einem Hauptfenster. Dennoch finde ich auch das nicht optimal, weil die Toolboxes und Paletten etc. sich wieder gegenseitig überlappen können, und ohnehin ihren Platz brauchen. Da nützt es nicht viel, dass man das Foto darunter größer darstellen kann, wenn es darunter verschwindet. Da verrichte ich als Benutzer immer noch Arbeit, nur um die GUI zu bedienen.

Mozilla ist schöner: verschiedene Webseiten werden in einem Rahmen dargestellt, und lassen sich per Tabulator umschalten (tabbed browsing). Da gab es auch mal ein prima Platinen-Layout-Programm namens Protel, in dem sich ebenfalls die einzelnen Inhalte mit Tabulatoren wechseln lassen.

Und letzteres meinte ich. Man braucht keine Task-Leiste mehr, um das Programm zu bedienen, und "floatende" Paletten fliegen auch nicht im Weg rum. Weißt Du, was ich meine? Das hat mir persönlich zumindest immer am besten gefallen. Klar kann irgendwo ein Info- oder Preferences-Fensterchen aufgehen.

Was ich mit modularisierbarer GUI meinte, hat Marfir besser ausgedrückt, und ich in meiner Antwort an ihn nochmal bestätigt. Es könnte z.B. so aussehen, dass Modulfunktionen in Tabs dargestellt werden.

Nun, ich hoffe ich konnte es irgendwie rüberbringen. Was hältst Du als "Optiker" <img src="/phpapps/ubbthreads/images/graemlins/cool.gif" alt="" /> davon?

Grüße, Henning

 

[Thomas_Pfleger]

Hallo Henning,

ich sage dazu nur eines: als ich 1994 mit ersten Studien zu E&T begonnen habe, kam mir die damalige "Vision" vor wie Science Fiction. Es sah völlig utopisch aus, dieser Wunschvorstellung hinreichend nahe zu kommen. Aber zehn Jahre später sieht's schon freundlicher aus.

Will heißen: man braucht viel Geduld und noch mehr Motivation für sowas. Und muss realistisch bleiben: Du brauchst für so ein Projekt meiner Schätzung nach für ca. fünf Jahre jemanden, der die Strippen zieht und als Mastermind sagt wo's langgeht. Und die Leute bei der Stange hält. Das ist nicht leicht, besonders wenn sich die Diskussionen über die technischen Details ergeben. Mit Freaks keine Chance (da ist es nur eine Frage der Zeit, bis die sich wegen einer an sich unwichtigen Designentscheidung gegenseitig an die Gurgel gehen), nur ein Team von glaubenskriegresistenten Pragmatikern verspricht überhaupt Erfolg.

Damals anno 1998 habe ich tatsächlich ein "Pflichtenheft" geschrieben und meinen Astrokumpels zur Kritik gegeben. Denn man muss zuerst mal ein möglichst klares Bild haben was man haben will. Wenn Du dieses klare Bild von den künftigen Anwendern nicht bekommst lohnt es sich nicht, überhaupt anzufangen. Man kann das sortieren in core requirements und Sachen die später kommen können.

Ich persönlich finde den Ansatz eines universellen "Eierlegende Wollmilchsau-Programms" nicht attraktiv, weder aus der Sicht eines Entwicklers noch aus der eines Anwenders. Solche mächtigen Programme neigen immer zu einem fett überladenen GUI, ich denke da besonders an SkyTools 2, aber auch Guide. Aber man kann es auch gut machen (Starry Night, TheSky 6 mit dem Display Explorer). Don hat mir auch schon Tipps gegeben, er hat eine Menge Ahnung von Usability <img src="/phpapps/ubbthreads/images/graemlins/Spitze.gif" alt="" />

Meine Zielrichtung geht eher in Richtung Schnittstellen und Austauschformate. Warum nicht versuchen, das ASCOM-Portfolio in Richtung neuer Interfaces oder Objektmodelle zu erweitern? OK, ich habe mal einen Vorschlag für eine "Planetariumsprogramm-API" gemacht (um Kartensoftware von aussen anzusteuern, so wie E&T das rudimentär macht), aber man wollte nichts davon wissen. ASCOM erklärte sich nur für Hardwaretreiber für zuständig. Aber wenn ihr kommt und einen wirklich guten Vorschlag macht mag es anders aussehen. Ich glaube es gibt sogar eine Java-Einbindung für ASCOM, es muss also nicht unbedingt draussen bleiben nur weil es originär für Windows ist.

Falls Du mit Deinem Projekt eines Tages loslegst, könnte man über Erweiterungen des VdS XML Schemas für Beobachtungen nachdenken, das derzeit für die Bedürfnisse visueller Deep Sky Beobachter entwickelt ist/wird. Das Schema ist modular angelegt, seine abstrakten Basistypen könnten beerbt werden. Man muss nicht alles von Grund auf neu erfinden. Wäre nett, wenn Du irgendwie auf das Format eingehst, damit Anwender von "Lorchisoft's Observatory Master" ihre Beobachtungen mit anderen Anwendungen/Anwendern austauschen können (soweit semantisch sinnvoll und technisch möglich).

Ich finde die Idee komisch, eine "freundliche" Programmumgebung zu verwenden, die auch wenig erfahrenen Leuten Beiträge ermöglichen soll. Das ist sehr sozial gedacht und klingt gut, aber Du wirst früher oder später an den Punkt kommen, wo es wirklich ins Eingemachte geht und gewisse OS-nahe Geschichten einfach nötig werden. Dann ist es gut, wenn man eine Umgebung benutzt, mit der man bis zum Bodenblech runterkommt und notfalls auch OS-APIs aufrufen kann.

Gruß,
Tom

 

[Lorchi]

Hallo Tom,

danke für Deinen langen Beitrag. Ich kann gerade leider nur kurz antworten:

Das ist nicht leicht, besonders wenn sich die Diskussionen über die technischen Details ergeben. Mit Freaks keine Chance

Das ist wohl wahr...

universellen "Eierlegende Wollmilchsau-Programms" nicht attraktiv

Du bringst mich ins Grübeln... danke dafür. Ja ich sollte meine Ideen wieder etwas runterschrauben auf den Kern, der mir im Sinn stand:
ein Bedienprogramm fürs Teleskop und die Kameras, das erweiterbar ist und sich bei Nacht leicht bedienen lässt, sozusagen ein Control Center. Mit der Fähigkeit allerdings, Darkframes und Flatfields in irgendeiner Weise zu handhaben und z.B. beim Guiding zu verwenden.

Nachverarbeitung und andere Scherze wie Tagebuch etc. sind natürlich für die Steuerung der Geräte bei Nacht unnötig und würden es aufblähen. Das ist wahr.

Warum nicht versuchen, das ASCOM-Portfolio in Richtung neuer Interfaces oder Objektmodelle zu erweitern?

Das wäre toll, allerdings...

könnte man über Erweiterungen des VdS XML Schemas für Beobachtungen nachdenken

Ja. Es wäre das Ziel, soviel wie möglich wiederzuverwenden, am besten Projekte die auf Vereinheitlichung abzielen.

Ich finde die Idee komisch, eine "freundliche" Programmumgebung zu verwenden

Komisch ist es vielleicht. Ich sehe darin eher eine Chance. Bis zum Bodenblech kommt man sehr einfach, indem man eigene Kommandobibliotheken schreibt und einhängt. Das wird gerne ab und zu in der Entwicklung von Geräten verwendet, wenn z.B. mit Matlab schnell eine Meß- und Bedienoberfläche für einen Motorenprüfstand erstellt wird. Es wäre sozusagen eine alternative Skriptsprache, in der Modell-, View- und Kontrollteil gestrickt werden könnten. Nur nicht mit dem teuren Matlab. Soweit zu dieser Idee.

Gruß, Henning

 

[Marfir]

Was ich mit modularisierbarer GUI meinte, hat Marfir besser ausgedrückt, und ich in meiner Antwort an ihn nochmal bestätigt. Es könnte z.B. so aussehen, dass Modulfunktionen in Tabs dargestellt werden.

Oh je oh je. Ich glaub jetzt sind wir alle verwirrter als vorher!

Als ich das Wort "modul" lass, dachte ich an nicht an die Darstellung der GUI (z.b. als Tab wie du), sondern an den Controlteil (wie wird die GUI erzeugt? statisch oder dynamisch?).

Wenn du pro Modul ein Tab machen willst, ok. Dann wäre dies also eine statische GUI pro Tab und 1 dynamische GUI für den "Rahmen".


Tom muss ich auch hier recht geben. Konzentriere dich auf den Kern! Wenige Funktionen und später erweitern. Wenn du eine schöne offene Struktur hast, dann haste später auch keine Probleme weitere Module einzubinden.

Das Problem ist auch die Motivation. Wenn die freiwilligen Helfer sehen das Ihre Arbeit Jahre dauern wird, werden wohl mehr Leute abspringen, als wie wenn jeder nen kleinen Teil macht und seine Arbeit Früchte trägt (sprich beim User gleich genutzt werden kann, und nicht erst zum Projektende in xy Jahren).

Vll startest du besser erst mal einen Aufruf im Forum usw. wer Lust hat und welche Qualifikationen die Leute haben? Dann haste einen groben Überblick welche Teile deines Projektes "sofort" machbar sind und welche warten müssen.

Die Frage ist auch, ob das Projekt dann auch ne Mehrsprachige GUI bekommt? Das müsste nämlich vor dem Coden auch gleich mit beachtet werden. <img src="/phpapps/ubbthreads/images/graemlins/grin.gif" alt="" />

 

[circushund]

@Henning,
ok, für mich ist die Diskussion jetzt zu ende und der Arbeitsteil beginnt <img src="/phpapps/ubbthreads/images/graemlins/smile.gif" alt="" />. Wenn du, ihr etwas habt, schickt es mir rüber und ich versuch was "optisch" raus zu holen.
Ich kann es auf Mac oder PC testen. Evtl. Programmierumgebeungen ect. kann ich da installieren. Also ich werde warscheinlich die meiste Zeit die Beine hochlegen, da ich nur die Icons mache, die aber dann professionell aussehen und ich relativ schnell erledigen kann.
Über die Komplexität des Programms würde ich auch sagen, das es im Rahmen sein soll:
Auszug aus Apple User Interface Guidlines:

Avoid Feature Cascade
If you are developing a simple application, it can be very tempting to add features that aren’t wholly relevant to the original intent of the program. This feature cascade can lead to a bloated interface that is slow and difficult to use because of its complexity. Try to stick to the original intent of your program and include only features that are relevant to the main workflow.

The best products aren’t the ones with the most features. The best products are those whose features are tightly integrated with the solutions they provide, making them the most usable.
Making Design Decisions

When making design decisions regarding features in your application, it’s important to weigh the costs, not all of which are financial, against the potential benefits. Every time you add a feature to your application, the following things can happen:

Your application gets larger.
Your application gets slower.
Your application’s human interface becomes more complex.
You spend time developing new features rather than refining existing features.
Your application’s documentation and help become more extensive.
You run the risk of introducing changes that could adversely affect existing features.
You increase the time required to validate the behavior of your application.
Choosing appropriate features and devoting the needed resources to implement them correctly can save you time and effort later. Choosing poor feature sets or failing to assign appropriate design, engineering, testing, and documentation resources often incurs heavier costs later when critical bugs appear or users can’t figure out how to use your product.

The following sections present several additional factors to take into consideration before adding features to your product.

Meine Email:
DWienand@gmx.net
HP:
www.dwienand.de

 

[Thomas_Pfleger]

Besser als Apple's Guideline kann man es nicht ausdrücken.

Genau das ist auch der Grund, warum es in E&T keine Ephemeridenrechnung, keinen Animationsmodus, keine integrierte Bildverarbeitung etc. pp. gibt bzw. geben soll. Konzentration auf die Kernaufgabe, und dort solange feilen bis auch noch die letzte Inkonsistent beseitigt und die Haken und Ösen verschwunden sind. Neue Features sind natürlich nicht ausgeschlossen, aber sie müssen in die Grundidee und Zielsetzung passen.

@Henning: die Idee mit einem "Control Center" finde ich viel attraktiver. Allerdings setzt sie voraus, dass die zu integrierenden Anwendungen mitspielen. D.h., dass sie im Idealfall offizielle Schnittstellen anbieten (egal mit welchem technischen Medium, auf Windows kann es HTTP sein, DDE oder OLE kommen auch in Frage) oder allgemein gängige Dateiformate benutzen.

E&T steuert Kartenprogramme an, indem deren Bedienung quasi simuliert wird. Das ist mühsam, geht aber ganz gut. Entscheidender Nachteil ist, dass E&T wissen muss, wie die Fensterstruktur und die Kommando-IDs der anderen Anwendung aussehen. Das bekommt man mit entsprechenden Tools (Spy++ vom Visual Studio) zwar heraus, aber die Anbindung kann kaputtgehen, wenn die nächste Version der anderen Anwendung irgendwas am GUI ändert. Inzwischen habe ich stabile Anbindungen für HNSky und CdC (via DDE), TheSky 6 Pro (via OLE) und Guide 8 (mit Bill Gray persönlich vereinbart, habe ihn jahrelang hartnäckig angebettelt deswegen). SkyMap und Megastar gehen mit dem nächsten Upgrade wahrscheinlich wieder kaputt :-( Bei StarryNight verwenden sie ein ungewöhnliches Window-Toolkit mit Fensterstrukturen, in die man kaum reinkommt. Deshalb gibt's dafür auch keine Anbindung. Und Java Swing hat gar keine erkennbare Fensterstruktur in Frames, dort wird offenbar alles programmatisch hingezeichnet. Eine Swing-Anwendung könnte man mit meiner Technik also nicht "hijacken". Eine SWT-Anwendung wie Eclipse dagegen schon.

Die Frage wäre aus meiner Sicht, was die Funktionalität eines solchen Control Centers bzw. sein Mehrwert für den Anwender wäre.

Sowas in der Art gibt es fix und fertig von Software Bisque, es heisst bei denen "Orchestrate" und erlaubt das Scripting von Kuppelcontroller, Montierung und CCD-Kamera. Die Bisque-Programme haben OLE-Schnittstellen und ein sinnvolles Objektmodell. Zusätzlich gibt es Serversoftware zur Remote-Steuerung automatisierter Observatorien. Wer das alles "braucht" kann es für ca. 1000$ als Komplettpaket kaufen.

Ein "Control Center" zu bauen läuft in gewisser Weise darauf hinaus, Orchestrate nachzuahmen. Wenn es gelänge, den Bisque-Ansatz (den ich gleichermaßen durchdacht wie konsequent finde) auf zu integrierende Programme zu übertragen und auf entsprechende Schnittstellen zu drängen bzw. notfalls solche Wrapper zu bauen wie sie E&T verwendet wäre für Sternfreunde ohne "millionenschweres" Budget eine tolle Lösung erreicht.

Sofern mein Wrapping-Knowhow für ein solches Vorhaben nützlich ist, stelle ich es gerne zur Verfügung (auch mit Codes in C++). Ich werde allerdings keinen Code speziell für euer Projekt entwickeln. Allerdings hatte ich schon mal daran gedacht, die "Fernsteuerungskomponenten" von E&T herauszulösen und als COM-DLLs mit dualer OLE-Schnittstelle zur Verfügung zu stellen. Samt Quelltext natürlich, damit bei künftigen Änderungen der angesteuerten Programme auch mal jemand anders als ich eine Anpassung vornehmen könnte.

E&T selbst benutzt übrigens nicht nur fremde Schnittstellen, sondern bietet auch selbst eine (kleine) an. Ein Control Center kann damit z.B. das aktuelle Objekt auf eine Karte setzen, in ein Projekt oder einen Beobachtungsplan einfügen bzw. einen neuen Logeintrag dafür anlegen. Ich hoffe, dass diese Funktionen künftig auch von anderen Programmen verwendet werden, aber das wird wohl erst der Fall sein, wenn E&T in englisch verfügbar und hoffentlich viel weiter verbreitet ist als heutzutage (die Amis kennen E&T nicht, aber die meisten wichtigen Programme kommen von der anderen Seite des Atlantiks).

Ich würde nun an eurer/Deiner Stelle erst mal recherchieren, ob bzw. welche Schnittstellen die relevanten Programme z.B. zur Kamerasteuerung zur Verfügung stellen. Ich kann auch gerne mal Georg Dittié (Giotto) darauf ansprechen, ich weiß, dass er seit längerem an Batchskripts denkt, er kennt sich mit COM aus und ich kann bei Bedarf dabei helfen, einer VC++ Anwendung (auch Giotto ist damit realisiert) eine duale OLE-Schnittstelle zu verpassen <img src="/phpapps/ubbthreads/images/graemlins/wink.gif" alt="" />

Gruß,
Tom

 

[circushund]

ok,
jetzt muss ich mich doch nochmal melden, den eine dringende Frage bzgl. Benutzerfreundlichkeit kommt mir da auf <img src="/phpapps/ubbthreads/images/graemlins/smile.gif" alt="" />.

Es geht um den Nacht bzw. Rotmodus.
Wie ich finde, ist es eine der wichtigsten Dinge, um ungeschadet (bzgl. Adaption des Auges) einen Beobachtungsnacht mit dem Computer zu machen.
Und das es auch wirklich Spass macht und seine Software auch wirklich Nachts benutzen kann, denn dafür ist sie ja auch irgendwie da oder sollte zumindest ?
Ich hab dazu mal 2 Screens abfotografiert, damit man es mal vergleichen kann. Einmal an einem Mac und einmal am PC Notebook.
Link zur Grafik: http://www.dwienand.de/Expo/N_pc.jpg
Link zur Grafik: http://www.dwienand.de/Expo/N_mac.jpg
auffallend an beiden Bildern ist, das die Monitore, auch wenn sie "Schwarz" sind, also Helligkeit=0 haben, trotzdem Licht vom Screen abgeben.
Dieses Hintergrundleuchten lässt sich bei beiden Monituren nur duch die Helligkeitsregelung dimmen, aber ganz weg geht es nicht.

Der gravierende Unterschied dieser beiden Nachtmodi ist nun folgender:
Der obere Screen zeigt CDC im Nachtmodus, dabei wird versucht, mittels einfärben der Icons und ändern der Hintergrund und Schriftfarbe, einen Rotbildschirm zu simulieren. Die Gefahr dabei ist jedoch, dass sobald man zB auf den Dektop wächselt oder sonstiges machen will, Strahlen die übrigen Elemente dh.. Titelbar, Taskbar ect. zu stark und die Adaption geht verloren. Gerade in der Nacht ist das Auge ja so empfindlich und reagiert stark auf Kontrastschwankungen.

Ganz anders sieht es im unteren Screen aus. Hier läuft ein "echter" Rotmodus, dh. der ganze Bildschirm ist komplett in ein tief weinrot eingetaucht, gerade so, als hätte man ein Weinglas auf dem Bildschirm ausgekippt.
Dh. das Tool (DarkAdapt) zieht den Blau und Grün-Kanal komplett auf 0% und dimmt zusatlich den Gammawert runter.
Dh. ich kann ohne Gefahr mit dem Computer komplett arbeiten.

Beim Pc gibt es ja bei vielen Grafikarten extra Einstellungen, wo man die Gamma Werte an einer Kurve rauf und runter zeihen kann und evtl. auch die einzelnen Kanälen einzeln verstellen ?

Frage ist, was habt ihr für Erfahrungen? Ich hab den Mac noch nicht raus genommen und über längere Zeit gearbeitet. Ich kann mir aber vorstellen, das man mit zunehmender Dunkelsichtigkeit, den Bildschirm auch immer weiter runterdimmen will, denn das was man indoor noch grade kontrstmässig unterscheiden kann, ist in der Nacht gut zu unterscheiden?

 

[Thomas_Pfleger]

Hi Don,

den Code für den Nachtmodus hat mir Han Kleijn (HNSky) zur Verfügung gestellt. Dort werden die Systemfarben während des Nachtmodus verändert, was auf alle Programme wirkt.

Meine Erfahrung ist aber, dass man um eine rote Scheibe vor dem Screen nicht herumkommt. Glücklicherweise hat mir eine Bekannte passgenau zugeschnittenes Plexiglas besorgt (in kleinen Mengen kommt man da schwer dran), in die Scheibe hab' ich oben zwei 6er Löcher reingebohrt und Du hängst die Scheibe damit einfach in den Halteklammern des Displays ein. Funktioniert hervorragend, kann ich nur empfehlen. Wenn man kein Plexi austreiben kann, geht auch rote Folie, gibt's bei Conrad oder auch bei dimmer.de (oder ähnlichen Versendern für Beleuchtungsbedarf).

Red screens and dark skies,
Tom

 

[circushund]

den Code für den Nachtmodus hat mir Han Kleijn (HNSky) zur Verfügung gestellt. Dort werden die Systemfarben während des Nachtmodus verändert, was auf alle Programme wirkt.

...das mag schon sein, doch ist und bleibt eben nur ein "fake". Wie geschrieben lässt sich eben ohne Folien oder sonstiges eben nicht reibungslos arbeiten, da selst gelbe Ordner ec. stören.

Trotzalledem finde ich die Mac Lösung da um einiges Eleganter und passender, irgdwas scheint es zu verhindern (oder es hat einfach noch niemand gescheit Programmert, den DarkAdapt funktioniert auch nicht auf PC?), das Statt die Systemfarben zu ändern, die Kanäle bzw. die Gamma des Monitors direkt anzusprächen.
Aber warscheinlich ist das ein riessiges unterfangen, da es tausenderlei Konfigurationsmöglichkeiten von Graka und Hardware gibt und es die Sache nicht grad leichter macht *fuckdoiknow . Denn ich denke schon das es möglich ist, irgendwie Softwaremässig die Gammawerte einzustellen, es hat bloss noch nichmand gemacht. Ich hab ja beim Mac "bloss die Idee bekommen", das es funktionieren kann, das man einen "echten" statt "gefakten" Nachtmodus auch hinbekommen kann, wo man mit dem Computer homogen arbeiten kann ohne sich sein Gerät mit allerlei Folien und Kleber zu verschandeln, denn sowas kann man sich bei einem Mac nicht leisten, es sei denn er ist ein sehr sehr alter (evtl. ein dreckiger G3)
Mit dem Nachtmodus am Mac trau ich mich schon raus und kann zusätzlich die Helligkeit runter dimmen, mit dem PC wo da evtl. dein ET läuft trau ich mich nicht raus, hab es schon versucht, das ist schier unmöglich.
Ich denk nur, es ist ja nicht immer notwendig um um den Stuhl auf den Gang rumzugehen, man kann ihn ja auch mal beiseite stellen.
Das man da eine Folie draufkleben kann und das ihr erfahrenen DeepSky user das so macht, ja ja ja, das hab ich nun auch tausendfach gelesen, doch das rechtfertigt doch noch nicht, sich über einen "vernünftigen" Rotmodus sich Gedanken zu machen ?
Nevertheless, ich reg mich grad auf, vll. sollt ich den ganzen S****** auch vergessen.

 

[Thomas_Pfleger]

Nachtmodi, die keine sind

Nein Don, vergessen sollst Du's nicht. Du hast schon recht, der Fake ist nicht elegant, aber die Ansteuerung der Hardware ist beim PC wahrscheinlich im Detail (ich kenne mich da nicht aus) so unterschiedlich, dass eine Softwarelösung mit GK-Beeinflussung mal funktionieren wird und mal nicht.

Ich habe selbst ein Beispiel: der Nachtmodus von Starry Night funktioniert auf dem Notebook (mit OpenGL-GK) nicht, auf dem Desktop (mit primitiver GK, ohne OpenGL) funktioniert es aber. Allerdings würde ich so ein dezentes Schweinchenrosa nicht als ernstzunehmenden Nachtmodus bezeichnen, aber das passt zu Starry Night, mit dem man als Beobachter nicht viel anfangen kann. So gesehen schadet der minderwertige Nachtmodus von SN nicht, denn es ist für den Feldeinsatz eh nicht zu gebrauchen. Was soll's, dafür hab' ich's eh nicht gekauft.

Da bei Apple die Hardware aus einem Guß ist und man besser auf die Einhaltung von Spezifikationen achtet, ist das wohl ein guter Grund dafür, dass sowas wie Dark Adapt dort funktioniert.

BTW: meine Dunkeladaption zerstört haben bisher der Jäger der mit Fernlicht schaut, wer auf dem Feld steht, der Bauer der im Sommer mitten in der Nacht auf sein Feld rausfährt um das gemähte Gras aufzunehmen, die Innenbeleuchtung der Autos von Mitbeobachtern oder deren irrtümlich weiß statt rot eingeschaltete Lampen. Rückfahrlicht (weil jemand nicht dran gedacht hat, sich richtigrum hinzustellen) ist auch eine üble Falle. Sehr störend auch die Displays von Digitalkameras und Camcordern. Mein Rechner hat mir jedenfalls noch nie die Adaption verblitzt, die Plastikscheibe für 10 Euro reicht dafür völlig aus.

Gruß,
Tom

 

[Lorchi]

Re: Nachtmodi, die keine sind

Vielen Dank für Eure ausführlichen Meinungen.

Ich denke, jetzt muss sich die Idee ersteinmal setzen, und weitere Recherche folgen. Dann könnte man verschiedene Ansätze miteinander vergleichen.

Zum Nachtmodus folgendes: ohne Folie bleibt alles ein Fake, auch eine Gammakorrektur, sowohl von der Graka als auch dem Monitor. Denn auch ein tiefes Schwarz leuchtet noch, d.h. die Hintergrundbeleuchtung scheint durch. Und das macht sich bei mir immer noch stärker bemerkbar, als ein paar farbige/weiße Sternchen von CDC. Daher denke ich, ist die einzige wirklich gute Lösung eine Kombination von einem guten Schwarz/Weiß- oder Schwarz/Rot-Modus in Verbindung mit einer Folie bzw. roter Hintergrundbeleuchtung. Der Software-Modus sollte in Verbindung mit der Folie benutzt werden, damit keine Darstellungen in anderen Farben auftreten (z.B. blau), welche dann durch die Folie zu schwarz werden und nicht mehr sichtbar sind.

Ansonsten:
Ich habe gestern ein existierendes System gezeigt bekommen, die Software vom VLT. Das ist sehr modular, basiert auf Tcl/Tk und C++, und besteht aus verschiedenen Prozessen, die eigene Sachen kontrollieren, wie z.B. Scheduler, Treiberinterface, (Real-Time-)Display, Datenbank zur Kommunikation und Einstellungen, usw. Dazu gibt es noch einen eigenen GUI-Builder, der zwar nicht alle Tk-Features unterstützt, aber zumindest die wichtigsten, und dazu gleich die Kommunikations- und Datenbank-Anbindung vornimmt. Leider läuft es nur unter Linux/Unix/HPUX, und ist somit nicht portabel.

Im Prinzip gibt es eine Grundschiene, über die Messaging, Event Handling, Logging, Database, Error System, Time Handling, Alarm Management, Access Control, Command Handling laufen, und die ein allgemeines Interface hat. Früher war das RTAP von HP, und ist mittlerweile durch ein selbstgestricktes System ersetzt worden (mit Namen CCS). Die Datenbank ist die gemeinsame interne Wissensbasis für die (teilweise) miteinander kommunizierenden Software-Module, und stellt die Infos bereit z.B. welche Kameras da sind, wer wodrauf zugreift (memory), und dort legen auch die Module ihre eigenen Einstellungen ab (disk). Aber soweit ich das verstanden habe, immer über das generelle Interface von CCS, kein Direktzugriff auf die Datenbank(?). Hier wurde die Modularisierung auf die Spitze getrieben. Durch die entsprechende Klassenimplementierung der aufsetzenden Module ist sogar alles als Skript-Kommando verfügbar.

(Alle Module sind einzelne Tasks, z.B. ein Kameratreiber. Nach diesem Modell wäre es auch leicht möglich, später "data transfer tasks" einzuhängen, die z.B. Kameras, die an anderen Rechnern angeschlossen sind, zu benutzen, oder die GUI irgendwo im Keller zu haben. Aber ich schweife wieder ab.)

Ich finde, das klingt nach einiger Erfahrung mit genau diesem Thema. Gibt es vielleicht mittlerweile etwas ähnliches als open-source (abgesehen von Betriebssystemen)? Das CCS ist leider nicht öffentlich. Das Prinzip neu zu integrieren wäre nicht gerade unaufwändig...

Das bezieht sich natürlich alles auf ein eigenständiges System, und keinen Wrapper um existierende Gui-Anwendungen. Davon habe ich vorher auch noch nicht gehört, die Vor- und Nachteile hast du ja aufgezeigt, aber ich sehe nur einen begrenzten Sinn darin...

Soweit so gut...

Grüße

 

[Thomas_Pfleger]

Re: Nachtmodi, die keine sind

Was Du da berichtest, klingt sehr nach der Idee des Softwarebus. Das ist eine Infrastruktur, über die man Produzenten und Konsumenten von Ereignissen oder Daten zusammenklinken kann. Ein Modul bietet seine Dienste über Schnittstellen an, das ist die logische Sicht. Der Softwarebus bietet (in großen Architekturen aus Modellen generierte) Adapter an, die die Benutzung der Schnittstellen über verschiedene Techniken ermöglichen, z.B. in Form von Webservices oder Message Queues.

Die Idee des Skripting greift das Command Pattern auf, wie es Gamma & Co. im allgemein bekannten Entwurfsmusterbuch beschreiben.

Für mich waren Deine Beschreibungen interessant, weil sie zeigen, dass die architektonischen Ideen in der Infrastruktur der ESO zumindest grundsätzlich mit dem übereinstimmen, was man aus der Softwareentwicklung in der Wirtschaft so kennt.

Das alles kann aber nicht über die Frage hinweggehen, was denn überhaupt das Ziel einer Eigenentwicklung wäre. Wenn Du ähnlich hoch greifst wie Du es gesehen hast, dann ist erst mal viel Aufwand für die Infrastruktur nötig, bevor man zu "Inhalten" kommt. Es dauert lange, bis man mal was sieht aber dann geht es auf einmal erfreulich schnell.

Für einen Endanwender ist zu bedenken, dass solche verteilten Systeme von der Konfiguration her oft mörderkompliziert sind, denn viele Fehler merkt nicht der Compiler sondern es kracht erst zur Laufzeit. Wenn man dann alles noch passend einstellen muss (was i.d.R. sehr detaillierte technische Kenntnisse erfordert), wird es für den Normalo schnell zuviel des Guten. "Keep it simple" und eine offene Architektur auf Basis verteilter Systeme und Prozesse ist ein Widerspruch! Nicht umsonst hat man für den ganzen Ärger mit dem Konfigurationswahnsinn den Begriff "Metadata hell", was die alte, aber deswegen auch nicht gute "DLL hell" ablöst...

Gruß,
Tom

 

[Varyonyx]

Re: Nachtmodi, die keine sind

Hallo zusammen,

möglicherweise hilft auch ein Click hierhin
http://software.audela.free.fr/english.htm

Gruß Alex (VSU-RTF)

 

[circushund]

Re: Nachtmodi, die keine sind

@Varyonyx
Die Oberfläche (Interface) GUI sieht ja zum (östr.) speien, (deut.)kotzen aus.
das gibt es ja nicht ?? Mag sein das es viele Funktioen hat und viel Teleskope steuern kann, aber WILL MAN DAS BENUTZEN?? Ich weiss nicht ?
Wieder mal haben Techniker/Programmierer die GUI bestimmt...leider!

Ps:
Dein Vorschlag der URL in Ehren -danke für den Hinweis...

 

[Varyonyx]

Re: Nachtmodi, die keine sind

Hallo Circushund,

ich bin sicher daß sich die Audelagroup über kompetente Entwickler bzw. GUI-Designer freut... <img src="/phpapps/ubbthreads/images/graemlins/Spitze.gif" alt="" />

Als Ansprechpartner würde ich diesbezüglich Alain Klotz empfehlen oder der entsprechende Yahoo-Group beitreten.
Immerhin ist dieses Projekt weit über das blosse Planungsstadium hinaus und von mir hier als Beispiel für eine Zusammenarbeit angeführt worden.

Natürlich läßt sich auch an Audela einiges verbessern, trotzdem ist es nicht angebracht sich über die Leistungen anderer in "Speiform" auszulassen. <img src="/phpapps/ubbthreads/images/graemlins/neinnein.gif" alt="" />

Mfg Alex (VSU-RTF)

 

[Lorchi]

Re: Nachtmodi, die keine sind

Hallo,

diese Audela-Geschichte ist sehr interessant. GUI hin oder her, die hatten anscheinend dieselbe Idee eines Gesamtsystems schon früher. Hier fallen gleich deutliche Schwächen auf (die meine Idee genauso betreffen):
- Die gesamte Dokumentation ist auf französisch. Das ist leider mehr als kurzsichtig gewesen, gleich den größten Teil der Weltbevölkerung auszuschließen. Für mich ist der Entwicklungsstandard englisch.
- Es ist ein offenes System, das sich aber doch abgrenzt, indem es eigene Treiber erstellt. Das ist nur sinnvoll, wenn es gelänge, zum Standardsystem zu werden das jeder benutzt. Trotzdem ist es natürlich besser als alles andere, da es zum ersten Mal diverse Kameras vereint und gemeinsam bereitstellt. Aber es sind mal wieder viele Schritte auf einmal.
(die GUI ist wirklich nicht schön, aber zum Bedienen eines Teleskops und der Kameras bin ich als User bereit mich einzuarbeiten, Hauptsache es würde alles mal gut zusammen funktionieren)

Habt Ihr Lust, noch ein wenig zu philosophieren?
Gestern hatte ich plötzlich ein Bedienerprogramm vor Augen, wie es funktionieren könnte. Aber das ist schon zu weit gegriffen.

Was wäre damit (die Idee noch weiter heruntergeschraubt, und bei der Basis angefangen):
Was ich oben erwähnte (den Softwarebus), gibt es in diversen Formen schon. Die Priorität muß darin liegen, vorhandene Standards zu nutzen ("reuse" in jeder möglichen Hinsicht). So könnte man erstmal einen Standard definieren, wie astronomische Geräte mit einem Softwarebus zu verbinden seien.

Beispiel:
- Real-time CORBA als Kommunikationsstandard für Hardware
- Schnittstelle von CORBA nach ASCOM
- Generisches Kamera-Interface für CORBA (mit dem Schnittstellen/Treiber zu den bekannten CCDs, DSLRs und Webcams geschaffen werden können)
- Eine Applikation würde CORBA benutzen, und sähe die CORBA-Schnittstellen für Teleskop (und andere Mechanik) sowie eine Liste von Kameras (die alle das gleiche CORBA-Interface hätten, aber verschiedene Attribute und Namen)

Vor- und Nachteile, die mir dazu einfallen:
+ Ein Standard für alle Kameras (ja das ist möglich)
+ Ein gemeinsamer Softwarebus/Middleware für alle gesteuerten Elemente (Mechanik, Sensoren, Cams, ...)
+ Freiheit für Entwickler, Systeme über verschiedene Rechner zu verteilen
- Schwierigkeit, einen Standard zu schaffen
+ Programme würden (bei Erfolg) "von selbst" kommen
+ Offenheit für weitere Interfaces (wie GPS, Wettersensoren, andere Stellmotoren und weiß der Geier <img src="/phpapps/ubbthreads/images/graemlins/grin.gif" alt="" />)
+ Portabilität dank vorhandener (Open-Source) CORBA-Implementationen

Was denkt Ihr dazu?
Gruß, Henning

 

[Thomas_Pfleger]

Erfahrungen mit CORBA

Portabilität dank vorhandener (Open-Source) CORBA-Implementationen

Dazu eine Anmerkung aus einem Projekt, das CORBA einsetzte: die IDL ist zwar standardisiert und portabel, aber die vom IDL-Compilter generierten Stubs und Skeletons benutzen i.d.R. grundverschiedene Hilfsklassen. Weil man diese benutzen wird, hat man eine Abhängigkeit der Anwendung von der CORBA-Implementierung. Muss nicht schlimm sein, kann aber ein Ausschlusskriterium sein.

Auch hinsichtlich der Services bzw. deren Komfort und Leistungsfähigkeit unterscheiden sich CORBA-Implementierungen.

Bei solchen architektonischen Überlegungen sollte man auch an den Endnutzer denken, der eines Tages die Software installieren und in Betrieb nehmen möchte. Wieviel Konfigurationswissen für einen ORB ist erforderlich? Wie werden die Objekte beim Naming Service registriert? Kann und will das ein "Otto Normalastro"? Bei der Auswahl einer CORBA Implementierung würde ich wissen wollen, ob es da irgendetwas "out of the box" das man relativ straight in die Installation einhängen kann. Nicht alle Astros sind Computerexperten (wenn auch viele) sondern wollen einfach mit dem Zeugs loslegen.

Gruß,
Tom

 

[Lorchi]

Re: Erfahrungen mit CORBA

Hi Tom,

Muss nicht schlimm sein, kann aber ein Ausschlusskriterium sein.

Hmmm das stimmt. Muß aber wie gesagt nicht. Eine Alternativen-Recherche wäre auf jeden Fall zu erledigen.

Bei solchen architektonischen Überlegungen sollte man auch an den Endnutzer denken

Darin sehe ich kein Problem, nur eine zu erledigende Aufgabe: einen Installer mitgeben. Wie der dann aussieht, kann man natürlich jetzt noch nicht sagen. Für die Standard-Variante, alles wie eine Anwendung auf einem Rechner zu haben, wäre das zumindest die Lösung. Bzw., solange wir nur von einem Interface reden und nicht von einer Endanwendung, wäre ein einfaches Konfigurationstool denkbar, das a) automatisch installierte Kameratreiber sucht (Canon, Webcam etc), und wo man b) andere Sachen einstellen kann (Ports für Parallel-Kameras, Webcam a la Steve Chamber etc.). Klar, out-of-the-box wäre schön, ansonten kompiliert man es halt mit rein... oder so... das könnte man dann klären, wenn man sich strategisch für eine Lösung entschieden hat.

Gruß, Henning

 

[Lorchi]

Re: Erfahrungen mit CORBA

...das CORBA einsetzte

Vergangenheit?

 

[Thomas_Pfleger]

Re: Erfahrungen mit CORBA

Ja, Vergangenheit. Den Kunden (Brokat AG) gibt's nicht mehr.