"Doppelte Rahmen"

[Talkabout]

Hallo zusammen,

ich würde gerne hier mal das Thema der "doppelten Rahmen" bei bestimmten Modulen aufgreifen, die dann zu unschönen Darstellungen in FHEMWEB (und anderen Modulen) führen. Im Anhang ein paar Beispiele dazu (ReadingsGroup, Calllist). Mir ist noch nicht ganz klar, warum der Border tatsächlich von diesen Modulen selber erstellt werden muss. Man geht ja davon aus, dass die Darstellung von FHEMWEB oder einem anderen Modul (in meinem Fall Dashboard) geregelt wird. Daher sollte dort auch dafür gesorgt werden, dass ein abgrenzender Rahmen vorhanden ist. Welchen anderen Use Case gibt es, der nicht mehr sauber funktionieren würde, wenn man den Aussen-Border tatsächlich weglässt und sich darauf verlässt, dass das Modul, welches das Device darstellt, sich darum kümmert?

Der Grund warum ich frage ist, dass wir im Dashboard Thread mittlerweilse das 3. Modul haben, welches dieses Problem aufweist (nach ReadingsGroups und Calllist nun auch Remote), und ich nur sehr ungern wieder einen CSS-Hack mache, der dann für diesen einen Fall den Border entfernt. Da das Problem ja im FHEMWEB ebenfalls auftritt, scheint es ein generelles zu sein und nicht nur auf bestimmte Fälle bezogen.

Wäre für Argumente in die eine und andere Richtung sehr dankbar!

Gruss

[rudolfkoenig]

Ich hoere interessiert zu, erstmal ohne eigene Meinung zum Thema

[Talkabout]

Hallo zusammen,

mir wäre sehr daran gelegen, wenn sich zumindest die Maintainer der oben genannten Module (readingsGroup, calllist, remote) hier zu Wort melden könnten. Ich denke, dass eine generelle Lösung des Problems (falls möglich) allen zum Vorteil gereichen wird. Vor allem aber den Benutzern, die aktuell damit in verschiedenen FHEMWEB Ansichten zu kämpfen haben.

Danke!

Gruss

[Talkabout]

Hallo zusammen,

ich habe mal etwas analysiert... Es gibt grundsätzlich 2 Punkte, die für die "schlechte" Darstellung in den verschiedenen Bereichen verantwortlich sind:

1. die CSS-Klasse "block" weisst allen Tabellen, denen sie zugewiesen ist, einen Border zu. Meiner Ansicht nach ist dies aber in den einzelnen Modulen nicht notwendig, daher sollte diese Klasse aus allen Tabellen raus Es reicht, wenn FHEMWEB selber diese Klasse verwendet. Die Klasse "wide" sorgt eh schon dafür, dass die Tabelle 100% Breite erhält. Diese Klasse sollte man allen Tabellen zuweisen bei denen man möchte, dass sie den komplett verfügbaren Platz einnehmen.
2. Ohne den Border ist das Padding der verschachtelten Tabellen zu groß. Um das zu beheben kann und sollte man allen Tabellen, die sich in einer anderen Tabelle befinden, ein "border-spacing: 0px;" verpassen. Das ginge in den globalen Styles z.b. damit:

Code Auswählen Erweitern

table table {
  border-spacing: 0px;
}

Damit sieht das Ganze dann zumindest schon mal annehmbar aus. Weitere Detailpunkte müssen dann pro Style gemacht werden.

Ich habe für die Analyse das "readingsGroup"-Modul verwendet, wo mir auch aufgefallen ist, dass dort die Container-Tabelle keine Breite hat. Hier würde ich vorschlagen (wie oben schon geschrieben) auch dieser Tabelle (an 2 Stellen) die Klasse "wide" zuzuweisen. Dann sehen die ReadingsGroups auch im Default-Style gut aus.

Was haltet Ihr davon?

Gruss

[Markus Bloch]

Hallo zusammen,

ich bin der Meinung, dass man hier unterscheiden muss, ob man eine Calllist/readingsGroup in der normalen FHEMWEB Standard-Oberfläche in eine group packt oder nicht. Deine Bilder zeigen ja deine Definitionen die in eine bestimmte group gepackt sind. Wenn in dieser group nur diese eine Definition vorhanden ist, dann sieht das in der Tat nicht stimmig aus, wobei ich mich dann frage, wozu die Gruppierung in diesem Fall nützlich sein soll? Sobald in der Gruppe aber noch mehr Definitionen vorhanden sind, dann ist dieser Rahmen innerhalb der Gruppe notwendig. Auch ohne Gruppe ist der Rahmen notwendig.

Genau aufgrund des doppelten Rahmens wurde atPageEnd in der Initialize-Routine gesetzt, da sonst solche Modul-Tabellen an der selben Stelle wie die devState-Ausgabe angezeigt werden und das noch beschissener aussehen würde.

Viele Grüße

Markus

[Talkabout]

Hallo Markus,

ich muss ehrlich gestehen, dass ich Deine Ausführung nicht ganz umrissen habe. Es kann aber sein, dass das an meiner fehlenden Erfahrung mit FHEM liegt.

Gehen wir mal von einem ganz einfachen Beispiel aus:

Ich habe 3 Lichtschalter, die ich in eine Gruppe stecke. Das Ergebnis im FHEM Frontend wie auch in Modulen wie readingsGroups ist, dass diese untereinander gelistet werden, ohne Border.

ein etwas komplexeres Beispiel:

ich nehme meine 3 Lichtschalter und packe sie in eine Gruppe mit 3 anderen Lichtschaltern. Ergebnis im FHEM Frontend und auch in Modulen wie readingsGroups ist, dass diese untereinander gelistet werden, ohne Border.

weiteres Beispiel:

wir nehmen nun eine ReadingsGroup, die genau eine Zeile hat. Im FHEM Frontend und auch anderen Modulen haben wir nun eine Gruppe mit doppeltem Border drin => nicht schön

nächstes Beispiel:

wir nehmen nun eine ReadingsGroup, die mehrere Zeilen hat. Im FHEM Frontend und auch anderen Modulen haben wir nun eine Gruppe mit doppeltem Border drin => nicht schön

nächstes Beispiel:

wir nehmen eine readingsGroup mit mehreren Zeilen und unsere 3 Lichtschalter aus dem 1. Beispiel. Ergebnis ist, dass wir nun eine Gruppe haben, die eine ReadingsGroup mit Border hat und dann noch 3 weitere Zeilen mit den Schaltern => nicht schön.

nächstes Beispiel:

wir nehmen mal 2 ReadingsGroups. Aktuell würden beiden einen Border bekommen, was auch nicht schön ist.

das einzige Beispiel, wo es zumindest noch nicht ganz so schlimm aussieht ist, wenn die ReadingsGroup einen Titel hat. Wobei auch dann das Ganze ohne Border annehmbar aussehen würde.

Mir ist also immer noch nicht ganz klar, in welchem Fall der Border notwendig ist, kannst Du mir da auf die Sprünge helfen?

Danke!

Gruss

[Markus Bloch]

Ich habe 3 Lichtschalter, die ich in eine Gruppe stecke. Das Ergebnis im FHEM Frontend wie auch in Modulen wie readingsGroups ist, dass diese untereinander gelistet werden, ohne Border.

Richtig, hier sind alle Devices von der Border der Gruppe umgeben. Passt.

ein etwas komplexeres Beispiel:

ich nehme meine 3 Lichtschalter und packe sie in eine Gruppe mit 3 anderen Lichtschaltern. Ergebnis im FHEM Frontend und auch in Modulen wie readingsGroups ist, dass diese untereinander gelistet werden, ohne Border.

Genau das selbe wie oben, es greift der Border der Gruppe.

weiteres Beispiel:

wir nehmen nun eine ReadingsGroup, die genau eine Zeile hat. Im FHEM Frontend und auch anderen Modulen haben wir nun eine Gruppe mit doppeltem Border drin => nicht schön

Da stimme ich dir zu. Eine Möglichkeit wäre, zu erkennen, ob die readingsGroup-Definition die einzigste in der Gruppe ist um dann den Border wegzulassen. Halte ich aber für nicht praktikabel.´Hierbei stellt sich mir aber auch die Frage, wozu packt man eine einzelne Definition in eine Gruppe rein?

nächstes Beispiel:

wir nehmen nun eine ReadingsGroup, die mehrere Zeilen hat. Im FHEM Frontend und auch anderen Modulen haben wir nun eine Gruppe mit doppeltem Border drin => nicht schön

siehe Kommentar zum vorherigen Beispiel.

nächstes Beispiel:

wir nehmen eine readingsGroup mit mehreren Zeilen und unsere 3 Lichtschalter aus dem 1. Beispiel. Ergebnis ist, dass wir nun eine Gruppe haben, die eine ReadingsGroup mit Border hat und dann noch 3 weitere Zeilen mit den Schaltern => nicht schön.

Nunja, du hast in diesem Fall eine Gruppe aus einzelnen schaltbaren Definitionen und einer Tabelle. Wenn du die Tabelle ohne Rahmen darstellst sieht das genauso unschön aus, wie ein fehlender Rahmen um die gesamte Gruppe. Wie würdest du dir diese Konstellation optisch vorstellen?

nächstes Beispiel:

wir nehmen mal 2 ReadingsGroups. Aktuell würden beiden einen Border bekommen, was auch nicht schön ist.

Wie willst du die sonst abgrenzen? Was ist dein Gegenvorschlag?

Gruß
Markus

[Talkabout]

Richtig, hier sind alle Devices von der Border der Gruppe umgeben. Passt.
Genau das selbe wie oben, es greift der Border der Gruppe.

Da stimme ich dir zu. Eine Möglichkeit wäre, zu erkennen, ob die readingsGroup-Definition die einzigste in der Gruppe ist um dann den Border wegzulassen. Halte ich aber für nicht praktikabel.´Hierbei stellt sich mir aber auch die Frage, wozu packt man eine einzelne Definition in eine Gruppe rein?
siehe Kommentar zum vorherigen Beispiel.

Nunja, du hast in diesem Fall eine Gruppe aus einzelnen schaltbaren Definitionen und einer Tabelle. Wenn du die Tabelle ohne Rahmen darstellst sieht das genauso unschön aus, wie ein fehlender Rahmen um die gesamte Gruppe. Wie würdest du dir diese Konstellation optisch vorstellen?

Wie willst du die sonst abgrenzen? Was ist dein Gegenvorschlag?

Gruß
Markus

Hallo Markus,

ich antworte darauf mal gesammelt. Ich halte den Weg über die Erkennung von Kontext oder Zahl der Einträge ebenfalls für nicht praktikabel, würde ich, wenn möglich, vermeiden wollen.

Zu Deiner Frage nach meinem Vorschlag für die Darstellung:

Ich persönlich halte es für "hübscher", wenn der Border in keinem der oben genannten Fälle angezeigt wird. Ich empfinde die Abgrenzung zu den anderen Elementen nicht unbedingt als notwendig. Das ist aber nur meine subjektive Meinung. Schaut man sich aber die Darstellung von Geräten im FHEMWEB an, ist der doppelte Border einfach "unnatürlich", da sonst nirgends vorhanden.

Zu Deiner Frage "Hierbei stellt sich mir aber auch die Frage, wozu packt man eine einzelne Definition in eine Gruppe rein?":

Schau Dir bitte noch mal meine Screenshots an. Dort siehst Du das Gerät "Fritzbox". Diese ReadingsGroup beinhaltet nicht nur eine Definition, sondern insgesamt 6 einzelne Readings, die separat definiert wurden. Für Dich sieht dies nach nur einer Definition aus, weil alle diese Elemente sich in einer Zeile befinden. Allgemein ist die Darstellung von nur einer Zeile aber nicht unbedingt etwas Aussergewöhnliches. Es kann durchaus sein, dass mich für meine Übersicht genau nur 1 Reading eines Gerätes interessiert, warum sollte ich dieses dann nicht in eine ReadingsGroup mit schönen Icons packen?

Gruss

[Talkabout]

Hallo zusammen,

zur Trennung ist mir vielleicht noch eine Idee gekommen: Wenn man davon ausgeht, dass sowohl das Modul readingsGroup wie auch calllist ein Attribut haben "noheading"/"no-heading", könnte man den Border auch daran festmachen. Mit heading=border noheading=no border.

Gruss

[justme1968]

ich denke das eigentliche problem kommt daher das readingsGroup und Calllist sowohl einzeln d.h. als eigenständiges device in der raum ansicht sowie in der device detail ansicht aussehen sollen wie die anderen devices auf der gleichen seite. d.h. sie sollten im dark style z.b. so aussehen wie die automatisch gruppierten devices.

die rahmen werden unterm strich nicht wirklich vom jeweiligen modul erzeugt sondern das modul sagt ich sehe so aus wie das top level element auf der normalen raum übersicht. wie dieses element aussieht hängt vom jeweiligen style ab. wenn es um dieses element noch etwas drum rum gibt wie z.b. das dashboard oder eine fhem group dann sollte das dem modul komplett egal sein und dieses übergeordnete element sollte dafür sorgen das per css das styling passt.

doppelte rahmen entstehen wenn man diese module in eine fhem group oder ins dashboard steckt da hier der übergeordnete kontainer ebenfalls einen rahmen zeichnet.

über den floorplan kann man streiten. ich habe hier bei den meisten readingGroups den rahmen aktiv. manchmal schalte ich ihn per css ab.

ein attribut dafür zu nehmen finde ich falsch. attribute sind für endanwender. zumal die gleiche readingsGroup ja an unterschiedlichen stellen dynamisch anders aussehen muss.

ich würde die css lösung nicht als hack ansehen sondern eigentlich ist das genau der anwengunsfall für css. über die hierarchie der verschachtelung kann man nur das jeweils äussere element mit rahmen versehen und die inneren nicht. ob überhaupt rahmen gezeigt werden hängt ja auch ganz allgemein vom style ab. manche styles verwenden gar keine sichtbaren rahmen.

das problem ist vielleicht eher das nicht ganz genau definiert ist welche css klassen es gibt und wie sie verwendet werden sollten.

gruss
  andre

[Talkabout]

ich denke das eigentliche problem kommt daher das readingsGroup und Calllist sowohl einzeln d.h. als eigenständiges device in der raum ansicht sowie in der device detail ansicht aussehen sollen wie die anderen devices auf der gleichen seite. d.h. sie sollten im dark style z.b. so aussehen wie die automatisch gruppierten devices.

die rahmen werden unterm strich nicht wirklich vom jeweiligen modul erzeugt sondern das modul sagt ich sehe so aus wie das top level element auf der normalen raum übersicht. wie dieses element aussieht hängt vom jeweiligen style ab. wenn es um dieses element noch etwas drum rum gibt wie z.b. das dashboard oder eine fhem group dann sollte das dem modul komplett egal sein und dieses übergeordnete element sollte dafür sorgen das per css das styling passt.

doppelte rahmen entstehen wenn man diese module in eine fhem group oder ins dashboard steckt da hier der übergeordnete kontainer ebenfalls einen rahmen zeichnet.

über den floorplan kann man streiten. ich habe hier bei den meisten readingGroups den rahmen aktiv. manchmal schalte ich ihn per css ab.

ein attribut dafür zu nehmen finde ich falsch. attribute sind für endanwender. zumal die gleiche readingsGroup ja an unterschiedlichen stellen dynamisch anders aussehen muss.

ich würde die css lösung nicht als hack ansehen sondern eigentlich ist das genau der anwengunsfall für css. über die hierarchie der verschachtelung kann man nur das jeweils äussere element mit rahmen versehen und die inneren nicht. ob überhaupt rahmen gezeigt werden hängt ja auch ganz allgemein vom style ab. manche styles verwenden gar keine sichtbaren rahmen.

das problem ist vielleicht eher das nicht ganz genau definiert ist welche css klassen es gibt und wie sie verwendet werden sollten.

gruss
  andre

Hallo Andre,

der Argumentation kann ich leider nicht ganz zustimmen. Schauen wir uns noch mal den einfachsten Fall an. Eine ReadingsGroup wird definiert und man öffnet die Raumansicht. Selbst dort ist der doppelte Rahmen da. Soweit mir bekannt ist gibt es keinen Fall, wo es kein übergeordnetes Element mit Rahmen gibt. Wenn also bereits da das Problem besteht und der Border überflüssig ist, dann sollte er in allen anderen Fällen ebenfalls nicht notwendig sein. Es sei denn Du kannst mir ein Beispiel nennen (am besten in FHEMWEB und nicht in einem Modul), wo der Border zwingend gebraucht wird.

Gruss

[justme1968]

nein. eben nicht. eine einzelne readingsGroup in der raum ansicht hat keinen doppelten rahmen.

alle atEnd devices sind in der raum ansicht komplett selber für ihr aussehen zuständig. hier werden keine rahmen eingefügt wenn das device nicht selber einen vorsieht. siehe SVG. es hat keinen rahmen. readingsGroup hätte auch keinen wenn sie nicht die entsprechende class für die table setzen würde.

gruss
  andre

[Talkabout]

nein. eben nicht. eine einzelne readingsGroup in der raum ansicht hat keinen doppelten rahmen.

alle atEnd devices sind in der raum ansicht komplett selber für ihr aussehen zuständig. hier werden keine rahmen eingefügt wenn das device nicht selber einen vorsieht. siehe SVG. es hat keinen rahmen. readingsGroup hätte auch keinen wenn sie nicht die entsprechende class für die table setzen würde.

gruss
  andre

Ja, genau, Du sagst es. Oben schreibst Du ja

"die rahmen werden unterm strich nicht wirklich vom jeweiligen modul erzeugt sondern das modul sagt ich sehe so aus wie das top level element auf der normalen raum übersicht"

und jetzt, dass

"readingsGroup hätte auch keinen wenn sie nicht die entsprechende class für die table setzen würde"

warum muss denn das Modul genau diese class setzen? Ich hatte ja oben mal geschrieben, dass man immer davon ausgehen kann, dass der Inhalt eines Moduls sich in einem parent-Element befindet, welches einen Rahmen hat. Meiner Ansicht nach sollten die Module auf die Klasse "block" verzichten, damit dieser unschöne Border nicht kommt. Ich habe immer noch kein Argument gehört, warum z.b. eine ReadingsGroup unbedingt diesen Rahmen braucht. Wenn es so ein Argument gibt, kann man sich ja überlegen ob dies tatsächlich unumgänglich ist oder ob man sich nicht leichter damit tut, die Border wegzulassen und die Ansicht bestimmten zu lassen, was aussen rum gezeigt wird.

Die Idee mit dem Attribut war eigentlich so gedacht, dass wenn ein Benutzer den Titel haben möchte, dann möchte er auch eine gewisse Abgrenzung haben, daher würde der Border dann angezeigt werden. Wählt der Benutzer keinen Titel anzuzeigen, ist die Anzeige "integriert", dann kann auch der Border weg.

Gruss

[justme1968]

warum muss denn das Modul genau diese class setzen?

aus genau dem unterschied den es z.b. zwischen readingsGroup und SVG gibt. die readingGroups soll einen rahmen haben damit sie wie ein 'normales' device aussehen, SVGs aber nicht weil der 'rahmen' weiter innen um den jeweiligen plot bereich ist und nicht um alles inklusive achsen und + - button. dann wären hier doppelte rahmen.

(zur zeit) kann man nicht davon ausgehen das das parent element den rahmen immer zeichnet. wenn man das einbaut dann müsste man umgekehrt dafür sorgen das es für SVG (und weblink) möglich ist diesen rahmen auch wieder zu deaktivieren.

gruss
  andre

[Talkabout]

(zur zeit) kann man nicht davon ausgehen das das parent element den rahmen immer zeichnet. wenn man das einbaut dann müsste man umgekehrt dafür sorgen das es für SVG (und weblink) möglich ist diesen rahmen auch wieder zu deaktivieren.

Kannst Du einen Fall benennen, wo es ein parent-Element ohne Rahmen gibt? Ich habe diesen Fall bisher nicht gesehen, was aber nicht viel heissen muss.

Das Vorgehen, den Rahmen (und alles andere) modul-(und style)-spezifisch für die verschiedenen Devices auszublenden, finde ich an dieser Stelle nicht richtig. Wie man am Beispiel des Dashboards sieht, muss man für jeden Sonderfall wieder ein eigenes Süppchen kochen. Die Tatsache, dass dies auch in der Raumansicht problematisch ist, verstärkt meine Einschätzung noch. Da es mit SVGs funktioniert kann ich mir einfach nicht vorstellen, dass das mit anderen Modulen nicht gehen sollte. Aber ich lasse mich gerne eines Besseren belehren.

Gruss

[Talkabout]

Noch ein ergänzender Kommentar von mir:

Eine Lampe ist ebenfalls ein eigenständiges Device, sie hat aber keinen eigenen Rahmen in der Raumansicht...

Gruss

[justme1968]

ich glaube wir reden gerade aneinander vorbei

meine beschreibung oben ist der ist zustand. deine der soll zustand.

der fall ist genau SVG (und eventuell weblink) hier wird vom übergeordneten modul kein rahmen gezeichnet und man müsste bei einer umstellung hier einen sonderfall einbauen damit das so bleibt.

als readingsGroup neu war gab es eine ähnliche diskussion schon mal. damals war readingGroup das einzige modul das es betroffen hat und es gab noch kein dashboard. es wäre also darum gegangen ob readingGroup die ausnahme ist oder SVG. da es SVG schon gab wurde readingsGroup zur ausnahme.

wenn man das jetzt ändert weil es inzwischen mehr module mit dem gleichen potentiellen problem gibt wäre der fall genau umgekehrt.

vielleicht gehört zur 'richtigen' lösung aber auch das atEnd anders zu lösen und hier mehr als eine kategorie einzuführen so das die semantik eines Elements besser beschrieben wird. das würde eventuell auch das problem mit den fehlenden labeln bei den SVGs in einer fhem group lösen über das immer wieder jemand stolpert.

die von dir angesprochenen module würden dann nicht mehr atEnd verwenden um zum ausdruck zu bringen das sie mehr als nur ein device icon anzeigen sondern statt dessen etwas wie isHtml. damit könnte man sie dann auch über sortBy zwischen die anderen devices sortieren. das geht zur zeit ja auch nicht und wurde schon ein paar mal angefragt.

LightScene ist noch ein kandidat den das betreffen würde.

gruss
  andre

ps: ist es wirklich ein süppchen für jeden sonderfall? reicht es nicht in 99% der fälle per css den jeweils bei block in block im inneren block den rahmen auszuschalten und den margin auf 0 zu setzen?

pps: was mir noch einfällt: wenn man das parent element den rahmen zeichnen lässt braucht man eine lösung für readingsGroups die so wie auf dem bild hier: http://forum.fhem.de/index.php/topic,27353.msg228670.html#msg228670 aussehen. hier soll der balken der jeweiligen überschrift ohne lücke bis zum umgebenden rahmen gehen.

ps: warum braucht es für jedes modul ein eigenes süppchen? reicht es nicht grundsätzlich

[Talkabout]

Hallo Andre,

ich habe mal aus der Raumansicht ein SVG angehängt, wo der äußere Rahmen da ist, es aber keinen inneren Rahmen gibt. So sollte meiner Ansicht nach auch eine ReadingsGroup aussehen. Für die SVGs würde sich ja gar nichts ändern, da diese sowieso keinen Rahmen haben. Meine Änderung würde sich auf die Module beziehen, indem diese aus ihren Tabellen die Klasse "block" entfernen. Dies hätte keine Seiteneffekte auf die Standard-Komponenten.

Hast Du ein Beispiel für mich, wo die ReadingsGroup mit dem aktuellen Style keinen doppelten Rahmen hat?

Gruss

[justme1968]

ich kenne keinen fall bei dem eine readingGroup in der normalen raum ansicht einen doppelten rahmen hat.

batteriestatus und RSSI in der untern hälfte sind readingsGroups, alles darüber sind normale devices und beides schaut gleich aus. ohne doppelten rahmen.

auf dem zweiten screenshot ist systemstatus eine readingGroup. wenn man hier ohne ausnahme das verhalten ändert hätten die SVG einen rahmen der da nicht hin gehört.

gruss
  andre

[Talkabout]

ich kenne keinen fall bei dem eine readingGroup in der normalen raum ansicht einen doppelten rahmen hat.

batteriestatus und RSSI in der untern hälfte sind readingsGroups, alles darüber sind normale devices und beides schaut gleich aus. ohne doppelten rahmen.

auf dem zweiten screenshot ist systemstatus eine readingGroup. wenn man hier ohne ausnahme das verhalten ändert hätten die SVG einen rahmen der da nicht hin gehört.

gruss
  andre

Das ist sehr interessant. Verwendest Du das Standard-Style? Warum gibt es bei Dir keinen doppelten Rahmen bei allen anderen Leuten aber schon, wenn sie die ReadingsGroups verwenden. Was ist an Deinen Definitionen anders?

Gruss

[justme1968]

mit standard und dark gibt es keine doppelten rahmen (mit ios7 gibt es natürlich gar keine rahmen).

ich wüsste auch nicht woher der doppelte rahmen kommen sollte. jedenfalls nicht solange die readingGroup nicht in einer fhem group steckt.

gruss
  andre

[Talkabout]

mit standard und dark gibt es keine doppelten rahmen (mit ios7 gibt es natürlich gar keine rahmen).

ich wüsste auch nicht woher der doppelte rahmen kommen sollte. jedenfalls nicht solange die readingGroup nicht in einer fhem group steckt.

gruss
  andre

Ah, jetzt kommen wir der Sache schon näher, danke! Das bedeutet, dass das Problem bei einer FHEM Gruppe ist, dass aussen rum ein Border gebaut wird und damit alles innerhalb doppelt dargestellt wird. Verstehe... Ich schaue dann mal, ob wir es nicht doch mit CSS hinkriegen.

Gruss

[Talkabout]

Hallo zusammen,

hier habe ich mögliche Lösungen für ein paar der Styles:

ios6touchpadstyle:

Code Auswählen Erweitern

table.block table {
  border: none !important;
  margin: 0px !important;
  padding: 0px !important;
  box-shadow: none !important;
  border-spacing: 0px;
}

table.block table.block td:first-child {
  padding-left: 0px;
}

darkstyle

Code Auswählen Erweitern

table.block table {
  border-spacing: 0px;
  padding-bottom: 0px;
  padding-top: 0px;
  border: none;
  box-shadow: none;
  width: 100%;
  border-radius: 0px;
}

table.block table td {
  padding-left: 0px;
  padding-right: 0px;
}

default

Code Auswählen Erweitern

table.block table {
  border-spacing: 0px;
  border: none;
  width: 100%;
  border-radius: 0px;
}

table.block table td {
  padding-left: 0px;
  padding-right: 0px;
}

Beim default und darkstyle ist das Problem, dass die Zeilenfärbung nicht komplett durchgeht, aber das ist über CSS nicht machbar. Trotzdem würde das besser aussehen, als die bisherige Darstellung. Was haltet Ihr davon?

Gruss

[Markus Bloch]

Kannst du mal bitte ein screenshot zur Verfügung stellen, wie das bei dir aussieht?

Danke
Gruß
Markus

[Talkabout]

Kannst du mal bitte ein screenshot zur Verfügung stellen, wie das bei dir aussieht?

Danke
Gruß
Markus

Mache ich gerne, siehe Anhang.

Gruss

[Markus Bloch]

Und wenn du weitere Geräte in der Gruppe mit drin hast, dann sieht man doch keine Unterscheidung mehr, wo die Tabelle der readingsGroup/Calllist anfängt?

[Talkabout]

Und wenn du weitere Geräte in der Gruppe mit drin hast, dann sieht man doch keine Unterscheidung mehr, wo die Tabelle der readingsGroup/Calllist anfängt?

Ist richtig, das würde man nicht sehen. Wobei ich bei mir diesen Fall bisher nicht hatte. Hast Du so einen Fall?

Gruss

[rudolfkoenig]

Wenn ich irgendetwas einchecken soll, bitte klar sagen.

[Talkabout]

Wenn ich irgendetwas einchecken soll, bitte klar sagen.

Ich hatte gehofft, dass die hier im Thread beteiligten sich die Änderungen mal anschauen und ausprobieren. Es ist nicht sinnvoll das Ganze ohne irgend einen Test einzuchecken, da es vermutlich zu Seiteneffekten führen würde und damit zu Missmut bei unseren Benutzern. Die Lösung mit CSS ist wohl die "ungefährlichste", und vielleicht erreichen wir damit zumindest einen Stand, mit dem die Benutzer leben können, ohne dass wir die Module "verbiegen" müssen.

Ich würde gerne warten bis ein OK von mindestens 2 Entwicklern kommt. Wenn es nicht kommt, ist das Problem wohl nicht so wichtig...

Gruss

[Markus Bloch]

Hallo zusammen,

ich komme leider zeitlich in den nächsten Wochen nicht dazu das ganze ordentlich auszutesten. Soweit ich das sehe würden mehrer ReadingGroups in einer Gruppe damit nicht unterscheidbar sein, da ja hier ein Rahmen oder zumindest eine Trennlinie fehlt, ist das richtig?

Gruß
Markus

[Talkabout]

Hallo zusammen,

ich komme leider zeitlich in den nächsten Wochen nicht dazu das ganze ordentlich auszutesten. Soweit ich das sehe würden mehrer ReadingGroups in einer Gruppe damit nicht unterscheidbar sein, da ja hier ein Rahmen oder zumindest eine Trennlinie fehlt, ist das richtig?

Gruß
Markus

Hallo Markus,

das ist richtig. Der Rahmen erscheint nur dann, wenn die ReadingsGroup sich nicht in einer FHEM Gruppe befindet.

Gruss

[justme1968]

vielleicht wäre es hilfreich sich für die unterschiedlichen styles zu überlegen wie es in den unterschiedlichen kombinationen aussehen aussehen könnte.

bei mehreren readingsGroups könnte man z.b. eine trennlinie einblenden.

gruß
  andre

[Talkabout]

vielleicht wäre es hilfreich sich für die unterschiedlichen styles zu überlegen wie es in den unterschiedlichen kombinationen aussehen aussehen könnte.

bei mehreren readingsGroups könnte man z.b. eine trennlinie einblenden.

gruß
  andre

Theoretisch ja, praktisch ist es deswegen schwierig, weil ja die Trennlinie nur erscheinen sollte, wenn es nicht das erste Element ist usw. Wenn man eine Trennung haben möchte, kann man das über den Titel erreichen. Oder wir machen das top/bottom-Padding größer.

Gruss