Autor Thema: "Doppelte Rahmen"  (Gelesen 5460 mal)

Offline Talkabout

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 885
"Doppelte Rahmen"
« am: 11 Juli 2015, 13:56:08 »
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

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22260
Antw:"Doppelte Rahmen"
« Antwort #1 am: 12 Juli 2015, 08:42:38 »
Ich hoere interessiert zu, erstmal ohne eigene Meinung zum Thema :)

Offline Talkabout

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 885
Antw:"Doppelte Rahmen"
« Antwort #2 am: 12 Juli 2015, 10:12:11 »
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

Offline Talkabout

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 885
Antw:"Doppelte Rahmen"
« Antwort #3 am: 12 Juli 2015, 13:09:11 »
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:

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

Offline Markus Bloch

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 3649
Antw:"Doppelte Rahmen"
« Antwort #4 am: 12 Juli 2015, 13:26:21 »
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
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Offline Talkabout

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 885
Antw:"Doppelte Rahmen"
« Antwort #5 am: 12 Juli 2015, 13:46:50 »
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

Offline Markus Bloch

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 3649
Antw:"Doppelte Rahmen"
« Antwort #6 am: 12 Juli 2015, 15:15:49 »
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

Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Offline Talkabout

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 885
Antw:"Doppelte Rahmen"
« Antwort #7 am: 12 Juli 2015, 15:34:32 »
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

Offline Talkabout

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 885
Antw:"Doppelte Rahmen"
« Antwort #8 am: 12 Juli 2015, 17:02:16 »
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

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 20260
Antw:"Doppelte Rahmen"
« Antwort #9 am: 12 Juli 2015, 17:50:58 »
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
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Talkabout

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 885
Antw:"Doppelte Rahmen"
« Antwort #10 am: 12 Juli 2015, 17:56:23 »
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

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 20260
Antw:"Doppelte Rahmen"
« Antwort #11 am: 12 Juli 2015, 18:02:04 »
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
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Talkabout

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 885
Antw:"Doppelte Rahmen"
« Antwort #12 am: 12 Juli 2015, 18:14:36 »
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

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 20260
Antw:"Doppelte Rahmen"
« Antwort #13 am: 12 Juli 2015, 18:30:07 »
Zitat
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

FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Talkabout

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 885
Antw:"Doppelte Rahmen"
« Antwort #14 am: 12 Juli 2015, 18:36:46 »
(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

 

decade-submarginal