docs: ADR-0023 Nachtrag - noninteractive verworfen, automatic-ubiquity+Autoklicker

Datei war bisher nie committed (Versehen aus einer frueheren Sitzung).
Enthaelt jetzt den vollstaendigen, bereits ausgearbeiteten Stand
inklusive des heutigen Nachtrags: noninteractive-Frontend endgueltig
verworfen (strukturelle PageNoninteractive-Stubs fuehren zur
Endlosschleife), Umstieg auf automatic-ubiquity + eigener Autoklicker,
drei real gefundene und behobene Bugs (fehlendes jq beim Kiosk-Auslauf,
Ubiquity-GTK-Absturz in ubi-prepare.py, choose_partition-select-finish-
Endlosschleife), Klarstellung dass der GRUB/isolinux-Sicherheits-Default
kein Bug ist (ADR-0009), und der noch offene automatisierte Klick auf
'Jetzt installieren'.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

adr/0023-ubiquity-priority-critical-fuer-echte-stille.md

@@ -0,0 +1,335 @@
+# ADR-0023: `priority=critical` fürs wirklich unbeaufsichtigte Mint-Install
+
+**Status:** Beschlossen
+**Datum:** 28.08.2026
+
+## Kontext
+
+Beim ersten echten Self-Service-Flow-Test auf physischer Hardware (Notebook,
+Organisation "Liebherr", 28.08.2026) zeigte die Installation trotz
+"Tuxflotte Auto-Install"-Bootmenüeintrag (`automatic-ubiquity noprompt` im
+Kernel-Append, korrekter, vollständig aufgelöster Preseed mit allen
+nötigen Werten — Netzwerk, Zeitzone, Partitionierung, Benutzer, Codecs)
+**jede** Ubiquity-Seite interaktiv an: Zeitzone-Bestätigung,
+Multimedia-Codecs-Frage, "Vorhandene Installation überschreiben?" und
+Benutzeranlage.
+
+Ausführliche Live-Fehlersuche (siehe [[project_e2e_flow_dogfooding_2026-08-28]]
+für den vollständigen Verlauf) hat mehrere naheliegende Verdächtige
+geprüft und ausgeschlossen, bevor die eigentliche Ursache gefunden wurde:
+- Falsch gewählter Bootmenüeintrag — ausgeschlossen (User hat "Tuxflotte
+  Auto-Install" korrekt gewählt, bestätigt durch Bildschirm: kein
+  Cinnamon-Desktop sichtbar, nur Ubiquitys eigenes Vollbildfenster — Abbruch
+  legt den normalen Desktop darunter frei, das automatische Ubiquity läuft
+  also tatsächlich).
+- Fehlende/kaputte WLAN-Zugangsdaten im Preseed — ausgeschlossen (`/opt/
+  tuxflotte/config/installer.conf` enthielt alle vier erwarteten Zeilen
+  korrekt; dasselbe Verhalten trat auch mit funktionierendem Ethernet auf).
+- Dateiberechtigungen (`installer.conf`, `sudoers.d/90-tuxflotte`) —
+  ausgeschlossen, per `xorriso -lsdl` an der echten gebauten ISO
+  gegengeprüft, beide unauffällig (644 bzw. das für sudoers.d korrekte 440
+  root:root).
+- Fehlende Codec-Preseed-Zeile — ausgeschlossen, `ubiquity ubiquity/
+  use_nonfree boolean true` war bereits korrekt gesetzt (die dokumentierte
+  Lösung für ein bekanntes Mint-21-Problem, siehe
+  https://github.com/linuxmint/mint21-beta/issues/34).
+
+**Tatsächliche Ursache:** `automatic-ubiquity` allein bewirkt laut Ubiquity-
+Dokumentation nur, dass Seiten übersprungen werden, deren Fragen *alle*
+bereits beantwortet ("seen") sind — reicht in der Praxis oft nicht aus, um
+wirklich jede Seite zu unterdrücken. Der fehlende Baustein ist die
+Debconf-Priorität: ohne `priority=critical` zeigt der Installer weiterhin
+Seiten an, auch wenn die zugehörigen Fragen vorbelegt sind. Durch mehrere
+unabhängige Quellen bestätigt (siehe Recherche im Chat).
+
+## Entscheidung
+
+`priority=critical` zum Kernel-Append des "Tuxflotte Auto-Install"-
+Menüeintrags ergänzt — in `grub/mint-boot-grub.cfg` und `grub/mint-
+isolinux-live.cfg`, jeweils nur bei diesem einen Eintrag (die übrigen
+Menüpunkte wie "Start Linux Mint"/"OEM install" bleiben bewusst
+unverändert interaktiv). Beide Dateien werden sowohl vom echten
+Kunden-ISO-Bau (`scripts/build_customer_iso.sh`) als auch vom lokalen/
+QEMU-Testpfad (`scripts/build.sh`) verwendet — der Fix deckt also beide
+Wege ab, ohne eine zweite Stelle anfassen zu müssen.
+
+## Konsequenzen
+
+Reine Boot-Parameter-Änderung, kein Preseed-/Server-/Agent-Code betroffen.
+Noch **nicht live verifiziert** — die nächste ISO, die für "Liebherr" (oder
+jede andere Organisation) gebaut wird, enthält den Fix automatisch, da
+`build_customer_iso.sh` die Dateien bei jedem Bau frisch kopiert. Die
+eigentliche Verifikation folgt beim nächsten Installationsversuch des
+Users.
+
+Offen, falls `priority=critical` allein nicht ausreicht: die
+Zusammenfassungsseite (`ubiquity ubiquity/summary note`) müsste laut
+Recherche ggf. auf einen leeren Wert gesetzt werden, um ebenfalls
+übersprungen zu werden — nicht vorab geändert, da nicht durch eigene
+Beobachtung bestätigt, nur in der Recherche als möglicher Zusatzpunkt
+aufgetaucht.
+
+## Nachtrag (28.08.2026): `priority=critical` war notwendig, aber nicht hinreichend — echte Ursache tiefer
+
+Live-Verifikation in der QEMU-Test-VM (`tuxflotte-mint-autoinstall-test`,
+siehe [[project_e2e_flow_dogfooding_2026-08-28]]) hat den in dieser ADR
+angenommenen Rahmen korrigiert:
+
+1. **Der "Tuxflotte Auto-Install"-Bootmenüeintrag selbst ist strukturell
+   kaputt und war nie der richtige Pfad.** Er referenziert
+   `file=/cdrom/preseed/tuxflotte.seed` — dieses Verzeichnis existiert auf
+   keiner gebauten ISO (`ls /cdrom/` bestätigt: kein `preseed/`-Ordner).
+   `build_customer_iso.sh` bäckt bewusst keinen Preseed auf die ISO (siehe
+   eigener Kommentar dort) — Hostname/Geräte-ID/Partitionierung werden
+   erst live aufgelöst.
+2. **Der tatsächlich funktionierende Mechanismus existiert bereits seit
+   06.08.2026 (Commit `d6a0146`): `backend_launch()` in
+   `backends/mint/backend.sh`.** Er baut zur Laufzeit einen echten,
+   vollständig aufgelösten Preseed, hängt ihn als zusätzlichen
+   cpio-Layer an `/cdrom/casper/initrd.lz` an und bootet per `kexec` neu
+   mit `automatic-ubiquity noprompt file=/preseed.cfg …`. Erreicht wird
+   dieser Pfad aber nur über den **"Start Linux Mint"-Eintrag** (bzw.
+   jeden Nicht-`automatic-ubiquity`-Eintrag) → `start-kiosk.sh` erkennt
+   `TUXFLOTTE_AUTO_MODE=true` → `installer.sh` → `40_backend.sh` →
+   `backend_launch()`. Live bestätigt: `/sbin/init`-Cmdline im zweiten
+   Boot lautet `automatic-ubiquity noprompt splash`, `ubiquity --automatic
+   --only` und `debconf-communicate -fnoninteractive` laufen tatsächlich.
+   Der Nutzer hatte diesen Mechanismus korrekt in Erinnerung, meine
+   eigene Aussage in einer früheren Session, `backend_launch()` sei ein
+   Stub, war falsch (nicht ausreichend im Git-Log/in den ADRs
+   nachgeprüft).
+3. **Trotz vollständig aufgelöstem Preseed und korrekt gesetztem
+   `priority=critical` bleibt Ubiquitys GTK-"Automatic"-Frontend auf
+   diesem Mint-22.3-Ubiquity-Build an mehreren Seiten hängen und wartet
+   auf einen manuellen Klick.** Live beobachtet: Multimedia-Codecs-Seite
+   blieb >60s ohne jede neue Zeile in `/var/log/installer/debug`
+   (`widget found for ubiquity/use_nonfree` war die letzte Zeile) —
+   erst ein per QMP `input-send-event` simulierter Mausklick auf
+   "Continue" brachte Fortschritt. Gleiches Muster danach bei
+   "Installation type" und beim "Änderungen auf Speichergerät
+   schreiben?"-Bestätigungsdialog — jede Seite pausiert bis zum Klick,
+   obwohl die zugrunde liegenden Debconf-Werte laut Preseed bereits
+   beantwortet sind. Das deckt sich exakt mit dem realen Befund auf der
+   physischen Hardware (Zeitzone/Codecs/Überschreiben/Benutzeranlage
+   alle interaktiv) — es lag nie an einem fehlenden Preseed-Wert oder an
+   `priority=critical`, sondern daran, dass Ubiquitys automatischer
+   GTK-Modus auf diesem Fork Werte vorbelegt, aber die
+   Seitennavigation selbst nicht automatisch durchläuft.
+
+**Korrigierter Stand:** `priority=critical` bleibt eine sinnvolle, nicht
+schädliche Ergänzung, löst das eigentliche Problem aber nicht. Die
+offene Frage — GUI-Auto-Klick-Mechanismus (z. B. `xdotool`, von
+`installer.sh` nach dem kexec-Sprung gestartet) vs. Ubiquity im
+Backend-/Textmodus ohne GTK-Frontend ansteuern vs. bewusster Verzicht auf
+volle Klick-Freiheit — ist mit dem User noch zu klären, siehe
+[[project_e2e_flow_dogfooding_2026-08-28]] Fund 8.
+
+## Zweiter Nachtrag (28.08.2026): Ursache endgültig gefunden und behoben — zwei unabhängige Bugs
+
+Der Nutzer erinnerte sich korrekt, dass die kexec-Automatisierung schon
+einmal (06.08., Commit `d6a0146`) bis zum Login-Bildschirm durchgelaufen
+war. Live-Nachstellung in der QEMU-VM (frische Disk, sauberer Boot über
+"Start Linux Mint") deckte zwei komplett unabhängige, bis dahin nie
+bemerkte Bugs auf, die zusammen jede automatisierte Installation seit
+langem verhindert haben:
+
+**1. `start-kiosk.sh` hatte `/home/liveuser` hartkodiert** (`mkdir -p
+/home/liveuser/...` und der Epiphany-Profilpfad). Der tatsächliche
+Live-Benutzername auf dieser ISO ist überall `mint` (siehe
+`grub/mint-*.cfg`, `username=mint`). `/home/liveuser` existiert nicht
+und kann vom Live-User nicht angelegt werden (`/home` ist nicht
+schreibbar) — mit `set -euo pipefail` brach das Skript dort sofort mit
+"Permission denied" ab, **noch bevor** die `TUXFLOTTE_AUTO_MODE`-Prüfung
+überhaupt erreicht wurde. `installer.sh` lief dadurch nie los, `NoDisplay=true`
+im Autostart-Eintrag verschluckte den Fehler komplett lautlos — nach
+außen sah es wie ein ganz normaler, nicht-automatisierter Live-Desktop
+aus. **Fix:** `${HOME}` statt hartkodiertem Pfad.
+
+**2. `backend_launch()`s kexec-Sprung nutzte nur `automatic-ubiquity`.**
+Das lässt Casper weiterhin Ubiquitys GTK-Oberfläche starten
+(`ubiquity-dm`), die zwar alle Preseed-Werte korrekt vorbelegt, aber pro
+Seite trotzdem auf einen Klick wartet — live beobachtet: die
+Multimedia-Codecs-Seite blieb ohne Klick über 60 Sekunden unverändert
+stehen (kein neuer Eintrag in `/var/log/installer/debug`), ein per QMP
+simulierter Mausklick brachte erst Fortschritt, dasselbe Muster
+wiederholte sich bei "Installation type" und beim
+"Änderungen schreiben?"-Bestätigungsdialog. Das erklärt exakt das auf
+echter Hardware beobachtete Verhalten (Zeitzone/Codecs/Überschreiben/
+Benutzeranlage alle interaktiv trotz "automatischem" Modus) — nie ein
+fehlender Preseed-Wert, sondern eine grundsätzliche Eigenschaft von
+Ubiquitys GTK-Automatic-Modus auf diesem Codestand.
+
+**Fix:** Zusätzliches Boot-Keyword `noninteractive` im kexec-Append
+(siehe `/usr/share/ubiquity/start-ubiquity-dm`: bei diesem Keyword ruft
+Casper direkt `ubiquity noninteractive` auf, statt die GTK-Oberfläche zu
+starten). Das ist Ubiquitys eigenes, mitgeliefertes Headless-Frontend
+(`ubiquity/frontend/noninteractive.py`) — verarbeitet jede Seite mit
+`auto_process=True` rein über Debconf, ohne je ein Fenster zu zeichnen;
+`question_dialog()` ist absichtlich nicht implementiert (wirft
+`NotImplementedError`) für alles, was sich nicht aus dem Preseed
+beantworten lässt — sauberes Scheitern statt stillem Hängenbleiben.
+
+**Live-Verifikation (QEMU, frische 40-GB-Disk):**
+- Zweiter Boot nach kexec hat `noninteractive` korrekt im
+  `/proc/cmdline`.
+- `pgrep -a ubiquity` zeigt keinen laufenden GTK-`ubiquity-dm`-Prozess.
+- `/var/log/installer/debug` bestätigt den Frontend-Wechsel eindeutig
+  per Exception-Traceback: `ubiquity.frontend.noninteractive.Wizard
+  does not implement question_dialog`.
+- **Verbleibende, jetzt exakt lokalisierte Lücke:** `ubi-partman.py`
+  (Zeile 3484) stellt beim Partitionieren eine Frage, die im aktuellen
+  Preseed noch nicht beantwortet ist — welche genau, ist noch offen
+  (nächster Schritt). Das ist ein erheblicher Fortschritt gegenüber
+  vorher: statt eines unklaren, seitenübergreifenden Hängenbleibens gibt
+  es jetzt einen einzigen, exakt benannten fehlenden Preseed-Wert.
+
+Beide Fixes committed und gepusht (`backends/mint/backend.sh`,
+`live-updates/opt/tuxflotte/kiosk/start-kiosk.sh`,
+`live-updates/etc/sudoers.d/90-tuxflotte`), siehe
+[[project_e2e_flow_dogfooding_2026-08-28]] für den vollständigen
+Untersuchungsverlauf.
+
+## Nachtrag (29.08.2026): `noninteractive` verworfen, Umstieg auf
+## `automatic-ubiquity` + eigener Autoklicker, mehrere echte Bugs gefunden
+
+Die "verbleibende Lücke" oben (eine unbeantwortete Preseed-Frage in
+`ubi-partman.py`) erwies sich als der erste von mehreren Funden in einer
+langen, sehr tief gehenden Sitzung. Kurzfassung des Ergebnisses vorab:
+**`noninteractive` wurde komplett verworfen**, `automatic-ubiquity`
+(echte GTK-Oberfläche) plus ein eigener Autoklicker sind jetzt der
+Ansatz. Drei reale, unabhängige Bugs wurden gefunden und behoben. Ein
+letzter Schritt (der Klick auf "Jetzt installieren" auf der
+Partitionierungs-Übersichtsseite) ist noch nicht zuverlässig
+automatisiert - siehe "Offen" am Ende.
+
+### `noninteractive` selbst ist strukturell nicht tragfähig
+
+Iteratives Beantworten einzelner fehlender Preseed-Werte (über 30 Stück,
+per `config.dat`/`templates.dat`-Abgleich auf dem laufenden Live-System
+diagnostiziert) brachte `ubi-partman.py` immer weiter, endete aber
+zuverlässig in einer echten Endlosschleife im `choose_partition`-Zustand
+(über 100.000 Debconf-Protokollzeilen in wenigen Sekunden, kein
+Fortschritt). Ursache, per Quelltextanalyse gefunden: `choose_partition`
+ist die Frage des MANUELLEN Partitionierers; deren Bearbeitung in
+`ubi-partman.py` baut einen internen Cache auf und wartet danach auf
+einen echten GTK-Button-Klick (`ok_handler()`), der über
+`PageNoninteractive` nie kommt - `PageNoninteractive.get_autopartition_choice()`
+und verwandte Methoden sind nur Stubs (`pass`/`None`). Das ist keine
+fehlende Preseed-Zeile, sondern eine strukturelle Lücke im mitgelieferten
+Headless-Frontend selbst.
+
+**Entscheidung:** zurück zu `automatic-ubiquity` (echte GTK-Oberfläche,
+`PageGtk` - der von Ubiquity selbst produktiv genutzte, echte
+Code-Pfad), dafür ein eigener Autoklicker
+(`live-updates/opt/tuxflotte/scripts/autoclicker.sh` + systemd-Service),
+ausgelöst durch das eigene Boot-Keyword `tuxflotte-autoclick`.
+
+### Bug 1: `jq` fehlt beim automatisierten Start über den Kiosk (real blockierend)
+
+Der reale Self-Service-Auslöser (`start-kiosk.sh` im Auto-Modus:
+`exec sudo installer.sh`, kein Terminal, keine sichtbare Ausgabe) blieb
+sofort im allerersten Modul (`10_hardware.sh`) mit "Benötigtes Programm
+nicht gefunden: jq" hängen - unsichtbar, nur in `~/.xsession-errors`
+sichtbar, nicht in `journalctl` (kein systemd-Unit). Alle bisherigen
+Testläufe in dieser Untersuchung sind daran nie gescheitert, weil `jq`
+vor jedem manuellen `installer.sh`-Aufruf von Hand nachinstalliert wurde
+(bekannte, bisher bewusst zurückgestellte Lücke, siehe
+`backend_init()`-Kommentar in `backends/mint/backend.sh`) - der reale
+Kiosk-Auslöser hat diesen manuellen Schritt naturgemäß nie bekommen.
+`backend_init()` installiert `jq` zwar nach, aber erst in Modul 40
+(`40_backend.sh`) - viel zu spät für Modul 10.
+
+**Fix:** neues Modul `scripts/modules/00_preflight.sh` (lief bisher leer),
+installiert `jq` als allererstes, vor jedem anderen Modul. Live über den
+echten Kiosk-Auslöser (nicht manuell) verifiziert: `installer.sh` lief
+danach vollständig automatisch bis zum `kexec`-Sprung durch.
+
+### Bug 2: Ubiquity-GTK-Absturz in `ubi-prepare.py` (echter Ubiquity-Bug)
+
+Mit `automatic-ubiquity` stürzte der Installer auf der "Vorbereiten"-Seite
+reproduzierbar ab: `TypeError: Argument 1 does not allow None as a value`,
+in `ubi-prepare.py::enable_download_updates()`,
+`self.label_download_updates.set_label(self.controller.get_string(template))`.
+Das Argument, nicht das Widget, ist None: `get_string('ubiquity/text/label_download_updates_na')`
+liefert keinen Wert (fehlende Übersetzung/Vorlage für diesen Zustand),
+GTK akzeptiert dafür kein `None`. Preseeden von
+`ubiquity/download_updates` half nicht - der auslösende Callback
+(`plugin_set_online_state`, an einen NetworkManager-Online-Status-Wechsel
+gebunden) feuert unabhängig vom Preseed-Wert.
+
+**Fix:** gezielter Sed-Patch statt Ersatz der kompletten
+Drittanbieter-Datei, eingehängt im bestehenden
+`initrd-hooks/casper-bottom/99casperboot`-Hook (läuft bei jedem
+Casper-Boot, auch nach dem Kexec-Sprung):
+```sh
+sed -i "s/self\.controller\.get_string(template))/self.controller.get_string(template) or '')/" \
+    /root/usr/lib/ubiquity/plugins/ubi-prepare.py
+```
+Live verifiziert: derselbe Ablauf, der vorher exakt an dieser Stelle
+abstürzte, lief danach sauber weiter bis zur Partitionierungsseite.
+
+### Bug 3: `partman/choose_partition select finish` erzwingt denselben Endlosschleifen-Zustandsautomaten wie bei `noninteractive` - auch im GTK-Modus
+
+Nach Fix 1+2 lief die Installation weiter, hing aber erneut in derselben
+`choose_partition`-Endlosschleife wie beim verworfenen
+`noninteractive`-Versuch (>100.000 Debconf-Zeilen in Sekunden) - diesmal
+mit `automatic-ubiquity`. Ursache identisch zur strukturellen Analyse
+oben: das direkte Preseeden von `partman/choose_partition select finish`
+zwingt `ubi-partman.py` in den manuellen Partitionierer-Zustandsautomaten,
+unabhängig vom Frontend - der ist für einen echten, interaktiv
+aufgebauten Seitenwechsel gedacht, nicht für ein direkt vorausgefülltes
+Ergebnis ohne echten Seitenaufbau.
+
+**Fix:** die Zeile `d-i partman/choose_partition select finish` ersatzlos
+aus `preseed.tpl` entfernt. `partman-auto/method` + `expert_recipe` +
+`choose_recipe` (bereits vorhanden) genügen, um die geführte
+Partitionierung auf dem dafür vorgesehenen Weg laufen zu lassen. Live
+verifiziert: Endlosschleife verschwunden (Debug-Log-Länge sank von
+>100.000 auf ~1.700 Zeilen für denselben Ablaufabschnitt), Installer
+zeigt danach korrekt die echte Partitionierungs-Übersichtsseite mit dem
+tatsächlich konfigurierten Layout (ESP + 42-GB-ext4-Root gemäß Rezept).
+
+### Nebenfund: GRUB/isolinux-Standardeintrag "von lokaler Festplatte
+### booten" ist ABSICHTLICH so, kein Bug
+
+Während der Fehlersuche wirkte ein per QEMU/SeaBIOS beobachtetes
+Boot-Hängenbleiben zunächst wie ein Infrastrukturproblem (ausführlich
+mit Bisektion über mehrere xorriso-Neubauten eingegrenzt). Tatsächliche
+Ursache: das ISO bootet per Voreinstellung "von lokaler Festplatte" (auf
+der frischen Test-Disk naturgemäß leer/nicht bootfähig) - das ist eine
+bewusste, bereits am 01.08.2026 getroffene Sicherheitsentscheidung
+(siehe ADR-0009, Abschnitt "Bootmenü als eigentlicher Sicherheits-Gate"):
+die destruktive Installation soll nur bei aktiver Menüauswahl starten,
+nie automatisch beim bloßen Verstreichen des Countdowns. Kein Fix nötig
+- für Tests (und für Kunden) muss der Eintrag "Start Linux Mint" (bzw.
+in Produktion später ein reparierter "Tuxflotte Auto-Install"-Eintrag)
+aktiv ausgewählt werden.
+
+### Offen: automatisierter Klick auf "Jetzt installieren" noch nicht
+### zuverlässig
+
+Nach Fix 3 erreicht der Installer real die Partitionierungs-Übersichts-
+seite korrekt und wartet dort auf einen Klick auf "Jetzt installieren".
+`autoclicker.sh` (Enter-Taste an das Hauptfenster) hat auf dieser
+speziellen Seite keinen Effekt - Enter aktiviert dort einen
+Ausklapp-Pfeil eines Status-Panels ("Konfiguration der Installation wird
+überprüft ..."), nicht den Installieren-Button. Mausklick-Versuche per
+`xdotool`/QMP auf berechnete Fensterkoordinaten scheiterten an
+unzuverlässiger Fenstererkennung (mehrere überlappende X11-Fenster
+ähnlicher Größe durch Metacity-Fensterdekoration, "größtes sichtbares
+Fenster"-Heuristik traf wiederholt das falsche Fenster) - bewusst NICHT
+in den produktiven Autoklicker übernommen, um kein Risiko fehlgeleiteter
+Klicks (z. B. versehentlich eine "Formatieren?"-Checkbox) einzugehen.
+Zusätzlich wurde dabei ein eigener, unabhängiger Bug in der
+Fenstersuche gefunden und behoben: `autoclicker.sh` suchte bisher nach
+einem Fenster namens "ubiquity" - der tatsächliche Fenstertitel ("Installation
+(as superuser)") enthält dieses Wort nie, die Suche fand also nie
+etwas. Das ist jetzt korrigiert (Suche nach jedem betitelten sichtbaren
+Fenster statt nach dem Namen "ubiquity"), der eigentliche Klick-Schritt
+bleibt aber offen.
+
+**Nächster Schritt, nicht mehr in dieser Sitzung verfolgt:** vermutlich
+robusteste Lösung wäre AT-SPI (Accessibility-API) statt Pixel-/Fenster-
+Heuristik - findet Buttons über ihre Rolle ("Push Button") und ihren
+(übersetzten) Namen, unabhängig von X11-Fensterüberlappung. Nicht
+recherchiert, da Zeitrahmen dieser Sitzung erschöpft.