Ich kopiere hier einfach mal rein, was ich bereits an Apple Feedback zur public preview gesendet habe. Vielleicht erfahre ich hier ja schneller, was ich tun kann:

----

Bisher hatte ich die Möglichkeit, mit folgendem Skript die Anzeige im Dock auf "nur aktive Apps" UND wieder zurück zur Normalansicht zu beeinflussen.

—START AppleScript: —

try
do shell script "defaults read com.apple.dock static-only"
on error
do shell script "defaults write com.apple.dock static-only -bool false" --show only active apps
end try
if result is "0" then
do shell script "defaults write com.apple.dock static-only -bool TRUE" --show all
else
do shell script "defaults write com.apple.dock static-only -bool false" --show only active apps
end if
do shell script "killall Dock"

—END AppleScript—

Seit der Tahoe 26.7 (vielleicht früher) sind nun alle meine vorherigen Einstellungen verloren (also NICHT aktive Apps u. Ordner, etc)

UND (was schlimmer ist): selbst wenn ich per Hand die "alten" Apps wieder ins Dock ziehe (und sogar zur Sicherheit "Im Dock behalten" ankreuze, bzw. Häkchen setze), werden die nicht aktiven Apps nach einem Neustart des Docks wieder nicht angezeigt. Auch ein wiederholtes Abspulen des oben genannten Skripts bringt keine Veränderung.

Wie kann ich unter Tahoe 26.7 meine Dockeinstellungen (nicht-aktive Apps and Ordner im Dock) zurückbringen?

Das Skript ist zum einen etwas merkwürdig, zum anderen basiert es auf einer inoffiziellen Einstellung des Dock, die nie dokumentiert war und deshalb jederzeit von Apple entfernt oder in seinem Verhalten verändert werden kann.

Die normale Art, diese Einstellung wieder außer Kraft zu setzen, wäre

Dieser Menüpunkt hat nichts mit "zur Sicherheit" zu tun. Er wird nur für gerade laufende Apps eingeblendet, weil man die währendessen nicht ein zweites Mal ins Dock ziehen kann, um sie dauerhaft zu behalten.

Erstmal vielen Dank für den richtigen Befehl. Es scheint wieder zu funktionieren (obwohl meine alten "Prefs" inzwischen futsch sind. Aber das lässt sich verschmerzen).

Ich bin leider kein Programmierer und kann nur ein bisschen AppleScript und kenne ein paar Terminalbefehle.

Es war wohl alles nicht mehr so ganz aktuell…

Nochmal vielen Dank!

P.S.:
Mit "zur Sicherheit" war nur gemeint, dass man dieses Häkchen ebenfalls noch setzen konnte - zusätzlich dazu, dass man im Dock App-Symbole durch einfaches Verschieben nach rechts oder links "verewigen" kann. Machen wir kein Problem daraus. (Quellen der Verwirrung… )

Gelinde gesagt …
Das ist aber hier offenkundig nicht das Problem.
Was ist denn daran „normaler“, einen Einstellungsparameter komplett zu löschen, statt ihn einfach auf den Default-Wert zurückzusetzen? Ich fände eher Letzteres „normal“ bzw. sauber. Meinst Du „normal“, weil es sich um eine undokumentierte Einstellung handelt?

Weil Du den „richtigen Befehl“ einmal im Terminal ausgeführt hast, weil Du das Skript mit diesem Befehl modifiziert hast, oder funktioniert das Skript jetzt „einfach so“ wieder?
Das ist diplomatisch formuliert. Wo kommt dieses Skript denn her? Es ist gleich dreifach daneben:

• die Verwechslung der beiden möglichen Einstellungen
• eine völlig unsinnige und unnötige Verwendung von AppleScript
• unnötig umständlich

Ich gehe davon aus, dass das Skript bei jedem Aufruf die aktuelle Einstellung in ihr Gegenteil verkehren soll. Da fangen die Probleme schon an: -bool false oder in Computersprache schlicht 0 zeigt gerade nicht nur die aktiven Apps (wie im Skriptkommentar behauptet), sondern alle (die Default-Einstellung); umgekehrt zeigt -bool TRUE oder in Computersprache schlicht 1 nur die aktiven Apps an und nicht alle. Diese Vertauschung führt dazu, dass, wenn der Parameter noch gar nicht konfiguriert ist und also der Default-Wert verwendet wird, nach dem ersten Aufrufen des Skripts on error getriggert und wieder der Default-Wert gesetzt wird, sich bei der ersten Anwendung des Skripts also überhaupt nichts am Verhalten des Docks verändert (nur intern ist jetzt der Parameter auf den Default-Wert gesetzt, während er zuvor gar nicht konfiguriert war).

Dann die völlig groteske Situation, dass das Skript formal in AppleScript geschrieben ist, obwohl AppleScript (eine fürchterliche Sprache mit einem riesigen Overhead) ausschließlich dazu verwendet wird, Shell-Befehle auszuführen. do shell script öffnet jedes einzelne Mal eine neue Shell! Diese Absurdität treffe ich im Internet immer wieder an. Warum um Himmels willen schreibt man in solchen Situationen nicht einfach gleich ein Shellskript? Das sähe dann 1:1 so aus:
Ich habe das Skript so formatiert, dass es zeilengleich ist, d.h. Du kannst es neben die AppleScript-Variante legen und Zeile für Zeile „vergleichen“.

Das ist aber alles viel zu umständlich; u.a. wird defaults write com.apple.dock static-only 0 völlig unnötigerweise zweimal ausgeführt, wenn zuvor der Wert 1 gesetzt war.

Eigentlich geht es ja nur darum, den gegenteiligen vom aktuellen Wert als Parameter zu setzen. Dafür reicht ein Dreizeiler ohne jegliche if-Verschachtelung:
Der Ausdruck $(( ${result:=0} ^ 1 )) setzt result auf 0, wenn der Parameter noch gar nicht konfiguriert war und result daher bislang undefiniert blieb (0 ist wie gesagt der Default-Wert) und der Exklusiv-Oder-Operator ^ 1 macht aus 0 1 und umgekehrt. 2>/dev/null sorgt dafür, dass ggf. die Fehlermeldung unterdrückt wird, dass der Parameter noch gar nicht konfiguriert ist.

Du musst dieses Skript ausführbar machen (chmod 755 /Pfad/zu/Skript) und kannst es dann einfach nach ~/Library/Scripts/ bewegen, dann erscheint es in der Menüleiste mit dem Namen, den Du der Datei gegeben hast. Aber Achtung: Das Skript geht in dieser Form davon aus, dass es nach wie vor reicht, den Parameter auf 0 zu setzen, statt ihn wie mit Marcel Bresinks Befehl komplett zu löschen. Sollte das in Tahoe nicht der Fall sein, müsste das Skript noch angepasst werden!

Eine letzte Frage habe ich aber noch: wozu das Ganze? Wenn man nur die laufenden Apps sehen will, kann man sich die doch einfach mit anzeigen lassen. Was ist besser daran, dieses Verhalten im Dock zu duplizieren?

Das Löschen des Wertes ist das Einstellen auf den Default-Wert. Das Setzen auf "false" ist dagegen das Einstellen eines bestimmten Wertes, den Du vielleicht gerade für einen Default-Wert hältst, was aber nicht stimmen muss. Da es sich um eine nicht weiter dokumentierte Einstellung handelt, kann Apple das, was als Default angesehen wird, jederzeit ändern. Sogar der Datentyp könnte sich ändern.

Naja, das ist aber ein sehr prinzipienverhaftetes Argument. Ändern kann sich natürlich grundsätzlich immer alles, aber in der Praxis kann ich mich an keinen Fall erinnern, wo eine binäre macOS-Präferenz plötzlich ihren Default-Wert umgedreht hat oder gar durch eine nicht-binäre Präferenz ersetzt wurde. Gerade bei undokumentierten Präferenzen ist meines Erachtens der viel wahrscheinlichere und praxisrelevantere Fall der, dass sie irgendwann einfach nicht mehr existiert bzw. keine Wirkung mehr hat.

Wenn man eine Funktionalität wie die hier besprochene möchte, will man diese Präferenz ja gerade hin- und herswitchen können; solange die binäre Präferenz eine binäre Präferenz bleibt, was hängt dabei daran, was ihr von Apple vorgesehener Default-Wert ist? Eine Präferenz für den einen Fall immer komplett zu löschen, würde für den entgegengesetzten Fall bedeuten, dass dieserären im Skript nicht einfach 0 oder 1 sein dürfte, sondern das Gegenteil von Apples Default-Wert sein müsste, was immer der gerade ist. Dazu müsste das Skript Apples Default-Wert feststellen können; wie soll es das? Wenn das Skript stattdessen den einen Wert als 0 oder 1 hardcodiert, den anderen aber durch Löschen des Default-Eintrags setzen will, funktioniert das Skript nicht mehr, sobald Apple den Default-Wert umdreht, weil dann beide vermeintlich entgegengesetzte Einstellungen dasselbe bewirken.

Sprich: Theoretisch erscheint das komplette Löschen der Präferenz vielleicht prinzipiell korrekter, aber pragmatisch funktioniert nur ein Skript, das den binären Präferenz-Eintrag zwischen 0 und 1 wechselt und komplett ignoriert, welcher davon momentan der Default-Wert ist, zuverlässig auch und gerade für den Fall, dass Apple den Default-Wert umdreht.

Solange das Skript in Tahoe nicht defaults delete erfordert, um zu funktionieren (ob das so ist, hat Whizzbizz ja noch nicht beantwortet), würde ich defaults write für die unter pragmatischen Gesichtspunkten klar bessere Variante halten.

Wie gesagt: ich bin kein Prgrammierer und mathematisch-logische Spielereien verwirren mich meistens nur. Aber so viel scheine ich verstanden zu haben:
Muss man eine „Default“-Einstellung löschen oder würde es bei einer Änderung der „Normaleinstellung“ genügen, die Werte 0 oder 1 (bzw. „false“ oder „true“) einfach zu belassen, damit User-Prefs bei einer Änderung nicht zwangsläufig gelöscht werden?

Hier scheint aber nur noch „delete“ funktioniert zu haben.

Das Skript war übrigens in AppleScript eingebettet, damit sich vom Script-Menü aus einfach mal auf die Schnelle die Ansicht des Dock wechseln ließ.

Zugegeben: mehr eine Spielerei als wirklich nützlich.

Nein, normalerweise muss man das eben nicht, der Wechsel zwischen 0 und 1 reicht nicht nur, sondern bewirkt auch ein stabileres Skriptverhalten, falls Apple mal was ändern sollte.

Was jetzt speziell das Problem bei Dir verursacht hat, weiß ich natürlich nicht. Hast Du den Lösch-Befehl von Marcel Bresink einmal im Terminal ausgeführt und ab dann ging das Skript wieder? Oder hast Du das Skript irgendwie bearbeitet (nach dem, was Du schreibst, ja wohl eher nicht)? Oder ging das Skript plötzlich von selbst wieder?
Normalerweise sollte das so sein, ja. Ob es bei Tahoe aus irgendeinem Grund anders ist, kann ich mangels Tahoe leider nicht testen, fände das aber extrem seltsam.
Ja, das ist meist die Motivation, aber die beruht eben auf der falschen Annahme, dass das mit einem Shellskript nicht ganz genauso ginge. Wie gesagt, Du kannst meinen obigen Dreizeiler in eine TextEdit-Datei kopieren (als reinen Text, also Menü Format → In reinen Text wandeln), ausführbar machen (chmod 755 /Pfad/zu/TextEdit-Datei ins Terminal eingeben) und die Datei nach ~/Library/Scripts/ bewegen und sie wird im Script-Menü in der Menüleiste erscheinen. AppleScript ist dazu einfach nicht nötig, aber aus irgendeinem Grund hält sich dieser Irrtum im Internet seit über zwei Jahrzehnten hartnäckig.

Nein, mein altes Skript hat seit Tahoe nur noch in die Richtung funktioniert, dass die "Normalansicht" auf "nur aktive Apps" verändert wurde. Die umgekehrte Einstellung ließ sich mit dem Script nicht wiederherstellen. Erst das Skript von Marcel Bresink hat die "Normaleinstellung" wieder hergestellt - allerdings auf Kosten meiner vorherigen Einstellungen.

Deswegen ja dieser thread.

Allerdings habe ich das alte Skript nicht mehr probiert, weil ich das gleiche Problem nicht noch einmal haben wollte.

Vielleicht probiere ich es einmal mit einem zweiten User-Account - just to know…

Ja, wusste ich auch nicht. Danke für die Info.

Was ich jetzt nicht verstehe: Was Marcel Bresink gepostet hat, ist doch überhaupt kein Skript, sondern nur ein Terminalbefehl, der die Einstellung komplett löscht und dadurch den Default-Zustand wiederherstellt. Was machst Du denn, wenn Du jetzt wieder die Nur aktive Apps zeigen-Variante haben willst? Nimmst Du dann wieder das Skript oder hast Du die Nase jetzt voll von dem Ganzen, bist froh, dass der Ausgangszustand wiederhergestellt ist und belässt es für die Zukunft dabei?

Wenn es diese Fälle nicht geben würde, hätte ich sie nicht erwähnt. Ich beobachte die Einstellungen seit Mac OS X 10.0 sehr genau. Es gab in der Vergangenheit zum Beispiel mehrmals Fälle, bei denen ein Präferenzwert nach dem Muster
durch
ersetzt wurde, also ein Typwechsel von String nach Bool.

Das waren meiner Erinnerung nach aber ausschließlich Übergangswehen bei ein paar Carbon-Programmen; bei Cocoa-Programmen gab es Strings für binäre Werte nie. Ist aber auch egal: bei so einer „brachialen“ Formatänderung würden ja dann auch die entsprechenden Programme selber die Präferenzen der Vorversion nicht mehr lesen können. Ein Skript, das einen Binärwert hin- und herswitcht, scheitert dann in jedem Fall, weil es den vorangegangenen Wert nicht mehr lesen kann, um daraus den gegenteiligen zu generieren und zu schreiben. Da muss dann in jedem Fall ein neues Skript her. Abgesehen davon dürften solche Fälle mittlerweile längst ein historisches Phänomen aus den Anfangstagen von Mac OS X sein.

Insofern bleibe ich dabei, dass defaults write com.apple.example Setting (augenblicklicher) Default-Wert funktional gesehen defaults delete com.apple.example Setting vorzuziehen ist.

Um ehrlich zu sein: wirklich benutzt habe ich die „nur aktive Apps“-Variante nicht wirklich. Wie gesagt: eher eine Spielerei.

Insofern war mir der Terminalbefehl von Marcel auch erstmal genug. Ich wollte nicht jedesmal mein Dock wieder „neu gestalten“ müssen, weil das alte Skript nicht mehr funktioniert. Vielleicht später mal.

(Obwohl es ja aufschlussreich wäre…)

Das stimmt nicht.

Doch, gerade bei den ureigenen, aus der NeXT-Welt nach Mac OS X übernommenen Programmen war das über viele Jahre hinweg noch üblich, da ursprünglich Objekte (wie Strings) gegenüber Skalaren (wie Bool) bevorzugt wurden.

Das stimmt nicht, denn in Cocoa ist der genannte Fall explizit vorgesehen und das war auch schon im Vorgänger OpenStep so. In der Dokumentation heißt es bis heute bei der Methode "NSUserDefaults boolForKey:" (Objective-C), bzw. "UserDefaults bool(forKey: )" (Swift)
Das Programm "defaults" auf der Befehlszeile ist dagegen typenstrikt. Die in Cocoa vorgesehene Fehlertoleranz bei der Auswertung erlaubt es allerdings, dass ein versehentlich als String angegebener Wert (also zum Beispiel Parameter "-bool" beim defaults-Befehl vergessen) trotzdem wie gewünscht funktioniert.

Ja, Objekte. Aber eben keine String-Objekte. @YES und @NO sind NSNumber-Objekte.

Aber letztlich egal, denn:Was doch eben genau das bedeutet, dass, was auch immer im Detail bei einigen Carbon-Programmen schief lief, es in Cocoa-Programmen diese Kompatibilitätsprobleme nicht gab und gibt.

Was also ist dann das Problem, defaults write statt defaults delete zu verwenden? Ich sehe nach wie vor nicht, wie ein Skript, das stets den jeweils vorhandenen auf den jeweils anderen Binärwert umschalten soll, anders so zuverlässig wie möglich selbst im Falle der von Dir befürchteten Formatänderungen zu realisieren wäre.

Davon war hier nur nirgendwo die Rede. Es ging um das Einstellen einer Benutzerpräferenz mit dem defaults-Programm, entweder über den String "YES" oder den booleschen Wert true.

Danach war nicht gefragt. @Whizzbizz wollte jede Änderung außer Kraft setzen, also wieder den Default-Wert einstellen, egal wie er im laufenden System zufällig lautet.

Dann hast Du die Frage enger aufgefasst als ich. Ich dachte zwar auch, dass er das wollte, aber eben mit Hilfe einer wieder funktionierenden Variante dieses Skripts.