Die Einstellungen erreicht man von der Startseite oben rechts oder über das Menü. Alles hier gilt für QuartzControl als Ganzes; was zu einem Projekt gehört, steht im Projekt.
Die Einstellungen — sie rollen weiter, als das Fenster hoch ist.
Erscheinungsbild
Design (Hell, Dunkel, Systemeinstellung) und Sprache (Deutsch, English, Systemsprache folgen). Beides wird sofort übernommen und gespeichert — es gibt hier keinen Speichern-Button. Die Sprache wechselt auch das Menü des Betriebssystems mit, ohne Neustart.
Gemeint ist das Aussehen von QuartzControl. Wie die gebaute Website aussieht, entscheidet Kapitel 4.
Projekte
Das Standard-Projektverzeichnis — der Ordner, in dem die Dialoge zum Öffnen und Anlegen
starten. Ein vollständiger Pfad, beginnend mit / oder ~/, oder über den Ordner-Dialog gewählt.
Beim Beenden
Was mit einem laufenden Dev-Server passiert, wenn QuartzControl geschlossen wird — Fragen, Weiterlaufen lassen oder Beenden.
„Weiterlaufen lassen“ heißt wirklich weiterlaufen: Der Server bleibt im Browser erreichbar. Beim nächsten Start bemerkt QuartzControl ihn und fragt, ob er beendet werden soll; die Seite „Vorschau & Build“ listet ihn ebenfalls.
Laufzeit
Die Laufzeit — darunter, welches git benutzt wird und warum.
Womit Quartz und npm ausgeführt werden — In QuartzControl (Voreinstellung) oder Vom System.
Die Voreinstellung ist die richtige. Node und npm reisen mit QuartzControl, deshalb muss auf dem Rechner
nichts installiert sein, und Versionsunterschiede zwischen zwei Rechnern gibt es nicht. Umschalten
lohnt sich in genau einem Fall: wenn ein Paket beim Installieren erst kompiliert werden muss — die
Fehlermeldung nennt dann node-gyp.
Darunter steht, welches git benutzt wird. Hier ist die Regel umgekehrt: das des Rechners
gewinnt, sobald es antwortet, damit die eigene .gitconfig und die eigenen Zugangshelfer weiter
gelten. Nur wenn keines da ist, springt das mitgelieferte ein.
Eine Änderung gilt für Vorgänge, die danach starten. Ein laufender Dev-Server behält seine Umgebung, bis er neu gestartet wird.
GitHub
Ein persönlicher Zugriffs-Token. Er wird an drei Stellen gebraucht, und wofür wie viel nötig ist, ist der einzige Punkt, den man wissen muss:
| Wofür | Welcher Token |
|---|---|
| Marktplatz und Theme-Katalog | Einer ganz ohne Berechtigungen genügt. Er hebt nur das Anfragelimit an. |
| Repository anlegen, GitHub Pages einrichten | Einer mit der Berechtigung repo. |
Speichern & prüfen fragt bei GitHub nach. Die Antwort ist dreiwertig, und das ist Absicht: Gültig, Abgelehnt (abgelaufen oder zurückgezogen) — oder Nicht prüfbar, wenn GitHub nicht erreichbar war. Das Letzte heißt nicht „ungültig“ und auch nicht „gültig“, sondern offen.
Der Token liegt verschlüsselt im Schlüsselbund des Systems. Ein gespeicherter wird nicht angezeigt; zum Ersetzen gibt man einen neuen ein.
Zugänge
Drei Zugänge; wohin ein Projekt damit veröffentlicht, steht im Projekt.
Server-Logins und Build-Hooks zum Veröffentlichen. Sie stehen hier und nicht im Projekt, weil dasselbe Webspace-Konto mehrere Websites tragen kann: Ein Passwortwechsel ist dann eine Änderung statt einer pro Projekt.
Was ein Zugang von einem Ziel unterscheidet, steht in 6.1 — dort wird auch angelegt, wohin ein Projekt veröffentlicht. Hier steht nur die Anmeldung.
Wird ein Zugang benutzt, steht an ihm, von wie vielen Projekten. Beim Löschen fragt QuartzControl entsprechend deutlicher: Danach zeigen deren Ziele ins Leere.
Daten & Wartung
- Theme-Dokumentation — die Beschriftungen der Theme-Optionen, einmal von GitHub geholt und aufbewahrt. Leeren erzwingt ein erneutes Laden.
- Speicherort — wo Projektliste, Einstellungen und die verschlüsselten Zugänge liegen, mit einem Button, der den Ordner öffnet.
Hier erscheint auch die Meldung „Eine gespeicherte Datei war nicht lesbar“, falls QuartzControl beim Start eine seiner eigenen Dateien nicht öffnen konnte. Sie wird dann zur Seite gelegt statt überschrieben — der Inhalt ist also noch da —, aber was darin stand, fehlt in QuartzControl und muss neu angelegt werden.