Icons für Texte und Pages

[christian523]

Hallo zusammen,

inspiriert durch einige Visus im Thread https://knx-user-forum.de/knx-eib-fo...beispiele.html
habe ich mal versucht, Pages und Texte so zu erweitern, dass man diesen eine Art Icon (image) voranstellen kann. In der Anlage habe ich ein Beispiel eingefügt.
Es ist aktuell noch ziemlich unsauber programmiert (css-Formatierung ist direkt im js-Script, Höhe ist fix festgelegt, etc.).
Was meint Ihr, wäre das ein brauchbares Feature? Falls ja, würde ich versuchen, den css-Part noch auszugliedern und vielleicht auch noch für andere Bausteine einzubauen.

Viele Grüße
Christian

[JNK]

Ich finde die Idee nicht schlecht. Magst Du vielleicht posten, wie Du das gemacht hast? Wenns nicht zu aufwändig ist, würde ich sagen, kann man das übernehmen.

Gruss,

der Jan

[Werner V]

Hi,

würde mir auch gefallen

Was auch super wäre, wären Images statt den Buttons für Switches etc

lg Werner

[Chris M.]

habe ich mal versucht, Pages und Texte so zu erweitern, dass man diesen eine Art Icon (image) voranstellen kann. In der Anlage habe ich ein Beispiel eingefügt.

Sehr schön! An so etwas in der Art hatte ich auch mal gedacht.

Was auch super wäre, wären Images statt den Buttons für Switches etc

Gemach, gemach! Das ist ein wichtiger Punkt - aber erst mal getrennt von den Label-Icons.

In Summe bringt das aber sehr schön die grundsätzliche Problematik zum Ausdruck. Hier brauchen wir nämlich nicht nur bisschen Code, hier brauchen wir erst mal eine Architektur:

Wie sollen wir mit Icons umgehen?

Icons können vor dem Label stehen (s.o.), hinter dem Label, statt dem Label. Icons können in Buttons vor dem Text, hinter dem Text oder statt dem Text stehen. Diese Icons können alle statisch sein, oder je nach Kontext sich verändern. (z.B. Lampe An/Aus im Button)
Und wäre es nicht sogar generisch bei den Labels auf Icons zu verzichten und eher die Groups so zu pimpen, dass man damit den selben Effekt erzielt? Und wäre dann nicht sogar ganz auf das Label zu verzichten und vom User selbst als weiteres (Text-)Element in der Group einzufügen?
Wenn man den Weg per Group macht und nicht endlos klicken will, wäre das nicht etwas für die angedachten Editor-Templates?
Und sollen die Icons alle eine "volle" URL haben, oder nicht per Design vorgegeben und nur noch per Name auszuwählen (+ überschreiben per URL für spezielle)?

Das sind viele Fragen. Und vermutlich fehlen noch ein paar wichtige!

Was ich vermeiden möchte, ist dass wir hier in eine Richtung losrennen und dann erst merken dass wir den generischen Ansatz völlig übersehen haben.

=> Bitte lasst uns vorher noch etwas Brainstormen!

[christian523]

Anbei habe ich mal die geänderte Structure_pure.js Datei angefügt.
Wenn wir diese Icons mal als separate Baustelle betrachten (ohne die von Chris aufgeführten Punkte) dann könnte ich die jetzige Lösung noch für weitere Elemente einbauen und evtl. noch die zwei css-Styles herausnehmen.
Aber wir können auch warten ob wir eine allgemeingültigere Lösung finden um die anderen Punkte evtl. gleich mit zu "erschlagen".

Bzgl. der Idee mit den Groups, da habe ich noch nichts weiter gefunden. Gibt es hier schon einen Thread in dem steht, für welchen Zweck die alles eingesetzt werden sollen / können?

Viele Grüße
Christian

[JNK]

@ChrisM: sehe ich auch so, lieber jetzt einmal diskutieren, und dann nicht ständig neu machen.

Meine Meinung: icons gehören zum Design. So habe ich das im pitchblack auch gemacht, wenn auch etwas "von hinten durchs Auge" in dem ich CSS-Klassen definiert habe, die Icons als background-image darin und diese Klassen den Widgets über "stylings" zugewiesen.

Auch was die groups angeht sehe ich das so. Ich wollte mir das als nächstes mal angucken, wie man denen "colspans" beibringen kann. Aber da sollten wir vorher noch klären, wie das generell werden soll, also alle Designs auf "1/12" (wieso eigentlich 1/12?) und ein "default-colspan" definieren? Das wäre extrem einfach in dem man .colspan0 im CSS definiert und das entsprechend auf die Widgetbreite setzt und colspan0 nimmt, wenn nichts anderes vorgegeben ist), wobei das jetzt fast so ist wie bisher, nur dass es viel weniger rechenintensiv bei der Berechung der colspan-Klassen ist). Das sollten wir im anderen Thread aber weiter diskutieren.

@christian523:

Zum Code: Das CSS-Geraffel sollte auf jeden Fall aus dem js raus. Sollte aber auch kein Problem darstellen, da man das mit ".widget > img" eigentlich gut selektieren können sollte. Was mir nicht klar ist: wofür ist das <span> gut? Um 5px Abstand zu erreichen? Geht das nicht auch mit einem margin-right in ".widget >img"?

Generell: die Groups sollen Zusammengehörendes zusammenfassen. Was auch immer das ist. Meine Idealvorstellung wäre, die "label"-Elemente komplett zu entsorgen und stattdessen etwas wie "<group><text/><widget/></group>" zu haben, wo dann text das Label enthält und widget das dazugehörige widget. Das würde auch gleich das zusammenfassen z.B. mehrerer info-widgets mit gemeinsamen Label ermöglichen.

Das Problem ist dabei, dass der Editor mit den Groups nicht umgehen kann und Groups im Augenblick nur vertikal gruppieren.

Gruss,

der Jan

[Chris M.]

Meine Meinung: icons gehören zum Design. So habe ich das im pitchblack auch gemacht, wenn auch etwas "von hinten durchs Auge" in dem ich CSS-Klassen definiert habe, die Icons als background-image darin und diese Klassen den Widgets über "stylings" zugewiesen.

Grundsätzlich sehe ich das auch so. Man darf aber nicht übersehen, dass einem Design eigentlich immer ein paar Icons fehlen, die man hier genau dringend braucht => Es muss immer zusätzlich vom User bereitgestellte Icons einbindbar sein.

Auch was die groups angeht sehe ich das so. Ich wollte mir das als nächstes mal angucken, wie man denen "colspans" beibringen kann. Aber da sollten wir vorher noch klären, wie das generell werden soll, also alle Designs auf "1/12" (wieso eigentlich 1/12?) und ein "default-colspan" definieren? Das wäre extrem einfach in dem man .colspan0 im CSS definiert und das entsprechend auf die Widgetbreite setzt und colspan0 nimmt, wenn nichts anderes vorgegeben ist), wobei das jetzt fast so ist wie bisher, nur dass es viel weniger rechenintensiv bei der Berechung der colspan-Klassen ist). Das sollten wir im anderen Thread aber weiter diskutieren.

Kann man gerne wo anders diskutieren. Da kann ich nochmal die 12 erklären (-> Primfaktorzerlegung). Machst Du einen Thread auf?

Grundsätzlich mach ein group, nun, eine Gruppierung. Nicht mehr und nicht weniger.
Ob's einen extra Rahmen bekommen soll oder nicht, könnte man sogar konfigurierbar machen.

Übrigens für 2D/3D werden Groups auch wichtig sein.

Generell: die Groups sollen Zusammengehörendes zusammenfassen. Was auch immer das ist. Meine Idealvorstellung wäre, die "label"-Elemente komplett zu entsorgen und stattdessen etwas wie "<group><text/><widget/></group>" zu haben, wo dann text das Label enthält und widget das dazugehörige widget. Das würde auch gleich das zusammenfassen z.B. mehrerer info-widgets mit gemeinsamen Label ermöglichen.

Sehe ich auch so.

Das Problem ist dabei, dass der Editor mit den Groups nicht umgehen kann und Groups im Augenblick nur vertikal gruppieren.

Sobald man Groups ein Colspan beigebracht hat, sollte die Limitierung auf vertikal automatisch fallen.
Das mit dem Editor dagegen ist wichtig und muss natürlich gelöst werden.

[christian523]

Hallo,

anbei die geänderte structure_pure.js

@Jan oder Chris: wenn das Eurer Meinung nach soweit passt, könntet ihr es bitte einchecken, da ich keinen Schreibzugriff im svn habe.

In der css-Datei habe ich noch folgendes hinzugefügt (mit dem >img habe ich es nicht hinbekommen):

.widget_icon {
height: 32px;
vertical-align:middle;
margin-right: 5px;
}

Da dies ja alle Designs betrifft, wäre zu überlegen (wurde glaube ich auch in in einem andere Thread überlegt) ob man dies nicht in einer global.css-Datei einpflegt.

[JNK]

In der css-Datei habe ich noch folgendes hinzugefügt (mit dem >img habe ich es nicht hinbekommen):
[...]
Da dies ja alle Designs betrifft, wäre zu überlegen (wurde glaube ich auch in in einem andere Thread überlegt) ob man dies nicht in einer global.css-Datei einpflegt.

Es wäre ".widget > div > img" gewesen, ich hatte das div dazwischen vergessen. Aber das mit der eigenen Klasse ist genauso gut. global finde ich nicht so gut, weil die einzelnen Designs eine unterschiedliche widget-height haben und sich dadurch vielleicht auch die Grösse der Icons ändert.

@Jan oder Chris: wenn das Eurer Meinung nach soweit passt, könntet ihr es bitte einchecken, da ich keinen Schreibzugriff im svn habe.

Wenn Du einen SF-Account hast, sag einfach Deinen Namen, dann kriegst du den Schreibzugriff. Wenn Du das nicht willst, kann ich das auch machen.

Generell: So ganz gefällt mir das noch nicht. Mir wäre eine Lösung die sich für alle Widgets verwenden lässt lieber. Wir versuchen gerade möglichst viel Code zusammenzufassen (z.B. .setWidgetLayout, .makeWidgetLabel) um Fehlermöglichkeiten zu reduzieren, und das läuft wieder in die andere Richtung.

Es müsste gehen eine zentrale Funktion (.addWidgetIcon) zu machen, die mit Hilfe von this.prepend('<img class="...." src="....." />') ein Icon anfügt. Diese Funktion könnte man dann in .makeWidgetLabel auf das Label-Element, in der create-Funktion von text bzw. page dann entsprechend (ret_val.append( $('schnurz der da bis jetzt steht).addWidgetIcon($p))
In dieser Funktion kann man dann $p auswerten (so wie Du das bis jetzt auch machst).

Der Vorteil ist: Wenn wir Syntax des Attributs ändern, oder ein Element dafür einfügen statt eines Attributs, muss man es nur an einer Stelle ändern und es funktioniert gleich für alle. Und es ist genauso einfach dass dann passend in den Plugins einzubinden.

Gruss,

der Jan