Spielstandsanzeige (Dual-Monitor-Setup)?

[Korodny]

Ich suche eine Software, mit der ich für eine Ballsportart (Radball) eine einfache Spielstands- bzw. Zeitanzeige realisieren kann: Laptop mit zweitem Monitor: auf dem internen Display bedient der "Operator" die Anzeige (Spielzeit Start/Stop, Tore zählen, usw.), auf dem zweiten, zum Publikum zeigenden Monitor wird grafisch Übersichtlich die aktuelle Begegnung, der aktuelle Spielstand und die verbleibende Spielzeit angezeigt.

Kennt jemand so etwas für Linux? Für Windows finde ich ein paar Nischenlösungen (Beispiel), für Linux habe ich bisher noch nichts auftreiben können.

[hikaru]

Für Windows finde ich ein paar Nischenlösungen (Beispiel), für Linux habe ich bisher noch nichts auftreiben können.

Ich kann leider nicht weiterhelfen, aber angesichts dessen, dass du dich hier in einer Nische (Linux) einer Nische (Spielstandsanzeige) bewegst, schlage ich vor, deine Herangehensweise zu ändern:
Suche nicht nach einem fertigen Programm, sondern nach jemandem, der dir sowas programmieren kann!

Ich sehe hier im Wesentlichen drei Punkte:
1. Technische Herausforderung: Du brauchst ein Programm, das zwei Fenster auf zwei Monitoren anzeigen kann. Das ist sicher nicht alltäglich, aber wohl technisch gut lösbar. Qt scheint dafür z.B. mehr oder weniger gut vorbereitet zu sein. [1] Ich würde vermuten, dass es für Gtk ähnlich standardisierte Lösungen gibt.
2. Klare Formulierung der Anforderungen: Ich habe mir die Website deiner Beispielsoftware kurz angeschaut, und dabei festgestellt, dass sich der Autor offenbar viele Gedanken darüber gemacht hat, was im Rahmen eines solchen Programms sinnvoll ist. Vieles von dem was er implementiert hat, steht nicht in deinem Beitrag und ich wäre darauf auch von allein nicht gekommen. Ich halte das hier für ein Paradebeispiel für die klare Formulierung eines Pflichtenheftes.
3. Abgesehen von 1. und 2. sollte der programmiererische Aufwand eher überschaubar, und im Wesentlichen Fleißarbeit sein.

Aus diesen drei Punkten schlussfolgere ich, dass so ein Spielstandsanzeigeprogramm eine geeignete Projektarbeit für einen Oberstufenschüler oder einen Studenten im Grundstudium sein könnte, vorausgesetzt er hat grundlegende Erfahrung im Programmieren von GUI-Applikationen unter Linux.
Falls du so jemanden kennst, idealerweise natürlich aus dem sportlichen Umfeld wo du die Spielstandsanzeige einsetzen willst, dann sprich den einfach mal darauf an!


[1] https://doc.qt.io/archives/qtextended4. ... splay.html

[MSfree]

1. Technische Herausforderung: Du brauchst ein Programm, das zwei Fenster auf zwei Monitoren anzeigen kann.

Wozu überhaupt ein 2-Monitorsetup?

Ich würde auf der Seite, wo die Spielstandsdaten eingegeben werden, eine HTML-Datei erzeugen. Auf der Seite, die den Spielstand (auf dem separaten) Monitor anzeigen soll, würde ich einen Browser im Fullscreen laufen lassen, der die erzeugte HTML-Seite darstellt. Mit etwas Javascript läuft der Fullscreenbrowser dann auch mit Autorefresh, so daß jede Spielstandänderung innerhalb kurzer Zeit angezeigt wird.

Was man dann also an Hardware benötigt, wären z.B. zwei Laptops jeweils mit einem Bildschirm. Einer dient zum Erzeugen der HTML-Seite, wozu man ein wenig Software programmieren müßte, und einem laufenden Webserver (Apache, nginx, MiniHTTPd...). Der andere kann irgendein System fahren, egal ob Android, OSX, Windows oder Linux, denn da muß nur ein Browser laufen. Im Prinzip täte es hier sogar ein Smart-TV mit einem Webbrowser. Vernetzen tut man das ganze per WLAN Ad-Hoc, mit Kabel oder per WLAN mit Accesspoint.

[Lord_Carlos]

Qt scheint dafür z.B. mehr oder weniger gut vorbereitet zu sein. [

Oder einfach ne webloesung benutzten.
Dann ist das in ein paar stunden Fertig und man kann alles moegliche als Klient benutzten. Ob rPi, moderner TV oder Handy .. oder ein Browser auf dem zweiten Monitor.

Edit: Was MSfree sagt. Obwohl ich das etwas interaktiver machen wuerde. Mit socket.io oder sowas.

[DeletedUserReAsG]

Den Ansatz finde ich gut. Im Grunde braucht man auch nur einen Laptop – die haben ja meist ’nen Bildschirm eingebaut, mit der Operator dann arbeiten kann. Auf dem externen, zum Publikum hingedrehten, Monitor lässt man dann den Browser im Fullscreen laufen, und fertig. Oder wenn’s getrennte Plätze sein sollen: was Schmales, etwa ’n Pi mit WLAN-Stick, am Monitor, und der Operator kann dann bequem mit seinem Schleppi irgendwo sitzen und die Daten eingeben.

[hikaru]

Wozu überhaupt ein 2-Monitorsetup?

Korodny sprach von Radball. Das wird meines Wissens nach auf einem Fußballhalbfeld gespielt. Ich hatte selbst aber auch sowas wie z.B. Handball oder Volleyball im Kopf - alles Szenarien wo mMn der Operator nahe am öffentlichen Display ist, entweder weil eh wenig Platz ist oder weil man möglicherweise vorhandene große Infrastruktur (Sprecherkabine eines Fußballstadions) nicht nutzen wird.
Da sitzt also in meiner Vorstellung jemand auf Höhe der Mittellinie neben dem Feld. Ein Dual-Monitor-Setup bietet sich da an.

Unabhängig davon finde ich deine Web-Idee aber auch spannend. Die würde auf größere Maßstäbe skalieren, wäre vermutlich am einfachsten umzusetzen weil das jeder Webentwickler können sollte und kann in dem kleinen Maßstab den ich vor Augen hatte ebenfalls eingesetzt werden, indem man Server und Client einfach auf dem selben Rechner betreibt.

[schorsch_76]

Du könntest auch mal wine probieren mit deiner Software. Wenn das nur Netzwerk Sockets nutzt ist die Wahrscheinlichkeit groß dass es einfach geht.

[Korodny]

Vielen Dank erst mal für die Antworten. Zu einigen der angesprochenen Punkte:

Eine HTML-Lösung scheidet aus, da auch die Uhrzeit sekundengenau angezeigt werden muss, und die Uhr bei Verletzungen, Materialschäden Zeitspiel o.ä. angehalten oder ggfs. korrigiert wird. Und ja, das "Kampfgericht" sitzt auf einer Seite des Spielfeldes auf Höhe der Mittellinie, das Publikum gegenüber - deswegen zwei-Monitor-Setup.

Wine o.ä. dürfte auch ausscheiden, da die Lösungen i.d.R. mit Access entwickelt werden, oder .NET- und SQL-Laufzeitumgebungen brauchen.

Die verlinkte Lösung war insofern ein schlechtes Beispiel, dass sie für unseren Bedarf komplett überdimensioniert ist. Ich habe mehrere solcher Windows-Lösungen durch, die alle ein Client-Server-Modell wie hier vorgeschlagen implementieren und zwei-Monitor-Betrieb nur nebenher unterstützen - die haben alle das gleiche Problem: Auf irgendeinem Privatlaptop, den ein Durchschnitts-Windows-User mitbringt, kommen die früher oder später ins Stocken - weil irgendein Hintergrundprozess (SchlagmichtotSchlangenöl 5.0 startet einen Virencheck o.ä.) ihnen zu viele Ressourcen klaut.

Eine Lösung, die Webserver und Javascript einsetzt gibt es bereits, die hatte ich vergessen zu erwähnen: PointsTable. Ist allerdings noch nicht 100% ausgereift und der Autor hat das Interesse verloren (kein Eigenbedarf mehr), benötigt ein WLAN-Setup mit einem RasPi (o.ä.) pro Monitor, ist extrem umständlich (für mich) aufzusetzen und braucht dutzende Javascript-Bibliotheken, von denen viele schon wieder veraltet sind. Außerdem hat es noch Fehler, Server und Client sind irgendwann nicht mehr in sync - das zu Debuggen ist mir ein paar Nummern zu groß.

Mir wäre deswegen eine möglichst einfache Lösung recht gewesen: Ein einfaches Programm dass zwei Fenster öffnet, eines davon Anzeige, eines Bedienung. So ähnlich wie OpenScoreBoard, nur wenn möglichst nicht in FreePascal und weniger schlecht Scheint als gäbe es da auch für andere Sportarten nix passendes was man anpassen könnte? Schade.

[DeletedUserReAsG]

Eine HTML-Lösung scheidet aus, da auch die Uhrzeit sekundengenau angezeigt werden muss, und die Uhr bei Verletzungen, Materialschäden Zeitspiel o.ä. angehalten oder ggfs. korrigiert wird.

Hat ja auch keiner von reinem HTML gesprochen. Mit JavaScript kannst du dir auch ohne externe Libs (oder wie das da heißt) ’ne Zeitanzeige bauen, die 1/100s anzeigt (auch, wenn’s spätestens dann nicht mehr sinnvoll ist, wenn die Zeit per Hand gestoppt wird). Und da der Operator auf der gleichen Maschine agiert, beziehungsweise zumindest im gleichen Netz sitzt, kommt da auch nur ’ne Verzögerung von unter ’ner 1/1000s von der Seite drauf, dazu vielleicht noch so 50ms für die Verarbeitung und Anzeige. Insofern würde ich das nicht kategorisch ausschließen – zumal’s die beste Option ist, wenn’s von Grund auf gebaut werden muss, etwa weil sich nix anderes findet. Die Entwicklungszeit wäre verhältnismäßig kurz.

Deine Aufgabe wär’s, mal ganz genau aufzuschreiben, was das Dingens können muss. Am besten noch mit Skizzen, wie der Anzeigebildschirm gestaltet werden sollte, was er wie anzeigen soll und so. Mit der Info lässt sich abschätzen, welcher Aufwand nötig wäre, und vielleicht findet sich ja sogar jemand, der’s als Wochenendprojekt nimmt.

[Korodny]

Deine Aufgabe wär’s, mal ganz genau aufzuschreiben, was das Dingens können muss. Am besten noch mit Skizzen, wie der Anzeigebildschirm gestaltet werden sollte, was er wie anzeigen soll und so. Mit der Info lässt sich abschätzen, welcher Aufwand nötig wäre, und vielleicht findet sich ja sogar jemand, der’s als Wochenendprojekt nimmt.

Erm, wenn du meinst hier lungern unterbeschäftigte Programmierer herum - gerne

Ich hatte mir selbst ein Konzept für einen FreeBasic-Prototypen überlegt, das scheitert aber derzeit an der nötigen Einarbeitszeit. Irgendwelche Fonts auf hochauflösenden (größer 320x240) Displays anzuzeigen, braucht bei FreeBasic schon ziemliche Verrenkungen oder externe Bibliotheken. Ich poste mal hier, was ich habe:

Zielhardware sind alte Laptops auf denen Debian XFCE läuft. Ein externer Monitor ist (voraussichtlich per VGA) angeschlossen.

Beim Programmstart gehen zwei Fenster auf: DISPLAY enthält die Anzeige für die Zuschauer und geht entweder direkt auf dem externen Monitor im Vollbild auf oder kann von mir dorthin geschoben und auf Vollbild geschaltet werden. Das zweite Fenster OPERATOR öffnet sich auf dem internen Monitor und enthält ebenfalls eine (schmucklose) Spielstands- (etc.-) Anzeige sowie Bedienelemente zur Steuerung der Anzeige.

Eine graphische Benutzeroberfläche ist nicht zwingend Voraussetzung, bedient würde sowieso eher per Tastatur. Neben Hotkeys müsste dann lediglich die Eingabe von Mannschaftsnamen irgendwie gehandhabt werden.

Nach dem Start erst mal der "Setup" Screen: die Namen der (bis zu) 10 Teams eingeben, die heute antreten, Dauer einer Halbzeit festlegen (5,6, oder 7 Minuten), eventuelle Einstellungen zum DISPLAY-Fenster, falls nötig. Setup sollte später erneut aufgerufen werden können (Tippfehler korrigieren o.ä.).

Der folgende Mockup zeigt, was DISPLAY enthalten muss: Spielstand (kann zweistellig werden), Team-Namen, Zeit, welche Halbzeit wird gerade gespielt. Wenn das ohne Neukompileren konfigurierbar wäre (Farbe, Position, Größe der Elemente aus einer Textdatei lesen) wäre das edel.



OPERATOR enthält eine kleinere/vereinfachte Version der Inhalte von DISPLAY, außerdem Einstellmöglichkeiten. Mein FreeBasic-Konzept hätte nur Tastatur-Shortcuts genutzt, dabei sind folgende Shortcuts herausgekommen (Shortcuts mit Beschreibung in eckigen Klammern sind nur in bestimmten Situation aktiv):

Code: Alles auswählen

Zeit                                                    Tore

<SPACE>         Uhr starten/anhalten                    (<Shift>)<TAB>      Tore linkes Team erhöhen (verringern)
<STRG><Z>       Zeit zurücksetzen                       (<Shift>)<ENTER>    Tore rechtes Team erhöhen (verringern)
(<Shift>)<S>    [Sekunden addieren (abziehen)]          <STRG><T>           Tore zurücksetzen

Halbzeit                                                Teams

<BACKSPACE>     Seitenwechsel                           <L>                 Name linkes Team auswählen
<H>             [Halbzeit-Uhr starten/abschalten]       <R>                 Name rechtes Team auswählen
<W>             1./2.Halbzeit                           <1>...<0>           [Team wählen]
<?>             Setup                                   <ESCAPE>            [Teamliste schliessen]

(da meine FreeBasic-Anwendung nicht aus zwei Threads (einer fürs Display, einer für Benutzereingaben) sondern nur aus einer großen Schleife bestehen sollte, ist die Wahl der Mannschaftsnamen etwas komplizierter: "L" oder "R" poppt links/rechts eine Liste mit Namen auf, aus der dann mit 1-0 einer gewählt wird. Alle anderen Eingebemöglichkeiten bleiben dabei aktiv, und das Display wird auch weiter aktualisiert - könnte man natürlich auch eleganter lösen).

"Halbzeit-Uhr" zählt zwei Minuten herunter, danach muss weitergespielt werden. Jeder Timer, der auf Null heruntergelaufen ist, spielt einen Signalton ab.

[Tintom]

Bei den genannten Anforderungen würde ich das Projekt als dynamische Webseite im Webbrowser umsetzen. Das hätte auch den Vorteil, das Bediener, die mit der Konsole unerfahren sind, sicher mit dem Tool umgehen können.
Auf github gibt es bereis ein Projekt für eine Anzeigetafel (engl. Scoreboard) mit Countdown, die mittels JavaScript im Browser läuft. Vielleicht kannst du das als Grundlage für dein Projekt verwenden.

[Korodny]

Bei den genannten Anforderungen würde ich das Projekt als dynamische Webseite im Webbrowser umsetzen.

Das hätte ich vielleicht deutlicher sagen sollen: Der Operator sieht das Spielfeld von der anderen Seite als die Zuschauer - das aus seiner Sicht linke Team ist aus Sicht der Zuschauer das rechte Team. Einfach nur ein und das selbe Display auf verschiedenen Monitoren anzuzeigen (1x für die Zuschauer, 1x für den Operator) hätte deswegen den Nachteil dass der Operator bei jeder Eingabe (Teams für nächstes Match, ein Tor ist gefallen...) etwas Gehirnakrobatik vollführen müsste: "linkes Team hat ein Tor geschossen, ich muss also rechts klicken".

Auf github gibt es bereis ein Projekt für eine Anzeigetafel (engl. Scoreboard) mit Countdown, die mittels JavaScript im Browser läuft.

Ich seh mir das mal an, Danke.

[Wiko]

Wie wärs denn mit der folgenden, ganz ganz einfachen Lösung?:

- ein Laptop mit einem externen Bildschirm (für die Zuschauer)
- dann den Bildschirm wie folgt teilen:
- in der oberen Hälfte einmal Libreoffice Calc aufmachen und den Spielstand in 200pt Schriftgröße einfach eintippen, z.B. "2 : 3"
- in der unteren Hälfte einen Browser mit einer Countdown Webanwendung laufen lassen, z.B. diese hier: https://www.timeanddate.de/stoppuhr/eieruhr

Den Spielstand kann man ganz einfach live updaten; und den Countdown Timer kann man im Webinterface ebenfalls einfach pausieren und weiterlaufen lassen.

Besonders schön ist das natürlich nicht, aber mit null Aufwand sofort umsetzbar.