Neuer Stil "Nachtprisma", Gespraeche anheften, und unten wieder Luft
Drei Sachen aus einem Bildschirmfoto-Satz.
=== 1. EIN ANDERER STIL, NICHT DIESELBE SPRACHE MIT NEUEN DETAILS ===
Filipe, zum dritten Mal an derselben Stelle: "du verstehst es wirklich
nicht ... ich will eine komplette aenderung vom aussehen. vom
hintergrund und von der grossen kachel. ich will einen ganz anderen
stil ... die leute sollen morgen nichts mehr wieder erkennen vom
aussehen her."
WARUM MEINE ZWEI ANLAEUFE DAVOR NICHT GEREICHT HABEN -- und das ist
kein Geschmacksstreit, sondern ein Fund:
Der Umriss des Chats kommt gar nicht aus chat.css. Er steht in
module.css, in einer Liste von 50 Klassen, und `.chat` ist eine davon:
Fase oben links, Kantenlicht, Punktraster, drei goldene Eckwinkel.
module.css wird NACH chat.css geladen -- und die Staerke des `:is(...)`
dort ist (0,2,0), weil `.gruppe[data-gruppe]` mit in der Liste steht.
Jede meiner Regeln war gleich stark und kam frueher. Deshalb stimmte
beides: "ich habe den Rand geaendert" und "der Rand ist derselbe". Ich
habe zweimal Details INNERHALB eines Rahmens geaendert, den ich nicht
angefasst hatte -- und den erkennt man zuerst.
Der neue Block steht als eine klar benannte Schicht am Ende von
chat.css, mit `.inhalt.chat-seite` -- eine Klasse mehr als module.css,
kein `!important` (das waere eine Tuer, die man nie wieder zubekommt).
ALT NEU
Fase oben links rundum 26 px weich
drei goldene Eckwinkel keine -- der Koerper traegt sich selbst
Punktraster drei weiche Lichter im Hintergrund
1-px-Rahmen ueberall kein Rahmen, Lichtkante innen
Gold als Leitfarbe Lavendel/Violett, Blasen wie gehabt
Kaesten nebeneinander Koerper mit Tiefe und farbigem Schatten
DIE LEITFARBE WIRD AN EINER STELLE GETAUSCHT, nicht an zwanzig. Im
ersten Anlauf habe ich zehn Regeln einzeln umgefaerbt und danach im
Bild gesehen, dass Suchfeld, "Neu", Zaehler und Fokusrahmen weiter
golden waren -- sie nehmen alle `--akzent` und `--rand`. Jetzt stehen
beide am `<main>` der Chatseite. Uebersicht, Kalender und Aufgaben
behalten ihr Gold; nur der Chat soll nicht wiederzuerkennen sein.
#b9a7ff UND NICHT #7a5cff, und das ist gerechnet, nicht gewaehlt: Die
Akzentfarbe ist hier auch FLAECHE unter dunkler Schrift (die
Ungelesen-Marke). Das satte Violett kommt dort auf 3,7:1 -- zu wenig.
Das helle auf 8,9:1, und als Schrift auf dunklem Grund genauso.
WAS UNANGETASTET BLEIBT: `--blasengrund`, `--blase-text`,
`--blase-leise`, `--namen-anteil`. An ihnen haengen die Messungen von
pruef-chatkachel (12 Kacheln) und pruef-chat-neu (360 Ringtoene). Ein
Stilwechsel darf eine Zusage nicht nebenbei aufheben.
pruef-chat-optik hat sofort einen echten Schaden gemeldet: Der neue
Stil nahm allen Blasen den Rahmen -- und damit auch den, mit dem eine
NICHT ABGESCHICKTE Nachricht markiert ist ("der Unterschied ist auch zu
SEHEN, nicht nur im Merkmal (Rand 0px)"). Genau dafuer steht die Zeile
dort. Der Warnton sitzt jetzt zusaetzlich im inneren Saum.
=== 2. GESPRAECHE ANHEFTEN ===
Filipe: "ich will dass man auch individuel jeder fuer sich auch in der
liste chats fixieren kann. auch mehrere nicht nur eins."
Drei Aussagen, und jede wird einzeln geprueft:
"fixieren" -> `fixiert_am` an der TEILNEHMER-Zeile; Angeheftetes
steht oben, darunter geht die gewohnte Reihenfolge
weiter.
"individuell" -> die Spalte haengt an der Person, nicht am Raum. Eine
Spalte an `chat_raeume` haette alles andere genauso
erfuellt und jedem im Raum das Gespraech oben
hingeklebt -- gemerkt haette man es erst, wenn sich
jemand beschwert. Die Gegenprobe prueft deshalb
ausdruecklich, dass es bei Luna weder markiert ist
noch nach oben rutscht.
"auch mehrere" -> keine Obergrenze. Ein Zeitstempel statt Ja/Nein
kostet dasselbe und beantwortet die Frage mit,
in welcher Reihenfolge mehrere stehen: zuletzt
angeheftet oben.
Die Nadel steht IMMER an der Zeile, nicht erst beim Ueberfahren -- am
Handy gibt es kein Ueberfahren (dieselbe Entscheidung wie am 23.09. bei
den Handgriffen), und eine Spalte, die mal da ist und mal nicht, laesst
die Namen daneben wandern. Sie liegt schraeg, solange nichts
angeheftet ist, und steht aufrecht, wenn doch -- das sieht man auch
ohne Farbe.
Der Zustand wird GESCHICKT, nicht errechnet (`an: true/false`): Ein
Schalter, der den Gegenwert selbst ausrechnet, kippt bei zwei schnellen
Klicks oder zwei offenen Fenstern in den falschen Zustand.
Die Karte ist seit heute die ZEILE und nicht mehr der Knopf darin --
im ersten Anlauf sass die Nadel sichtbar ausserhalb der Flaeche, wie
ein Knopf, der danebengefallen ist.
=== 3. UNTEN WIEDER LUFT ===
"schieb das bisschen hoeher bitte, weil das ist unten zu nah am rand."
14 px Polsterung. Sie geht nach INNEN (`border-box`), macht die Seite
also nicht laenger -- sonst waere das Schreibfeld wieder unter den
Bildrand gerutscht, und genau darum ging es am 09.09. schon einmal.
Geprueft: pruef-chat (neuer Abschnitt Anheften, 14 Punkte, alle gruen),
pruef-chat-optik, pruef-chatkachel (40), pruef-chat-neu (32),
pruef-chat-ausbau (64), pruef-chat-kanaele (81), pruef-chat-aufloesen
(126), pruef-chat-anhaenge (109), pruef-erwaehnung (129),
pruef-css-klassen, pruef-tippziele (11), pruef-lesbarkeit.
Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
Claude Opus 5
@@ -1110,7 +1110,7 @@ chatRouter.get("/workspace/api/chat/raeume", (req, res) => {
|
||||
angelegt hat. */
|
||||
const reihen = db().prepare(`
|
||||
SELECT r.id, r.art, r.name, r.kategorie, r.letzte_am, r.erstellt_von,
|
||||
t.gelesen_bis, t.leitung, t.geloescht_bis
|
||||
t.gelesen_bis, t.leitung, t.geloescht_bis, t.fixiert_am
|
||||
FROM chat_raeume r
|
||||
JOIN chat_teilnehmer t ON t.raum_id = r.id AND t.person_id = ?
|
||||
WHERE t.raus_am IS NULL
|
||||
@@ -1118,7 +1118,19 @@ chatRouter.get("/workspace/api/chat/raeume", (req, res) => {
|
||||
AND (t.geloescht_am IS NULL
|
||||
OR EXISTS (SELECT 1 FROM chat_nachrichten n
|
||||
WHERE n.raum_id = r.id AND n.id > t.geloescht_bis))
|
||||
ORDER BY CASE WHEN r.letzte_am IS NULL THEN 1 ELSE 0 END, r.letzte_am DESC, r.id DESC`)
|
||||
/* ANGEHEFTETES ZUERST (25.09.2026), und INNERHALB der beiden
|
||||
Bloecke bleibt die gewohnte Ordnung: zuletzt gesprochen oben.
|
||||
Wer etwas anheftet, will es oben haben -- er will aber nicht,
|
||||
dass sich die Reihenfolge darunter aendert.
|
||||
|
||||
ZULETZT ANGEHEFTET STEHT GANZ OBEN. Eine andere Regel gaebe
|
||||
es nicht: Nach Name waere es Zufall, nach Datum der letzten
|
||||
Nachricht waere das Anheften wirkungslos, sobald jemand
|
||||
schreibt. */
|
||||
ORDER BY CASE WHEN t.fixiert_am IS NULL THEN 1 ELSE 0 END,
|
||||
t.fixiert_am DESC,
|
||||
CASE WHEN r.letzte_am IS NULL THEN 1 ELSE 0 END,
|
||||
r.letzte_am DESC, r.id DESC`)
|
||||
.all(req.person.id);
|
||||
|
||||
const raeume = reihen.map((r) => {
|
||||
@@ -1203,6 +1215,10 @@ chatRouter.get("/workspace/api/chat/raeume", (req, res) => {
|
||||
} : null,
|
||||
ungelesen,
|
||||
erwaehnt,
|
||||
/* Als Ja/Nein an die Oberflaeche -- WANN jemand etwas
|
||||
angeheftet hat, geht niemanden etwas an, auch ihn selbst
|
||||
nicht. Der Zeitstempel ist Sortierung, keine Auskunft. */
|
||||
fixiert: !!r.fixiert_am,
|
||||
};
|
||||
});
|
||||
/* WELCHE KANAELE ES NOCH NICHT GIBT -- und nur fuer die, die sie
|
||||
@@ -2985,6 +3001,52 @@ chatRouter.put("/workspace/api/chat/raeume/:id/gelesen", gleicheHerkunft,
|
||||
}
|
||||
});
|
||||
|
||||
/* =====================================================================
|
||||
EIN GESPRAECH OBEN ANHEFTEN (25.09.2026)
|
||||
=====================================================================
|
||||
|
||||
Filipe: „ich will dass man auch individuel jeder fuer sich auch in
|
||||
der liste chats fixieren kann. auch mehrere nicht nur eins."
|
||||
|
||||
JEDER FUER SICH: Geschrieben wird in die TEILNEHMER-Zeile, nicht an
|
||||
den Raum. Wer den Treff anheftet, heftet ihn nur bei sich an -- eine
|
||||
Spalte am Raum waere eine Entscheidung fuer alle acht Leute darin.
|
||||
|
||||
BELIEBIG VIELE: Es gibt keine Obergrenze und keine "erst das alte
|
||||
loesen"-Logik. Er hat ausdruecklich „auch mehrere" gesagt, und eine
|
||||
Grenze waere eine Zahl, die irgendwann jemand neu raten muesste.
|
||||
|
||||
`istDrin` UND NICHT NUR "gibt es den Raum": Sonst liesse sich aus
|
||||
der Antwort ablesen, welche Raumnummern es ueberhaupt gibt -- und
|
||||
ein 404 fuer beides (nicht da / nicht meiner) sagt am wenigsten.
|
||||
|
||||
DIE ANTWORT TRAEGT DEN NEUEN STAND und nicht nur „ok". Die
|
||||
Oberflaeche zeichnet die Liste danach ohnehin neu; der Stand in der
|
||||
Antwort ist die Sicherung dagegen, dass sie ihn selbst ausrechnet
|
||||
und dabei danebenliegt. */
|
||||
chatRouter.put("/workspace/api/chat/raeume/:id/fixieren", gleicheHerkunft,
|
||||
express.json({ limit: "4kb" }), (req, res) => {
|
||||
try {
|
||||
const raumId = Number(req.params.id);
|
||||
if (!Number.isInteger(raumId)) return res.status(400).json({ fehler: "ungueltig" });
|
||||
if (!istDrin(raumId, req.person)) return res.status(404).json({ fehler: "nicht_gefunden" });
|
||||
|
||||
/* AUSDRUECKLICH `=== true` / `=== false` und kein Umschalten
|
||||
ohne Angabe. Ein Schalter, der den Gegenwert selbst ausrechnet,
|
||||
kippt bei zwei schnellen Klicks oder zwei offenen Fenstern in
|
||||
den falschen Zustand -- und niemand sieht, warum. Die
|
||||
Oberflaeche weiss, was sie will; sie sagt es. */
|
||||
const an = req.body?.an === true;
|
||||
db().prepare(`UPDATE chat_teilnehmer SET fixiert_am = ?
|
||||
WHERE raum_id = ? AND person_id = ?`)
|
||||
.run(an ? new Date().toISOString() : null, raumId, req.person.id);
|
||||
res.json({ ok: true, fixiert: an });
|
||||
} catch (fehler) {
|
||||
console.error("[chat] Anheften:", fehler?.message);
|
||||
res.status(503).json({ fehler: "nicht_verfuegbar" });
|
||||
}
|
||||
});
|
||||
|
||||
/* =====================================================================
|
||||
ANKUENDIGUNGEN ANHEFTEN (10.09.2026, Kapitel 7.2)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user