DogFatherGitandClaude Opus 5
0784ad61ce
GEFUNDEN DURCH EINEN HINWEIS AUS DEM ANDEREN HAUS. Die Crew-Sitzung hat
heute eine Hilfe gebaut, die getippten Text ueber das Neuzeichnen
rettet, und dazugeschrieben: "Falls dir in bereich.js dasselbe begegnet
-- Liste wird neu gebaut, Feld darin entsteht neu." Genau das war hier
der Fall, nur mit einer Ausgabe statt einer Eingabe.
DER FEHLER: `beitragZeigen()` hing den fertigen Discord-Beitrag an das
DOM-Element der Kachel. Direkt danach lief `await laden()` -- die
Kachel muss ja "Link kopieren" statt "Teilen" anzeigen --, und `laden()`
leert die ganze Liste. Der Kasten wurde also im selben Atemzug
angehaengt und weggeraeumt.
GEMESSEN, NICHT VERMUTET: Die neue Pruefung fand ihn schon 600 ms nach
dem Druck nicht mehr. Beim Zusehen faellt das nicht auf -- es geht zu
schnell --, und die Zwischenablage stimmte ja. Es waere also als "steht
sichtbar unter der Kachel" in die Welt gegangen, ohne je gestimmt zu
haben. Ich hatte es genau so gemeldet.
DIE BEHEBUNG: Der Beitrag steht jetzt in `beitraege`, einer Liste je
Eintragsnummer, und `karte()` haengt ihn beim Bauen wieder an. Damit
uebersteht er beliebig viele Neuzeichnungen -- bis ihn jemand
schliesst, und dann wird er auch aus dem Gedaechtnis genommen, sonst
stuende er beim naechsten Mal wieder da.
NICHT DIESELBE SACHE WIE `getippt.js`: Dort wird ein EINGABEFELD an
einen Serverwert gebunden. Hier ist es eine AUSGABE ohne Serverfeld --
der Baustein haette nichts zu binden. Die Erkenntnis dahinter traegt
trotzdem: Was ein Neuzeichnen ueberleben soll, darf nicht im DOM
wohnen.
DIE PRUEFUNG MISST BEIDES, nicht nur eines: dass der Kasten erscheint
UND dass er nach dem Neuzeichnen noch da ist. "Er erscheint" allein
waere gruen gewesen, auch bei einem Kasten, der einen
Sekundenbruchteil spaeter weg ist. Dazu, dass Schliessen wirklich
schliesst. Sie war vor der Behebung rot (5 Fehler) und ist danach
gruen -- die Gegenprobe steckt also im Ablauf selbst.
GEPRUEFT: 190 (Kachel, +8), struktur, css-klassen. Stempel neu gesetzt,
weil bereich.js sich geaendert hat.
PARALLELE ARBEIT: Die Crew-Sitzung hat vorher ausgeliefert (ab204e96)
und ist fertig; die Arbeitskopie war sauber, als ich angefangen habe.
Co-Authored-By: Claude Opus 5 <[email protected]>
70 lines
3.0 KiB
HTML
70 lines
3.0 KiB
HTML
<!doctype html>
|
||
<html lang="de">
|
||
<head>
|
||
<meta charset="utf-8" />
|
||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||
<title>Bühne – das laufende Video</title>
|
||
<!-- ======================================================================
|
||
DAS LAUFENDE VIDEO ALS BROWSER-QUELLE (28.09.2026)
|
||
|
||
Zeigt das Video, das gerade in der Reaction läuft — auf dieselbe
|
||
Sekunde wie bei allen anderen. Sonst nichts: kein Chat, keine
|
||
Kameras, keine Bedienung, kein Rand.
|
||
|
||
WARUM DIE EIGENE KAMERA HIER NICHT DRIN IST: Sie ist in OBS
|
||
direkt als Gerät verfügbar, in besserer Qualität und frei in
|
||
Größe und Lage. Den Umweg über den Browser zu nehmen hieße,
|
||
Qualität gegen nichts einzutauschen — und die Größe wäre dann
|
||
festgelegt statt frei.
|
||
|
||
Sind GÄSTE im Bild, kommen deren Kameras über eine
|
||
Direktverbindung an, und die braucht eine angemeldete Seite.
|
||
Dafür gibt es den Bühnenmodus der Reaction-Seite
|
||
(`reaktion.html?nur=buehne`), der als Fenster aufgenommen wird.
|
||
|
||
In OBS: Quelle → Browser → diese Adresse, 1920 × 1080,
|
||
„Steuerung anzeigen" aus.
|
||
====================================================================== -->
|
||
<style>
|
||
html, body {
|
||
margin: 0; padding: 0;
|
||
background: #000;
|
||
height: 100%; overflow: hidden;
|
||
font-family: "Segoe UI", system-ui, -apple-system, sans-serif;
|
||
}
|
||
#platz { position: fixed; inset: 0; }
|
||
#platz iframe { width: 100%; height: 100%; border: 0; display: block; }
|
||
|
||
/* ==== BEI „NUR KAMERA" GEHT DAS BILD AUS ========================
|
||
Sonst läge im Stream ein stehengebliebenes YouTube-Bild unter
|
||
den Kameras — und Filipe sähe es nicht, weil er in OBS auf
|
||
seine Szene schaut und nicht auf die Quelle.
|
||
|
||
`visibility` UND NICHT `display`. Ein Spieler, den man aus dem
|
||
Seitenaufbau nimmt, hört auf zu dekodieren; beim Zurückschalten
|
||
müsste er erst wieder an die richtige Stelle springen, und das
|
||
sehen dann alle. So läuft er weiter, nur eben unsichtbar, und
|
||
ist in derselben Sekunde wieder da. */
|
||
body[data-bild="aus"] #platz { visibility: hidden; }
|
||
|
||
/* Was zu sehen ist, wenn gerade nichts läuft. Schwarz und still --
|
||
eine Beschriftung stünde im Stream. Nur bei einem falschen
|
||
Schlüssel gibt es einen Hinweis, denn den sieht man sonst nie. */
|
||
.obs-fehler {
|
||
position: fixed; left: 16px; top: 16px;
|
||
padding: 10px 14px; border-radius: 10px;
|
||
background: rgba(140, 20, 30, .9); color: #fff; font-size: 14px;
|
||
}
|
||
</style>
|
||
<!-- DIE WERBEEINBLENDUNG. Dieselbe Datei wie in der Reaction-Seite:
|
||
Zwei Fassungen altern unterschiedlich, und dann sieht der Stream
|
||
anders aus als das, worueber geredet wird. -->
|
||
<link rel="stylesheet" href="assets/css/werbung.css?v=202610081523" />
|
||
</head>
|
||
<body class="obs-buehne">
|
||
<div id="platz"></div>
|
||
<script src="assets/js/werbung.js?v=202610081523" defer></script>
|
||
<script src="assets/js/buehne.js?v=202610081523" defer></script>
|
||
</body>
|
||
</html>
|