RaspberryMatic - Verbesserungsvorschläge/Wünsche

[MichaelN]

Habe mir gerade den aktuellen Nightly 3.59.6.20211026 vorgeknüpft.
STartseite mit den Favoriten sieht ja wieder gut aus!

Aber Status/Systemvariable ist IMHO schlimmer geworden:

Ich bin nicht sicher, was da vorher codiert war, aber nun ist die Datumsspalte mit

Code: Alles auswählen

<col style="width:0px;">

versehen. Ich würde die style-Anweisung wie bei den anderen Spalten rauswerfen.
Dann ist die Aufteilung schon mal harmonischer:

Und wenn man dann noch den gestrigen Vorschlag

Code: Alles auswählen

word-wrap: anywhere;

statt break-word in der Eigenschaft der Klasse .CLASS02535
umsetzt, dann wird sogar noch bei schmalen Fenster skaliert:

[MichaelN]

Ich habe mir auch nochmal das Übersetzungsproblem angeschaut.
Status/Programme: Verzögerung ist immer noch da, aber es wird übersetzt
Status/Gewerke: wird nicht übersetzt, Browser ist auch nicht beschäftigt
Aber was mir aufgefallen ist:
Gewerk "Energiemanagement": keine Übersetzung

Gewerk "Umwelt": wird übersetzt - ich habe extra den gleichen Kanal da rein gepackt

EDIT: und das geht fast immer abwechselnd:
Energiem. - nein
Fenster - ja
Heizung - nein
Klima - ja
Licht - nein
Sicherheit - ja
Taster - ja
Umwelt - ja
Wetter - ja
Zentrale - ja

Ist das bei euch auch so oder ist es Zufall?

EDIT2:
2 neue Gewerke hinzugefügt: werden übersetzt
Eneergiemanagemt: alle bis auf CuxD Aussenfeuchtesensor entfernt - wird übersetzt
Eneergiemanagemt: PSM Kanal 6 hinzugefügt - wird nicht übersetzt
Eneergiemanagemt: PSM Kanal 6 entfernt; Kanal 0 hinzugefügt - wird übersetzt
Heizung: FSM Kanal 5 entfernt - wird übersetzt

also ich würde nicht ausschließen, das es nicht doch an meiner Virtualisierung liegt. Möchte den Nightly aber auch nicht auf meine Produktivumgebung loslassen

[Baxxy]

statt break-word in der Eigenschaft der Klasse .CLASS02535
umsetzt, dann wird sogar noch bei schmalen Fenster skaliert:

Sieht gut aus!

das Übersetzungsproblem

Taucht auf meinem Testsystem quasi nicht auf. Wenn ich aber ganz schnell hin und herklicke sehe ich aber ab und zu ganz kurz das Problem.

Grüße, Baxxy

[jmaus]

Ich bin nicht sicher, was da vorher codiert war, aber nun ist die Datumsspalte mit

Code: Alles auswählen

<col style="width:0px;">

versehen. Ich würde die style-Anweisung wie bei den anderen Spalten rauswerfen.
Dann ist die Aufteilung schon mal harmonischer

Ok, hab das mit dem "width:0px" wieder rausgenommen. Hoffe so passt es nun besser.

Und wenn man dann noch den gestrigen Vorschlag

Code: Alles auswählen

word-wrap: anywhere;

statt break-word in der Eigenschaft der Klasse .CLASS02535
umsetzt, dann wird sogar noch bei schmalen Fenster skaliert:

Also das hab ich gerade versucht mir noch einmal genauer anzuschauen. Also ich sehe hier keinen wirklichen unterschied ob ich "anywhere" oder "break-word" nutzen. In beiden Fällen findet der word-wrap exakt gleich statt. Zumindest kann ich im Debugger vom Browser keinerlei unterschied erkennen.

[jmaus]

das Übersetzungsproblem

Taucht auf meinem Testsystem quasi nicht auf. Wenn ich aber ganz schnell hin und herklicke sehe ich aber ab und zu ganz kurz das Problem.

Das unterstützt meine These, das das Problem nur deshalb passiert weil in den Testumgebungen meist die Geräte die man dort angelernt hat nicht erreichbar sind oder gar kein Funkmodul zur kommunikation dort existiert. Ich vermute auf einem produktivem System wird/sollte das nicht passieren.

[jp112sdl]

Ich vermute auf einem produktivem System wird/sollte das nicht passieren.

Mein Screencast und die Laufzeitanalyse war im produktiven System mit RPI-RF-MOD und erreichbaren Geräten

[MichaelN]

Also das hab ich gerade versucht mir noch einmal genauer anzuschauen. Also ich sehe hier keinen wirklichen unterschied ob ich "anywhere" oder "break-word" nutzen. In beiden Fällen findet der word-wrap exakt gleich statt.

Du merkst es dann, wenn Du eine SV mit langem Inhalt hast, der keine "natürliche" Umbruch Stelle hat und Du das Browser Fenster schmal machst. Zumindest im Firefox. Ohne anywhere bleibt die Spalte auf einer Inhalt abhängigen mindest Breite und skaliert nicht weiter.

[MichaelN]

Ich vermute auf einem produktivem System wird/sollte das nicht passieren.

Mein Screencast und die Laufzeitanalyse war im produktiven System mit RPI-RF-MOD und erreichbaren Geräten

Aber auf deinem System war die Übersetzung nur verzögert, während sie bei mir in Gewerk gar nicht stattfindet. Oder?

[jmaus]

Ich vermute auf einem produktivem System wird/sollte das nicht passieren.

Mein Screencast und die Laufzeitanalyse war im produktiven System mit RPI-RF-MOD und erreichbaren Geräten

Ok, das ist interessant und verwirft dann wohl meine These

Aber gut, das Problem mit diesen "${xxxx}" strings ist ja, das zu der Zeit wo der Browser das darstellt die "translatePage()" Funktion noch nicht durchgelaufen ist (weil ggf. noch auf weitere Daten gewartet wird). Deshalb wird auf einigen Seiten ja direkt "translateKey()" im Javascript kontext beim setzen verwendet. Das habe ich heute erst in deinem 0141 WebUI Patch wie folgt umgestellt:

https://github.com/jens-maus/RaspberryM ... 5984b18b95

Denn auch dort konnte man auf der Hauptseite bei einem full-browser reload kurzzeitig die ${xxxx} identifier sehen und dann nach einer kurzen Zeit erschienen erst die übersetzten Texte. Seit ich das jetzt auf direkte "translateKey()" aufrufe umgestellt habe passiert das auf der Startseite nicht mehr. Und meine Vermutung ist nun, das die Probleme die du und Matthias hier sehen aus der gleichen Richtung kommen. Komisch nur das ich diese bisher aber selbst nicht wahrnehmen konnte bei "Status und Bedienung"

[jp112sdl]

Aber auf deinem System war die Übersetzung nur verzögert, während sie bei mir in Gewerk gar nicht stattfindet. Oder?

Genau. Aber auch 5 Sekunden warten bis alles da ist, ist es ein Showstopper

das zu der Zeit wo der Browser das darstellt die "translatePage()" Funktion noch nicht durchgelaufen ist (weil ggf. noch auf weitere Daten gewartet wird).

Während dieser Pause verbringt der Browser seine Zeit nicht damit, auf Daten zu warten oder neu zu laden, sondern mit hunderten "Stilberechnungen".

Chrome verhält sich (bei mir) anders als der Firefox.
Es dauert zwar auch 5 Sekunden, bis der Inhalt geladen ist. Jedoch wird die Seite erst angezeigt, wenn sie vollständig ist. Bis dahin bleibt die Seite einfach weiß