Guten Abend zusammen,
Diese Nachricht richtet sich vor allem an @pierre-gilles, aber jeder kann wahrscheinlich seine Meinung dazu sagen.
Da ich ein Tüftler bin, aber nicht verrückt nach der Kommandozeile, habe ich einen kleinen Vorschlag: die Möglichkeit, direkt über die Verwaltungs-Oberfläche auf die Logs von Gladys zuzugreifen. Unter EINSTELLUNGEN > SYSTEM scheint mir am passendsten.
Ist das vorstellbar?
Guten Abend @guim31, wenn es abstürzt, kannst du das nicht auf der UI-Seite einsehen und wenn Gladys normal läuft, musst du die Logs nicht anschauen.
Also sind wir irgendwo dazwischen oder es geht um Entwicklung.
Ich habe auch Angst, dass der „durchschnittliche“ Nutzer (nichts Abwertendes) Probleme meldet, die keine sind.
Das ist meine persönliche Meinung 
Ja, ich verstehe deinen Standpunkt sehr gut.
Lassen wir mal das Beispiel hier: Ich bin ein ganz normaler Nutzer, der gerne herausfinden würde, was nicht stimmt. Und ich weiß nicht mal, wie ich die Logs von Gladys einsehen kann! Haha, peinlich, ich weiß, aber so ist es nun mal.
Ich glaube nicht, dass Gladys sich in einem Entwicklungsstadium befindet, in dem man auf so etwas verzichten kann. Oder es ist einfach zu umständlich zu integrieren im Verhältnis zum erwarteten Nutzen. Und in dem Fall muss ich wohl lernen, die Logs per SSH einzusehen 
Nö, ich nutze Ubuntu 
Der Punkt wurde bereits angesprochen. Natürlich gehen die Meinungen auseinander 
Es ist nicht vorgesehen, auf die Logs vom Frontend aus zuzugreifen. Sicher, es ist eine Beta und das würde es den Early Adoptern ermöglichen, leicht Informationen zurückzumelden, aber die Position von PG damals schien mir klar zu sein. Keine Logs im Frontend. Fehler müssen behandelt und in Form einer für den Benutzer verständlichen Nachricht zurückgemeldet werden.
Unsere Rolle als Beta-Tester besteht darin, die Fehlfunktionen festzustellen und die Logs zu konsultieren, um die Informationen zurückzumelden. Die Rolle der Entwickler besteht darin, den gemeldeten Bug zu berücksichtigen und ihn zu behandeln.
Das ist zwar frustrierend, aber es ist ein Schritt, der sicherlich das Verschwinden unbehandelter Fehler begünstigt → was man sich nur für eine „kugelsichere“ Version wünschen kann.
Ja… da muss ich zugeben, dass mir nichts Besseres einfällt ^^ Ich verstehe diesen Standpunkt sehr gut 
Aber du sagst, der Punkt wurde bereits behandelt, aber ich habe nichts im Forum gefunden… Habe ich etwas übersehen oder war es woanders?
Ich weiß nicht mehr genau. Vielleicht auf Discord damals, oder vielleicht auf Slack. Keine Ahnung mehr.
Davon wurde in den letzten Jahren tatsächlich viel im Forum gesprochen Meine Meinung ist immer noch dieselbe!
Kennst du viele Produkte, die dich auffordern, die Logs zu überprüfen, wenn ein Problem auftritt?
Persönlich kenne ich keines 
Wenn dein Smartphone ein Problem hat, zeigt es dir eine klare Pop-up-Meldung an, kein schwarzes Terminal mit unverständlichen Logs.
Derzeit sind wir noch in der intensiven Entwicklung von Gladys 4, daher werden tatsächlich noch nicht alle Fehler in der UI angezeigt, und ich bitte die Entwickler, mir ihre Logs zu geben, um das Produkt zu verbessern.
Das Ziel ist, dass jeder Fehler eine Fehlermeldung in der UI hat, eine klare Fehlermeldung, die dem Benutzer sagt, was er tun muss, um sein Problem zu lösen. Jede Entwicklung wird mit diesen Anforderungen im Hinterkopf durchgeführt!
Ich hatte hier einige Richtlinien zu diesem Thema der Fehlerbehandlung in der UI geschrieben:
Ich habe gerade einen Feature-Request gestellt und wurde auf dieses Thema verwiesen.
Ich grabe es also aus 
Hier ist, was ich geschrieben habe:
Es wäre gut, wenn man in der Gladys-Oberfläche auf die Logs zugreifen könnte.
Ein Fenster, in dem man auswählen könnte, ob man alle Logs, nur die Statusmeldungen oder nur die Fehler anzeigen möchte.
Meine Position hat sich nicht geändert, siehe letzte Nachricht 
Ich bin dafür, kontextuelle Fehlermeldungen an den richtigen Stellen anzuzeigen (oder sogar den Rohfehler, wenn der Fehler unbekannt ist), aber die vollständigen Logs anzuzeigen, das ist nicht wirklich die Philosophie von Gladys.
Heute hat sich das Thema in Gladys gut weiterentwickelt, denn wir haben 2 Muster, um Fehler in der Oberfläche zu melden:
Wenn du in Gladys bist und eine Aktion « direkt » ausführst (eine Kamera hinzufügen, auf einen Button klicken, ein Tab wechseln, etc.), und es gibt einen Fehler, wird der Fehler in einem Badge blau/grün/gelb/rot je nach Schweregrad angezeigt. Klassisch!
Wenn ein Hintergrundprozess fehlschlägt, wird der Status des Hintergrundprozesses angezeigt, und die Fehlermeldung im Tab « Hintergrundprozesse » in den Einstellungen:
Beispiel eines Fehlers:
Jetzt ist dieser Tab noch nicht auf alle Hintergrundprozesse ausgeweitet, die Idee wäre, alles hinzuzufügen, was im Hintergrund läuft (Ausführung von Szenen, Start von Gladys, etc.), um leichter debuggen zu können.
Ich war bei deiner Meinung zum Thema stehengeblieben @pierre-gilles, also habe ich mich dran gemacht, die Logs per SSH zu checken
Ich habe aber eine Idee, ich weiß nicht, was sie wert ist / ob du schon mal daran gedacht hast: die Ausführung der Szenen zu überwachen.
Denn wenn man mehrere Szenen hat, die zusammen funktionieren, ist es manchmal schwierig, den Überblick zu behalten. Ein Nutzer (dessen Name mir leidlicherweise entfallen ist) schlug vor, Telegram-Nachrichten während der einzelnen Schritte der Szenen zu senden, aber das ist recht umständlich und erfordert, diese Aktionen regelmäßig zu aktivieren/deaktivieren.
Könnte es eine Art « Logs » der Szenen geben, einfach so etwas wie:
2022-12-15 12:45:55 - Auslösung der Szene LICHT AN
2022-12-15 12:56:44 - Auslösung der Szene HEIZUNG AN
2022-12-15 12:45:55 - Beendigung der Szene ÜBERWACHUNG
Ich hatte auch daran gedacht, dass auf der Seite der Szenen eine laufende Szene anders angezeigt werden könnte (Beispiel hier mit einem Rahmen drumherum):
Diese Lösung ist etwas eingeschränkter, da einige Szenen in wenigen Hundertstelsekunden ausgeführt werden ^^
Also, ich wollte deine Meinung dazu hören, bevor ich ein neues Thema / eine Funktionsanfrage eröffne.
Lies meine Nachricht oben nochmal
Siehe:
Das passiert, wenn man zu schnell liest! Ich teile also diese Idee der Szenenausführungsverfolgung
