386eb6ae70f9c5a1f320f787665d5a20f7a65ca2
11
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  ScarriffleandClaude Opus 5
|
386eb6ae70 |
Ladelimit ist eine Anzeige, Akku-Kachel sagt etwas, Menüleiste bekommt Kürzel
Der Regler war eine Pseudobedienung. Der SMC lehnt Schreibzugriffe auf CHLT ab — der Helfer hat es mit korrekter Größe versucht und „geschrieben (false), zurückgelesen 85" gemeldet. Das Sicherheitsnetz hat also die Wahrheit gesagt; die Oberfläche hat sie nur nicht gezeigt. Weiter zu raten hieße, im Lade-Subsystem Keys durchzuprobieren, und das ist die eine Operation in diesem Projekt, die Hardware dauerhaft beschädigen kann. Also: das Limit wird gelesen und angezeigt, mit einem Weg in die Systemeinstellungen, wo es tatsächlich geht. Der Schreibpfad ist aus dem privilegierten Helfer entfernt — ein Root-Dienst trägt nur, was benutzt wird. Die Akku-Kachel zeigte „40 %" und einen Verlauf über die letzten Sekunden. Der Ladestand ändert sich in Minuten, nicht in Sekunden; der Graph war eine waagerechte Linie. Jetzt: verbleibende Zeit bzw. Zeit bis voll, Leistung in Watt mit Richtung, Ladelimit, Zustand, Zyklen — und der Energiesparmodus. Der erklärt, warum die Maschine langsamer wirkt, und ohne diesen Hinweis sucht man den Grund woanders. In der Menüleiste standen fünf nackte Prozentzahlen nebeneinander. Man sah Zahlen und wusste nicht, welche wozu gehört. Zwei neue Darstellungen: Kürzel und Wert („CPU 34 %") sowie Symbol und Wert. Beim Akku stehen sie zuoberst in der Auswahl. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
ScarriffleandClaude Opus 5
|
5ba9e551a4 |
Ladelimit gehört zum Akku, nicht zu den Lüftern
Der Regler stand in der Lüfterkachel, weil dort der Helfer schon angebunden war. Das ist die Sicht des Programmierers, nicht die des Nutzers: gesucht wird er beim Akku, und zwar genau dann, wenn man auf den Ladestand schaut. Er steht jetzt in der Akku-Kachel des Panels und im Akku-Popover der Menüleiste. Angebunden über ein Protokoll statt über einen direkten Zugriff: geschrieben wird vom privilegierten Helfer, und der gehört zur App, nicht zu MetricsProvider — die Akku-Ansicht soll ihn bedienen können, ohne ihn zu kennen. Ohne laufenden Helfer ist der Regler sichtbar, aber gesperrt, mit dem Hinweis, wo er herkommt. Ein Regler, der still nichts tut, ist schlimmer als einer, der sagt warum. Dazu Protokollierung, warum das Panel schließt: Zeigerposition, Auslösefläche, Fensterrahmen. „Es ging zu, obwohl ich noch drin war" ist ohne diese drei Zahlen eine Behauptung gegen eine andere — und meine automatisierten Proben halten den Zeiger perfekt still, treffen den Fall also nie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
ScarriffleandClaude Opus 5
|
a54b332723 |
Notch: Toleranz für zitternde Hände, „Panel öffnen" fliegt raus
Warum meine Proben grün waren und deine Hand nicht: jedes einzelne Abtastbild außerhalb der Auslösefläche hat das Aufziehen sofort abgebrochen. Ein Zeiger, den eine Hand an den oberen Rand führt, steht dort aber nicht still — er wandert um ein paar Punkte. Damit fing die Entprellzeit von 220 ms dauernd von vorn an und kam nie ans Ziel. `CGWarpMouseCursorPosition` setzt den Zeiger auf einen Punkt und hält ihn absolut still; deshalb war jede automatisierte Probe 19 von 19 grün. Kurzes Herausrutschen bricht jetzt nicht mehr ab: die Entprellzeit läuft weiter, parallel läuft die Abbruchfrist von 300 ms. Kommt der Zeiger zurück, wird die Frist gestoppt — die Entprellzeit setzt bewusst nicht neu an, sonst dauerte es bei jedem Grenzübertritt wieder von vorn. Das allein hätte einen neuen Fehler gebracht, und ein vorhandener Test hat ihn gefunden: beim beiläufigen Streifen der Notch wäre die Entprellzeit abgelaufen, während der Zeiger längst weg war — das Panel wäre für ein Zehntel aufgeblitzt. Die Maschine merkt sich deshalb, wo der Zeiger steht, und öffnet nur, wenn er da ist. Ist die Entprellzeit abgelaufen, während er draußen war, geht es beim Zurückkommen ohne weiteres Warten auf. Die Auslösefläche reicht außerdem 14 statt 4 Punkte unter die Notch. Vier Punkte sind keine Fläche, die eine Hand trifft. „Panel öffnen" ist aus dem Menü verschwunden. Ein Menüeintrag für etwas, das beim Berühren der Notch von selbst passiert, beschreibt einen Umweg um die eigentliche Bedienung herum. Als Notausgang bleibt es erreichbar, nur ohne eigene Zeile: Linksklick auf das Symbol fährt das Panel aus, Rechtsklick zeigt Einstellungen und Beenden. Dazu Protokollierung jedes Zustandswechsels und jeder Unterdrückung. Ohne diese Spur ist ein Panel, das sich „manchmal nicht öffnet", nicht zu untersuchen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
ScarriffleandClaude Opus 5
|
b2f69f34ae |
Ladelimit: Key gemessen, Schreibpfad gebaut
Der Key heißt CHLT, drei Bytes. Identifiziert per Differenzmessung gegen macOS' eigene Ladebegrenzung, ohne einen einzigen Schreibzugriff: 80 % → 50 01 00 95 % → 5F 01 00 85 % → 55 01 00 Erstes Byte ist die Prozentzahl, zweites offenbar „Limit aktiv", drittes unbenutzt. Drei Messpunkte, weil einer Zufall sein kann: BACC hatte beim ersten Vergleich ebenfalls gepasst — ein Zähler, in dem gerade 50 stand. ChargerConfiguration aus ioreg sah zunächst wie eine zweite Quelle aus (niedriges Byte 0x50 = 80), blieb aber unverändert, als CHLT längst auf 95 stand. Also Zufall, und gut, dass darauf nichts gebaut wurde. Geschrieben wird nur das erste Byte, und nur zwischen 80 und 100 — dem Bereich, den macOS selbst anbietet und in dem gemessen wurde. Darunter ist ungemessenes Gebiet. Bei den Lüftern liefert die Firmware mit F0Mn/F0Mx eigene Grenzen mit, an denen sich ein Sicherheitsnetz festhalten kann; hier gibt es das nicht, hier gibt es nur die Messung. Ein falscher Wert im Lade-Subsystem ist die eine Operation in diesem Projekt, die den Akku dauerhaft beschädigen kann. Nach jedem Schreiben wird zurückgelesen und gemeldet, was tatsächlich steht — nicht, was gewünscht war. „Kein Limit" heißt 100 Prozent und nicht das Aktiv-Byte auf null: diese Kodierung hat macOS nie geschrieben, sie wäre also ungemessen. Bedienung im Lüfter-Bereich der Einstellungen und in der Lüfterkachel, also auch im Menüleisten-Popover. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
ScarriffleandClaude Opus 5
|
c9366302fc |
Wetter: Zwischenspeicher auf Platte, Zeitlimits auf alle Netzaufrufe
Das Protokoll zeigte das Wetter nach 185 ms erfolgreich geladen — und danach nichts mehr. Dazwischen liegt genau ein Aufruf, der noch ins Netz geht: die Abfrage der Namensnennung. Sie hatte kein Zeitlimit, und ohne sie wurde der Schnappschuss nie gebaut. Ein Netzaufruf ohne Zeitlimit ist ein Aufruf, der hängen darf. Jetzt hat jeder ein Limit: Wetter zwölf Sekunden, Ortung acht, Umkehrsuche fünf, Namensnennung drei. Die Namensnennung hält den Messwert ohnehin nicht mehr auf — sie ist Pflicht für die Anzeige, nicht für das Laden — und wird behalten, weil sie sich nicht ändert. Der Zwischenspeicher lag nur im Arbeitsspeicher. Beim Start stand deshalb ein Rädchen da, bis der erste Abruf durch war; hing der, für immer. Er liegt jetzt in weather.json und wird beim Anlegen des Modells gelesen: das Widget zeigt sofort, was zuletzt bekannt war, mit Zeitstempel, und lädt im Hintergrund nach. Ein Wert von vor einer Stunde ist eine Auskunft, ein Rädchen ist keine. Nachgeprüft: Datei wird geschrieben, Hamburg mit zwölf Stundenwerten. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
ScarriffleandClaude Opus 5
|
453353de58 |
Notch öffnet zuverlässig, Einstellungen beenden Onyx nicht mehr
Das Öffnen hing allein an Mausereignissen. Der Auslösebereich liegt aber in der Menüleiste, und dorthin stellt macOS Bewegungen nicht verlässlich an fremde Programme zu — mal kommen sie an, mal nicht, je nachdem, was gerade den Zeiger führt. Ein Verfahren, das eine Zustellung voraussetzt, die es nicht gibt, kann nicht zuverlässig sein. Die Zeigerposition wird deshalb jetzt immer abgefragt, im Ruhezustand zehnmal je Sekunde, bei offenem Panel sechzigmal. Die Monitore sind nur noch Beschleunigung. Kosten: 0,1 % CPU im Leerlauf, gemessen. Nachgeprüft mit fünf Anläufen aus verschiedenen Richtungen — fünfmal offen. Die Unterdrückung war zu grob: jedes Vollbildfenster galt als Grund, das Panel wegzuhalten. Damit war die Notch tot, sobald Xcode im Vollbild lief. Gemeint war immer nur der Film über den ganzen Bildschirm, und den erkennt man daran, dass etwas den Bildschirm wachhält — ein Textfenster tut das nicht. Beide Bedingungen zusammen, nicht eine davon. Dazu ein Loch, das dabei auffiel: fiel die Unterdrückung weg, während der Zeiger schon in der Notch stand, wartete die Maschine auf ein Ereignis, das erst bei der nächsten Bewegung kam. Der rote Knopf blendet Fenster jetzt aus, statt sie zu schließen. Onyx hat kein Hauptfenster; „Fenster zu" heißt hier nie „fertig". Manche Hilfsprogramme erzwingen aber genau diese Gleichung und beenden eine App, sobald ihr letztes Fenster verschwindet — dann war Onyx nach einem Blick in die Einstellungen weg, samt Menüleiste und Notch. Ein Fenster, das nie wirklich schließt, gibt dafür keinen Anlass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
ScarriffleandClaude Opus 5
|
b22a44ba70 |
Mediensteuerung hochkant, Symbole wieder sichtbar, „Auto" als Zustand
Die Mediensteuerung stand nebeneinander: Cover links, alles andere in den verbleibenden gut hundert Punkten. Daher „Bernhard H…" statt eines Titels. Jetzt übereinander, wie es zu einer hochkanten Kachel passt. Das Cover ragte zusätzlich über die Kachel hinaus, weil `clipShape` vor dem Rahmen stand — beschnitten wurde damit auf die Eigengröße des Bildes, und die ist bei einem Podcast-Cover ein Vielfaches. Erst Rahmen, dann beschneiden. Menüleistensymbole waren kaum zu sehen. `color.set()` vor `image.draw(in:)` färbt ein Template-Bild nicht: es wird schwarz gezeichnet, auf einer dunklen Menüleiste also unsichtbar. AppKit färbt Template-Bilder nur ein, wenn sie als `image` eines Buttons gesetzt sind — in einer selbst gezeichneten Ansicht muss die Farbe in die Symbolkonfiguration. Betraf alle fünf Zeichenstellen, nicht nur die Lüfter. „fans.auto" stand als roher Schlüssel da: Xcode hatte ihn extrahiert, gefüllt wurde er nie. Beim Nachsehen waren es 35 solche Einträge über alle Kataloge hinweg — die meisten reine Formatschlüssel, die als Durchreicher trotzdem einen Wert brauchen. Der Automatik-Knopf ist jetzt eine gefüllte Pille, wenn sie greift. Blauer Text sieht aus wie ein Link und nicht wie ein Zustand. Und ein Absturz, der noch niemandem passiert ist: meldet der Helfer für einen stehenden Lüfter keine Grenzen, hätte `Slider(in: 0...0)` die App beendet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
ScarriffleandClaude Opus 5
|
93fe95827f |
Panel wächst in die Breite, Menüleiste wird schmaler
Das Raster ist weg. Widgets stehen nebeneinander, alle gleich groß, in der Reihenfolge aus den Einstellungen. Das Panel sitzt am oberen Rand — nach unten zu wachsen bedeckt den Bildschirm, nach rechts und links legt es sich in den ohnehin leeren Streifen neben der Notch. Eine zweite Reihe entsteht erst, wenn der Bildschirm keine weitere Kachel mehr hergibt. Die Größenauswahl fällt damit weg, und das ist kein Verlust: ein 2×1 neben einem 2×2 lässt oben rechts eine Lücke, die niemand füllen kann und die aussieht wie ein Fehler. Genau daher kam auch die Überlappung. Ein Test prüft jetzt für ein bis zwölf Kacheln, dass sich keine zwei schneiden und alle vollständig im Panel liegen — außerhalb heißt oben: hinter der Notch. Kacheln werden zusätzlich beschnitten, damit überquellender Inhalt nicht über den Nachbarn zeichnet. Der Kalender wählt jetzt zwischen Monatsraster und Terminliste. Das war vorher an die Kachelgröße gekoppelt und ist in Wahrheit eine Frage dessen, was man sehen will. In der Menüleiste wird die Breite gemessen statt geschätzt. Vorher stand je Darstellungsart eine feste Zahl im Code, großzügig gewählt — mit dem Ergebnis, dass neben jedem Wert Platz für ein weiteres Symbol blieb, in dem nichts stand. Gemessen wird die breiteste vorkommende Zeichenfolge, nicht die gerade angezeigte, sonst springt die Leiste bei jedem Messwert. Die Balkendarstellung bekommt ihre Breite aus der Kernzahl, die erst nach der ersten Messung feststeht. Popover schließen jetzt beim Klick daneben. `behavior = .transient` genügt nicht: es greift, solange die eigene App aktiv ist, aber Onyx läuft als .accessory und wird durch einen Klick auf ein Statuselement nicht aktiviert. Ein Klick in ein fremdes Fenster erreichte das Popover gar nicht. Ein globaler Beobachter sieht solche Klicks, ein lokaler die in der eigenen App, Escape schließt ebenfalls — und es ist immer nur eines offen. Mixer und Lüfter haben eigene Menüleistenelemente. Beides regelt man mitten in etwas anderem; der Weg über ein Einstellungsfenster war zu weit. Die Lüfter sind damit auch als Panel-Kachel echt statt Platzhalter. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
ScarriffleandClaude Opus 5
|
a0342205fd |
Phase 9: Einrichtung, Autostart, Notarisierung — und die Mixer-Optik
Die Einrichtung beim ersten Start erklärt jede der vier Sachen einzeln und fragt jede einzeln an. Vier Systemdialoge hintereinander wären der übliche Weg und der falsche: wer nicht weiß wofür, klickt viermal „Nicht erlauben", und danach fragt macOS nie wieder. Sie kommt beim ersten Start immer, auch wenn zufällig schon alles erlaubt ist — sie erklärt auch den Helfer und den Autostart. Beim Autostart ist `requiresApproval` der Zustand, der weh tut. Wer das Anmeldeobjekt in den Systemeinstellungen abgeschaltet hat, kann in Onyx auf den Schalter drücken, so oft er will. Als „aus" angezeigt führt das in eine Schleife, also steht dort jetzt, wo es weitergeht. Der Mixer verliert den Schalter je Programm. Zehn Mini-Schalter untereinander sind das, was den Eindruck macht; am Regler zu ziehen ist ohnehin die Entscheidung, dieses Programm zu regeln, und der große Ausschalter stellt alles zurück. Der Regler ist selbst gezeichnet — der Systemregler bringt sein eigenes Erscheinungsbild mit und kann nicht zeigen, worauf es hier ankommt: den Pegel und die Grenze bei 100 %. Der Pegel wird im selben Durchlauf gemessen, in dem verstärkt wird, und über `Atomic` weitergereicht. Eine gewöhnliche Eigenschaft wäre ein Wettlauf, eine Sperre im Audiothread der klassische Weg zu Aussetzern. Dabei fällt das `Date()` aus dem Echtzeitpfad, das dort nie hingehört hat. Zwei Funde beim Bauen des Release-Wegs, beide hätten erst nach dem Hochladen zur Ablehnung geführt: der Helfer wurde ohne sicheren Zeitstempel signiert, und das Adapter-Framework ad-hoc. Beides gilt jetzt nur noch im Debug. Scripts/release.sh prüft Zertifikat und Notarisierungsprofil vorweg, statt nach zehn Minuten Bauen zu scheitern. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
ScarriffleandClaude Opus 5
|
8308536227 |
Phase 8: Ablage, AirDrop und Calendarr
Calendarr liefert Termine über den Gruppencontainer. Streng lesend: keine eigene Anmeldung, kein Netz, kein Schreiben zurück. Die Abdeckung ist der Kern und kein Detail. Der Schnappschuss reicht 49 Tage nach vorne, und das steht nirgends in der Datei — es ist zugesagtes Verhalten des Schreibers. Außerhalb liegt keine Information vor, nicht keine Termine; das Monatsraster graut solche Tage aus, statt „frei" zu behaupten. Verlockend wäre, die Abdeckung aus dem frühesten Termin abzuleiten. Das ist falsch, und ein Test hält es fest: mehrtägige Termine ragen ins Fenster hinein und werden mitgeschrieben, obwohl ihr Anfang nicht abgedeckt ist. Bei „beide Quellen" ist die Abdeckung der Schnitt, nicht die Vereinigung. Ein Tag gilt nur als bekannt, wenn ihn jede Quelle abdeckt. Umgekehrt darf ein Ausfall einer Quelle die andere nicht mitreißen: Calendarr nie geöffnet zu haben knipst den Apple-Kalender nicht aus. Die Ablage kopiert, statt zu verweisen. Anhänge aus Mail oder WhatsApp liegen in temporären Verzeichnissen — ein Verweis wäre in Stunden tot, und die Ablage wäre leer, wenn man sie braucht. Aus demselben Grund nimmt die Fläche UTType.item statt public.file-url an: solche Anhänge kommen als Dateiversprechen, und loadFileRepresentation löst beides ein. Die übergebene Datei existiert nur innerhalb des Rückrufs, also wird sie dort sofort gesichert statt später auf dem MainActor. Gelöscht wird in den Papierkorb. Automatisches Aufräumen ist standardmäßig aus — eine Ablage, die ungefragt löscht, ist ein Papierkorb mit Zeitschaltuhr. Nebenbei: „mixer.on" und „network.vpn.active" standen als rohe Schlüssel in der Oberfläche. Label(_:systemImage:) kennt kein Bundle und sucht immer im Hauptbundle. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
ScarriffleandClaude Opus 5
|
28b1b4270e |
Audiomixer zeigt Programme statt Prozesse
Core Audio meldet Prozesse, nicht Programme. Angezeigt wurden deshalb Kennungen wie „com.apple.WebKit.GPU" und Dutzende Systemdienste, die theoretisch Ton ausgeben könnten, es aber nie tun. ProcessNaming fragt erst das laufende Programm, kürzt sonst bekannte Hilfsprozess-Endungen weg und schlägt das übergeordnete Programm nach — Chromes Ton kommt aus einem Helfer, angezeigt gehört Chrome. Symbole gehen denselben Weg, sonst steht neben dem Namen ein Platzhalter. ProcessVisibility zeigt, was klingt, kürzlich klang oder geregelt wird. Die Nachlaufzeit von zwei Minuten ist der eigentliche Punkt: ohne sie verschwindet Spotify beim Pausieren aus der Liste, und man kann die Lautstärke genau dann nicht mehr einstellen, wenn man es will. Geregelte Programme bleiben immer — wer etwas leiser gedreht hat, muss es auch zurückdrehen können. Die Prozentzahl wandert vom Namen zum Regler. Oben war sie genau die Breite, die den Namen abgeschnitten hat. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |