Am 19.06.2025 fand das 4. Muckturnier auf der Sportwoche des ASV Leupoldsgrün statt, wie die letzten Male auch gerne unterstützt durch das Muckturnier.org-Team.
Ein herzlicher Glückwunsch geht an die strahlenden Sieger Karin Troßmann und Matthias Hertrich, die sich knapp aber dann doch souverän den 1. Platz gesichert haben! In der kompletten Rangliste 2025 können alle Interessierten nachsehen, wer wo gelandet ist.
Ein besonderer Dank geht an die Sponsoren, das waren dieses Mal, neben dem ASV Leupoldsgrün selbst waren das (in alphabetischer Reihenfolge):
Kürzlich habe ich mich ja mit den Möglichkeiten beim Auslosen auseinandergesetzt. Und festgestellt: So einfach, wie man denken möchte, ist es nicht. Z. B. kümmert sich tatsächlich – anders als im Release Announcement für Muckturnier 3.10.0 behauptet – das Programm eben nicht sowieso darum, dass man ganze Runden für Paare auslosen kann, und so lang es geht spielt keines mehrfach gegen ein anderes.
Wie funktioniert es bisher?
Die Auslosung passiert pro Anmeldung. Für eine ganze Runde wurden bis Version 3.8.0 einfach alle Plätze zufällig vergeben. Seither gibt es die Möglichkeit, die mehrfache Zulosung von Partnern (für Einzelspieler) und/oder Gegnern zu vermeiden.
Wie läuft das momentan ab? Beim Anklicken einer Anmeldung wird geschaut, welche Plätze verfügbar sind. Alle die, die „kollisionsfrei“ sind (also entsprechend der Einstellungen keinen bisherigen Partner und/oder Gegner enthalten) werden bevorzugt. Gibt es solche Plätze, dann wird einer von diesen gelost. Ansonsten ein komplett zufälliger. Seit Version 3.10.0 wird im Fall von Einzelspielern zweistufig ausgewählt: Wenn bisherige Parter und Gegner vermieden werden sollen, es aber keine solchen Plätze mehr gibt, dann wird zumindest nach Plätzen gesucht, bei denen bisherige Partner vermieden werden. Und erst dann wird zufällig ausgelost.
Bei der Auslosung einer ganzen Runde wird nichts anderes gemacht: Es wird eine zufällig sortierte Liste aller Anmeldungen generiert, und die dann von oben nach unten abgearbeitet – so, als ob man jede Anmeldung in einer zufälligen Reihenfolge anklicken würde.
Aber sorgt das tatsächlich für Kollisionsfreiheit? Nein. Einfaches Beispiel: Paar A kann nur noch gegen Paar B spielen, alle anderen Paarungen waren schon. beide stehen aber am Anfang der Liste, und werden an verschiedene Tische gelost (es gibt keine Kollision – die Tische sind ja noch leer). Und schon ist es vorbei – obwohl es noch eine Möglichkeit gegeben hätte.
Besserer Ansatz zum Auslosen ganzer Runden
Man muss die komplette Runde betrachten, nicht nur einzelne Plätze. Wer muss mit wem und gegen wen spielen, damit es keine Kollisionen gibt? Die einfachste Lösung hierfür ist der sog. „Brute Force“-Ansatz, das Ausprobieren aller Möglichkeiten. Das ist relativ einfach zu implementieren, mit einer Backtracking-Funktion, die sich rekursiv selbst aufruft, bis eine Lösung gefunden ist.
Funktionen, die sich selber immer wieder aufrufen, sind immer ein bisschen gefährlich, weil es zu sehr vielen Iterationen kommen kann. Also probieren wir es doch mal aus, und zählen die Aufrufe. Die Funktion selbst war wie gesagt recht leicht zu schreiben. Also Testlauf, aber gleich ordentlich – mit 50 Paaren.
Runde 1: Eh komplett zufällig ausgelost (da kann es ja noch keine Kollisionen geben). Runde 2: 26 Aufrufe. 3: 26. 4, 5, 6 … immer 26. Dann mal 786. Okay … und dann auf einmal über 800 000. Okay, zwar hast da selbst mein recht leistungsfähiger Desktop-Rechner kurz gestockt, aber das wäre schon noch okay. Aber: Wie viele Aufrufe können theoretisch maximal bei n Anmeldungen vorkommen?
Die Formel dafür ist einfach: (n - 1)!!. Für diesen Fall heißt das: Wir berechnen immer die Doppelfalkultät einer ungeraden Zahl, da ja immer eine gerade Anzahl an Anmeldungen angemeldet sein muss (egal ob feste Paare oder Einzelspieler). Also multipliziert man alle ungeraden Zahlen bis n - 1 miteinander, für n = 6 wäre das z. B. 1 · 3 · 5.
Sieht doch übersichtlich aus, oder? Was wäre das für 10? 9!!, das sind 945. Geschenkt. Und für 20? 19!!, das sind 654 729 075. Oha, da kommen wir schon in den mittleren Millionenbereich. Und für 50?! Soll ja durchaus mal ein Turnier mit 50 Paaren geben? Tatsächlich sind 49!! sage und schreibe 58 435 841 445 947 272 053 455 474 390 625 – eine Zahl mit 32 Stellen. Den Namen musste ich mir erstmal überlegen – wenn ich mich nicht verzählt habe, dann sprechen wir hier von gut 58 Quintillionen Funktionsaufrufen im schlechtesten Fall bei 50 Anmeldungen. Das ist selbstverständlich so nicht mehr darstellbar.
Eine funktionierende Implementierung
Glücklicherweise haben sich schon lang vor mir viel schlauere Leute als ich mit solchen Problemen auseinandergesetzt. Das, was wir hier machen wollen, ist – mathematisch betrachtet – die Berechnung der maximalen Paarung in einem ungerichteten Graphen, wobei jedes Paar bzw. jeder Spieler einen Knoten darstellt, der mit jedem möglichen anderen Paar- bzw- Spieler-Knoten durch eine Kante verbunden ist.
Beispiel: Wir haben sechs Paare, „A“ bis „F“. In der ersten Runde hat A gegen B gespielt, C gegen D und E gegen F. Dann würde die Visualisierung eines Graphen, der alle noch möglichen Paarungen beinhaltet, folgendermaßen aussehen:
Nur wie berechnet man nun die maximale Paarung? Ohne dass im schlechtesten Fall eine irrwitzige Rechenleistung dafür nötig wäre? Die Lösung ist Edmonds’ Blossom Algorithm. Der tut exakt das: Die maximale Paarung in einem ungerichteten Graphen berechnen. Eine schöne Erklärung für das, was dabei passiert – incl. Visualisierung – gibt es bei der TU München. Ich persönlich finde das sehr beeindruckend, wie man auf sowas kommt – vor allem, wenn man bedenkt, dass der Algorithmus bereits 1965 veröffentlicht wurde!
Für das obige Beispiel wäre, wenn man die Paare in alphabetischer Reihenfolge abarbeitet, die durch den Algorithmus berechnete, maximale Paarung folgende (die gepaarten Kanten sind rot hervorgehoben):
In der nächsten Runde würden diese Kanten dann fehlen (die Paarung gab es ja dann bereits), und die berechnete maximale Paarung würde so aussehen:
Um für hinreichende Zufälligkeit zu sorgen, kann man die Knoten vorher zufällig sortieren, so dass der Algorithmus nicht immer beim selben Paar oder Spieler mit der Suche beginnt, und das Ergebnis nicht bereits allein aus der gegebenen Konstellation vorhersagbar ist.
Aber Sorgt das dafür, dass wirklich alle Möglichkeiten ausgenutzt werden können, die es rein rechnerisch gibt? Leider nein. der Algorithmus betrachtet nur die aktuelle Situation. Nicht das, was vorher war, und auch nicht das, was hinterher noch kommen könnte. Das kann bei ungünstigen Konstellationen dazu führen, dass man sich eine Möglichkeit „verbaut“ und es so schon zu Kollisionen kommen kann, bevor die theoretisch möglichen Runden erreicht werden. Würde man wirklich alle Möglichkeiten ausnutzen wollen, müsste man im Vorfeld das komplette Turnier in einem Round-Robin-Design planen. Das hat dann allerdings nichts mehr mit einer Auslosung zu tun.
Aber es geht ja auch gar nicht um das theoretisch maximal Machbare. So viele Runden wollen wir ja zumeist gar nicht spielen. Sicher ist: Dieser Ansatz bringt eine erhebliche Verbesserung für die Auslosung ganzer Runden, und erheblich weniger Kollisionen, als das, was wir bisher hatten. Alle Anmeldungen werden zunächst zufällig sortiert; somit ist die Zuordnung – im Rahmen dessen, was mit einer maximalen Paarung möglich ist – auch wirklich noch zufällig.
Wie funktioniert es also jetzt?
Die 1. Runde wird, egal ob man mit festen Paaren oder Einzelspielern spielt, immer komplett zufällig ausgelost. Hier kann es ja noch keine Kollisionen geben.
Bei festen Paaren ist die einzige Möglichkeit, Kollisionen zu vermeiden, dass ein Paar nicht mehrfach gegen ein anderes spielt. Die Paare werden zufällig sortiert, und dann wird eine maximale Paarung ermittelt. Bleiben Paare übrig, werden diese komplett zufällig einander zugelost.
Bei Einzelspielern kann man entweder gleiche Partner oder gleiche Gegner vermeiden – oder beides.
Zunächst werden die Spieler zu Paaren zugeordnet. Je nach Einstellung entweder komplett zufällig, oder analog wie oben bei festen Paaren beschrieben – nur, dass hier nicht auf die bisherigen Gegner, sondern auf die bisherigen Partner geschaut wird.
Im zweiten Schritt werden dann die ausgelosten Paare einander zugeordnet. Wie das passiert, hängt wieder von den Einstellungen ab: Entweder es werden die Paare komplett zufällig zugelost, oder es wird nach einer maximalen Paarung gesucht, wobei kein Spieler auf einen Gegner treffen soll, gegen den er schon einmal gespielt hat. Gibt es hier keine vollständige Lösung mehr (und das geht, abhängig von der Zahl der Spieler, recht schnell), wird jeweils eine Möglichkeit gesucht, bei der zumindest Spieler 1 bzw. Spieler 2 keine Gegner mehrfach sieht (ob ein Spieler 1 oder 2 wird, ist ja im 1. Schritt zufällig zugeordet worden). Das deckt zwar bei Weitem nicht alle möglichen Kombinationen ab – aber das Problem ist tatsächlich so komplex, dass man es nur schwer beherrschen kann. Die Vorgabe zumindest zur Hälfte zu erfüllen scheint mir da ein guter Kompromiss zu sein. Es wird immer die Variante mit den wenigsten Kollisionen gewählt.
Und ab wann gibt es das?
Die neue Funktionalität wird, ganz heimlich, still und leise, im nächsten Release verfügbar sein. Das wird vermutlich 3.11.0 heißen (t. b. a.). Für den Benutzer ändert sich augenscheinlich nichts, alles passiert „unter der Haube“. Außer, dass es jetzt eben bei der Auslosung ganzer Runden erheblich weniger Kollisionen geben sollte, wenn man die entsprechenden Optionen aktiviert hat.
Seit Version 3.8.0 gibt es die Möglichkeit, nicht nur einfach zufällig auszulosen, sondern die Auslosung mit Regeln zu versehen – sofern für jede Runde ausgelost wird. Namentlich kann man angeben, dass nach Möglichkeit die Zulosung von Gegnern vermieden wird, gegen die schon einmal gespielt wurde, und für Einzelspieler auch die von Partnern, die der Spieler schon einmal hatte.
Es stellt sich die Frage, wie viele Möglichkeiten es überhaupt gibt – also wie viele Runden gespielt werden können, bevor es zu einer „Kollision“ kommt. Jetzt sollte man aus dem Mucken keine Wissenschaft machen, aber hier braucht es ein bisschen Mathematik, namentlich Kombinatorik ;-)
Nennen wir die Anzahl der Anmeldungen (Paare oder Spieler) n und die maximale Anzahl Runden ohne Kollisionen r. Diese unterscheidet sich je nach Turniermodus und Einstellungen:
Feste Paare
Für feste Paare ist es relativ einfach. Eine Kollision bei Partnern kann es nicht geben, da ja eh immer dieselben Spieler zusammenspielen. Also muss man sich nur die Gegner anschauen – in diesem Fall die gegnerischen Paare.
Neben der Auslosungsvariante „Paar 1 bleibt sitzen, Paar 2 rutscht weiter“ ist eine zufällige Auslosung mit der Einschränkung, dass dieselben Gegner vermieden werden sollen, interessant.
Prinzipiell muss eine gerade Anzahl Paare angemeldet sein. Es gilt also:
Paar 1 bleibt sitzen, Paar 2 rutscht weiter
Hierfür brauchen wir keine höhere Mathematik. Es gibt halb so viele Tische wie Paare, da immer zwei Paare an einem Tisch sitzen. Alle Paare 2 rutschen jede Runde einen Tisch weiter. Also können halb so viele Runden gespielt werden, wie es Paare gibt, bevor das Paar 2 von Tisch 1 wieder an Tisch 1 sitzt und sich somit die Gegner wiederholen würden. Also gilt hier:
Beispiel für Für 6 Paare (a, b, c, d, e, f):
Runde
Tisch
Paare
1
1
a – b
2
c – d
2
e – f
2
1
a – f
2
c – b
3
e – d
3
1
a – d
2
c – f
3
e – b
In Runde 4 würde Paar b wieder zu Tisch 1 weiterrücken und erneut gegen Paar a spielen. Die maximale Rundenanzahl kann definitv erreicht werden, da sie von vornherein feststeht und nicht mehr durch eine Auslosung beeinflusst wird.
Gleiche Gegner vermeiden
Wird zufällig ausgelost, und es soll vermieden werden, dass dieselben Paare mehrfach gegeneinander spielen, dann muss die maximale Anzahl an möglichen Paarungen betrachtet werden. Diese sind:
Da in jeder Runde an halb so vielen Tischen gespielt wird, wie es Paare gibt, errechnet sich die maximale Anzahl der kollisonsfreien Runden dann zu:
Es kann also theoretisch kollisionsfrei eine Runde weniger gespielt werden, als Paare angemeldet sind. Allerdings kann es passieren, dass, bedingt durch eine ungünstige Konstellation, eine Paarung in einer früheren Runde eine spätere Paarung verhindert. Es kann also passieren, dass nicht alle Möglichkeiten tatsächlich auch ausgenutzt werden können.
Hier ein Beispiel für Für 4 Paare (a, b, c, d):
Runde
Tisch
Paare
1
1
a – b
2
c – d
2
1
a – c
2
b – d
3
1
a – d
2
b – c
Einzelspieler
Für einzelne Spieler wird es etwas komplizierter. Wie gesagt haben wir hier die Möglichkeit, sowohl Wiederholungen bei Partnern, bei Gegnern sowie die Kombination aus beidem zu vermeiden.
Grundsätzlich muss eine durch 4 teilbare Anzahl an Spielern angemeldet sein, somit gilt:
Keine gleichen Partner
Sollen nur gleiche Partner vermieden werden, die Gegner sind aber egal, dann haben wir dieselbe Situation wie bei den festen Paaren – nur dass wir eben nicht Paare betrachten, die gegeneinander, sondern Spieler, die miteinander spielen.
Die maximale Anzahl an kollisionsfreien Paaren für n Spieler ist:
Da in jeder Runde jeder Spieler mit genau einem anderen Spieler spielt, gibt es pro Runde halb so viele Paare, wie es Spieler gibt. Somit errechnet sich die theoretische maximale Anzahl kollisionsfreier Runden (analog zu der Situation bei den festen Paaren) zu:
Auch hier gilt, dass die maximale Rundenanzahl je nach Verlauf der Auslosung womöglich nicht erreicht werden kann. Beispiel innerhalb einer Runde: Wenn für Spieler a nur noch Spieler b als noch nicht „verbrauchter“ Partner übrig ist, beide aber am Anfang der Auslosung in verschiedene Paare oder an verschiedene Tische gelost werden, können Kollisionen nicht mehr vermieden werden.
Hier ein Beispiel für 8 Spieler (a, b, c, d, e, f, g, h):
Runde
Tisch
Paare
1
1
a / b – c / d
2
e / f – g / h
2
1
a / c – b / d
2
e / g – f / h
3
1
a / d – b / c
2
e / h – f / g
4
1
a / e – b / f
2
c / g – d / h
5
1
a / f – b / e
2
c / h – d / g
6
1
a / g – b / h
2
c / e – d / f
7
1
a / h – b / g
2
c / f – d / e
Keine gleichen Gegner
Sollen nur gleiche Gegner vermieden werden, gleiche Partner sind aber egal, muss beachtet werden, dass ein Spieler pro Runde auf zwei Gegner trifft. Es gibt außer dem Spieler, um den es geht, noch n - 1 andere Spieler. Da es ja aber immer zwei sind, berechnet sich die theoretische maximale Anzahl Runden, bevor sich ein Gegner wiederholt zu:
Hier ein Beispiel für 8 Spieler. Es wiederholen sich zwar Paare, die zusammenspielen, aber jeder Spieler spielt für sich nur ein einziges Mal gegen einen anderen:
Runde
Tisch
Paare
1
1
a / b – c / d
2
e / f – g / h
2
1
a / h – b / g
2
e / f – c / d
3
1
c / d – g / h
2
e / f – a / b
Wieder haben wir hier nur ein theoretische Maximum. Ob diese Rundenzahl tatsächlich kollisionsfrei erreicht werden kann, hängt davon ab, wie die Partner zugelost werden – und darauf wird ja nicht geachtet.
Weder gleiche Partner, noch gleiche Gegner
Hier wird es schwierig. Als Ansatz könnte man sagen, dass auf jeden Fall so viele Runden möglich sein müssten, wie ein Spieler immer auf drei neue Mitspieler treffen kann – egal in welcher Konstellation. Damit wäre definitiv ausgeschlossen, dass sich Partner oder Gegner wiederholen – es sind ja immer drei Spieler, auf die der jeweilige Spieler noch nicht getroffen ist.
Nach einiger Recherche habe ich herausgefunden, dass es sich bei dieser Überlegung exakt um das Social-Golfer-Problem handelt, in diesem Fall für Vierergruppen. Allein das ist schon eine kombinatorisch so komplexe Fragestellung, dass man die Lösung nicht mehr berechnen, sondern nur annähern kann.
Ein bekannter Ansatz für dieses Problem ist, dass die theoretische maximale Anzahl an Runden (was den Wochen beim Social-Golfer-Problem entspricht) folgendermaßen abgeschätzt werden kann:
Wobei s die Gruppengröße ist, in unserem Fall also 4. Das ist allerdings tatsächlich nur eine Näherung. Wenn man z. B. die theoretisch zwei möglichen Runden für 8 Spieler konstruieren will, wird man feststellen, dass das tatsächlich für diesen Fall nicht möglich ist.
Für „weder gleiche Partner, noch gleiche Gegner“ dürfte es mehr Möglichkeiten als das geben, da nicht ausgeschlossen ist, dass ein oder mehrere Spieler mehrfach miteinander am Tisch sitzen. Es kommt ja auf die ausgelosten Beziehungen der Spieler an, ob es trotzdem keine Kollision gibt. Allerdings ist ja schon das vermeintlich einfache Social-Golfer-Problem schon nicht zu beherrschen. Zusätzliche Regeln erhöhen die Komplexität hier noch weiter. Allenfalls ist hier vielleicht eine Annäherung der Maximalanzahl der Runden möglich – wenn überhaupt.
Konstruiert man die Zusammenstellung der Paare und ihrer Gegner sorgfältig, sind ungeachtet dessen z. B. für 8 Spieler folgende 3 Runden möglich, in denen weder ein Spieler mehrfach mit, noch gegen einen anderen spielt:
Runde
Tisch
Paare
1
1
a / b – c / d
2
e / f – g / h
2
1
a / e – b / f
2
c / g – d / h
3
1
a / d – e / h
2
b / c – f / g
So eine Auslosung per Zufall zu erhalten halte ich für annähernd ausgeschlossen. Sie programmatisch zu generieren wäre vermutlich möglich, wenngleich bei einem „Brute-Force“-Ansatz, also dem einfachen Ausprobieren aller möglichen Kombinationen, die Anzahl der nötigen Rechenoperationen mit steigender Spieleranzahl vermutlich sehr schnell ins Unendliche abdriftet.
Fazit
Bei festen Paaren ist die Lage relativ übersichtlich. Wenn mit einem festen Schema („Paar 1 bleibt sitzen, Paar 2 rutscht weiter“) gespielt wird, dann gibt es nur eine Auslosung in der 1. Runde. Die maximale Anzahl Runden ist berechenbar und kann definitiv auch erreicht werden. Dasselbe gilt für das zufällige Auslosen, wenn gleiche Gegner vermieden werden sollen: Wir können die theoretische maximale Rundenzahl berechnen; allerdings kann es schon hier – abhängig vom Verlauf der Auslosung – passieren, dass man diese nicht erreicht.
Bei einzelnen Spielern wird es komplexer. Sofern nur gleiche Partner oder gleiche Gegner vermieden werden sollen, ist die maximale Anzahl der Runden zwar berechenbar, aber ob sie tatsächlich erreicht wird, hängt wieder davon ab, wie die Auslosung verläuft. Schwierig wird es, wenn gleiche Partner und gleiche Gegner vermieden werden sollen: Hier wird die Problemstellung so komplex, dass eine einfache Berechnung der maximalen Rundenzahl nicht mehr möglich ist.
Trotz der vermeintlich einfachen Fragestellung handelt es sich hier teilweise tatsächlich um hochkomplexe kombinatorische Probleme, für die es zum Teil schlicht keine Lösung gibt.
Das neue Release des Muckturnier-Programms bringt vor allem Verbesserungen für die Auslosung von Einzelspielern und bessere Unterstützung für Turniere mit nur einem Bobbl pro Runde. Abgesehen davon wurden natürlich auch ein paar Fehler behoben.
Bessere Unterstützung für nur einen Bobbl pro Runde
Wie kürzlich gelernt werden mancherorts nicht mehrere Bobbl pro Runde gespielt, sondern nur eine Runde bis zu einer bestimmten Punktzahl (also faktisch ein einzelner Bobbl). Dem trägt das Programm jetzt Rechnung:
Es gibt jetzt auch eine Spielstandzettel-Vorlage für nur einen Bobbl. Außerdem werden die Oberfläche und der Datenexport jetzt angepasst, wenn es nur einen Bobbl gibt: Es wird jetzt dann z. B. bei der Ergebniseingabe nicht mehr „1. Bobbl“ angezeigt, sondern einfach „Ergebnis“ – es gibt ja nur einen Bobbl. Entsprechend wird auch der Export passend formatiert.
Bessere Auslosung für Einzelspieler
Wenn man Einzelspieler auslost, dann kann man nicht nur einen Haken dafür setzen, dass möglichst vermieden werden soll, dass dieselben Gegner erneut zugelost werden, sondern auch dieselben Partner. Sollte das nicht mehr möglich sein, dann wurde bisher eine komplett zufällige Auslosung gemacht.
Bei wenigen Spielern dauert es nicht lang, bis man beide Kriterien nicht mehr erfüllen kann: Es geht recht schnell, dass in einem gegnerischen Paar ein Spieler ist, gegen den zumindest einer des anderen Paars schon einmal gespielt hat. Die dann zufällig vorgenommene Auslosung hatte dann schnell zur Folge, dass dieselben zwei Spieler mehrfach einander zugelost wurden – es gab also schnell „Kollisionen“ bei Partnern.
Ab jetzt gibt es einen Zwischenschritt: Wenn es keine Plätze mehr gibt, bei denen sowohl das eine wie auch das andere Kriterium erfüllt sind, wird versucht, zumindest das Zulosen von bereits zugelosten Partnern zu vermeiden. Das sorgt für viel weniger Kollisionen: Bei den Partnern gibt es ja nur halb so viele, wie bei den Gegnern – somit kann man dieses Kriterium viel einfacher erfüllen, und die Vorgaben zumindest zur Hälfte deutlich länger erfüllen.
Beim Auslosen einer kompletten Runde wird jetzt darauf hingewiesen, wenn es Kollisionen gab, welche und wie viele. Für Einzelspieler kann man dann erneut eine Auslosung versuchen, weil diese ggf. ein anderes Ergebnis liefern kann (bei festen Paaren gibt es erst dann Kollisionen, wenn es wirklich nicht mehr anders geht).
Neues zu Qt 6
Das Linux-AppImage basiert jetzt auf Qt 6. Auf der mittlerweile ältesten noch unterstützen LTS-Version von Ubuntu (22.04) kann man problemlos mit Bordmitteln Qt 6 bauen und nutzen. Somit dürfte es auf Linux keinerlei Kompatibilitätsprobleme mit einem Qt-6-Build geben.
Die Windows- und macOS-Builds bauen zunächst weiterhin auf Qt 5 auf, um maximale Kompatibilität auch mit alten Rechnern möglichst lang aufrechtzuerhalten.
Weitere Änderungen und Bugfixes
Alle Änderungen enthält, wie immer, der ChangeLog – hier eine Auswahl:
Es wurden einige Rendering- und Anzeigeprobleme, vor allem für den Breeze-Style von KDE, behoben. Weiterhin wurde generell am Aussehen gefeilt. Ausführlich steht das im ChangeLog.
Beim Drucken von Zetteln wird jetzt überprüft, ob versehentlich die voreingestellten Platzhalter-Überschriften belassen oder keine angegeben wurden und in dem Fall eine Warnung angezeigt.
Wenn auf der Anmeldungsseite eine andere Runde für die Auslosung gewählt wird, dann wird diese Runde jetzt auch automatisch auf der Übersicht-Auslosung-Seite angezeigt (und damit auch automatisch das Auslosungs-Display aktualisiert). Auf der Seite selber kann ungeachtet dessen weiterhin eine beliebige Runde ausgewählt werden. Neu ist, dass jetzt auch Runden ausgewählt werden können, für die es noch keine Auslosung gibt.
Es können jetzt wieder alle Markierungen genutzt werden, nicht nur die, die oberhalb der „Unmarkiert“-Markierung einsortiert sind. Auf alle danach konnte man nicht zugreifen. Dieser Fehler hatte sich tatsächlich schon in Version 3.7.0 eingeschlichen, aber ist vermutlich aufgrund der voreingestellten Standardmarkierungen (mit „unmarkiert“ ganz unten) nicht aufgefallen.
Wenn man im Zeitplan-Display jetzt für eine Seite ein Hintergrundbild lädt, und die Seite hatte schon vorher eines, dann wird dieses jetzt sofort angezeigt, und nicht erst, nachdem die Größe des Displays verändert wird.
Bei den Binärpaketen können jetzt auch JPEG-Dateien (insbesondere als Hintergrundbild für das Zeitanzeige-Display) genutzt werden, nicht nur PNG-Dateien. Das Fehlen der JPEG-Unterstützung war gar nicht am Code gelegen, sondern an den Qt-Builds, die bisher zum Bauen der jeweiligen Pakete genutzt wurden. Egal wie – das Problem ist jetzt behoben.
Viel Spaß mit der neuen Version und vor allem beim Mucken :-)
