Neues Feature: colspan/rowspan

[JNK]

zu groups und Zwei-Spalten-Designs:

ich hab gerade einen Commit gemacht, mit dem das gefixt sein sollte, bitte testen (bisher nur im pure-Design).

Ausserdem: Innerhalb der Gruppen kann colspan auch benutzt werden.

Gruss,

der Jan

[JNK]

Ich gucks mir an, aber vor morgen schaffe ich das nicht

[ZeitlerW]

Problem mit [group]

Hallo Jan,

So, colspan ist committed. Das kann man dann relativ einfach auch auf 1/12, 1/6, 1/3 usw ändern, wenn mal mehr Browser calc() gelernt haben.

Ich habe hier: https://knx-user-forum.de/cometvisu/...tml#post210072 ein Problem mit [group] gepostet.
...sorry falscher thread

Vielleicht kannst Du mal einen Blick drauf werfen

vG
Wolfgang

[Sandman60]

Hi Jan,
danke! Habe eben die erste Page unter discreet_slim umgebaut mit colspan und muß sagen: KLASSE! Läuft bestens! Danke!
Habe auch etwas mit Pitchblack gespielt, allerdings ist mir im Moment nicht ganz klar, wie ich meine bisherigen Seiten (hauptsächlich toggle mit label) umbauen muß, da aktuell nur die Status angezeigt werden, die Labels aber nicht mehr sichtbar bin. Laut Readme soll Label durch Info ersetzt werden???

P.S.: Habe manuell die Pitchblack in die structure_custom.js eingetragen, damit die Designauswahl via Button funktioniert. Evtl. eine Änderung für das SVN?
Viele Grüße,
Oliver

[JNK]

So, colspan ist committed. Das kann man dann relativ einfach auch auf 1/12, 1/6, 1/3 usw ändern, wenn mal mehr Browser calc() gelernt haben.

Gruss,

der Jan

[JNK]

calc():

Ich weiss wieder, warum ich das aussortiert hatte. Nur -moz-calc und calc im IE funktionieren. -webkit-calc ist zwar progarmmiert, wird gegenwärtig aber von keinem der Webkit-Browser unterstützt und -o-calc ist wohl nicht mal ansatzweise in Arbeit http://caniuse.com/calc.

Gruss,

der Jan

Edit: aber im Prinzip ist das total super und funktioniert im Mozilla auch ganz gut.
Edit2: Das würde dann auch mit width: calc(1 / 12 * 100%) funktionieren.....

[JNK]

Ob diese Prozentzahlen die beste Lösung sind, ist mir nicht klar - das ist aber auch egal. Das mit den Klassen ist erst mal das wichtigere, die konkrete Implementierung kann man dass immer noch rückwärtskompatibel optimieren.

Die ergeben sich einfach aus den 12 Spalten und sind am nächsten an column*1/12 dran. Soll ich das dann so implementieren?

Die richtige Lösung sind die rechnenden CSS-Größen, die für genau so einen Fall eingeführt werden (-> calc())

Ich gucks mir mal an. Das hatte ich wieder verdrängt.

Gruss,

der Jan

[Chris M.]

Der Vollständigkeit halber, warum gerade 12:
Wenn ich 12 Spalten definiere, kann ich die Bildschirm-Bereite auf 1,2,3,4,6 oder gar 12 Widgets aufteilen. Die nächste spannende Zahl wäre 60, damit würde auch noch 5 gehen - aber 60 ist meist schon zu groß und unhandlich.

So, hier nochmal zusammengefasst mein Vorschlag für colspan/rowspan:

colspan:

1) In allen Designs werden folgende Klassen definiert:

.colspan1 { width : 8.33333 %}
.colspan2 { width : 8.33333 %}
...
.colspan12 { width : 99.99996 %}

Ob diese Prozentzahlen die beste Lösung sind, ist mir nicht klar - das ist aber auch egal. Das mit den Klassen ist erst mal das wichtigere, die konkrete Implementierung kann man dass immer noch rückwärtskompatibel optimieren.

In den CSS verwenden wir dann px und em lustig durcheinander, und wieviele px am Ende ein line-height: 2em + 0.3em padding + 0.3em margin + 1px border sind weiss man einfach nicht, d.h. wir können gegenwärtig nicht sagen ".rowspan1" hat eine height von x em oder y px.

Nö, das ist nicht lustig, das ist Absicht (bei pure, andere dürfen's ja machen wie sie wollen).

Da wir für ein Touch-Interface schreiben, gibt es ein paar relevante Größen:

• Pixel - um z.B. die Breite von Rahmen exakt angeben zu können. 1px ist damit quasi auch eine Abkürzung für minimal-aber-sichtbar
• mm - da die Fingergröße absolut ist
• em - eine etwas näher an der tatsächlichen Widget-Größe orientierte Einheit

Die richtige Lösung sind die rechnenden CSS-Größen, die für genau so einen Fall eingeführt werden (-> calc())

[JNK]

So, hier nochmal zusammengefasst mein Vorschlag für colspan/rowspan:

colspan:

1) In allen Designs werden folgende Klassen definiert:

.colspan1 { width : 8.33333 %}
.colspan2 { width : 8.33333 %}
...
.colspan12 { width : 99.99996 %}

Es ist wichtig, dass es 99.99996 % sind, weil sonst 12 .colspan1 möglicherweise nicht die gleiche Breite haben wie ein .colspan12. Möglicherweise können wir das in eine global.css einbauen, weil alle das brauchen und die passend in index.html miteinbinden.

2) Geändert wird in allen basic.css

.widget_container { }

d.h. width:xx% entfällt. Die Klasse sollten wir beibehalten, weil wir sie für .widget_container .widget_container benötigen. und wer weiss wofür in Zukunft noch. Das tut auch nicht weh.

3) Jedes Design definiert

.colspan0 {width: xx%;}

wobei xx% der "default-Breite" eines Widgets entspricht. Also für die zweispaltigen Designs 49.99998%, für die dreispaltigen 33.33332%. Wird in einem Widget kein colspan="x" Attribut übergeben, wird automatisch colspan0 gesetzt.

4) In templateengine.js kann dann calcRowSpan entfallen, .setWidgetLayout kann die richtige Klasse gleich in data setzen, damit das .widget_container-DIV die passende Klasse zugewiesen bekommt. Das spart deutlich Zeit beim ersten Aufruf.

rowspan:

Die Situation ist etwas komplizierter, weil die Höhe eines Widgets im Augenblick zum Zeitpunkt der CSS-Erstellung nicht bekannt ist. Das liegt daran, dass wir eine font-size in mm definieren, der Browser dann daraus errechnet, wie gross 1em ist.

In den CSS verwenden wir dann px und em lustig durcheinander, und wieviele px am Ende ein line-height: 2em + 0.3em padding + 0.3em margin + 1px border sind weiss man einfach nicht, d.h. wir können gegenwärtig nicht sagen ".rowspan1" hat eine height von x em oder y px.

Der Ausweg ist

- es so machen wie bisher, ein widget DIV in einem widget_container DIV erzeugen und "ausmessen", was trotz aller Bemühungen manchmal schief geht, weil es um 1px nicht passt, oder
- (ungetestet, aber ich vermute es würde gehen) wir stellen alles auf em um. Das sollte sich dann gut addieren lassen und somit könnte man in jedem Design .rowspan1 bis .rowspan(keine Ahnung, 10 oder sowas) definieren.
- das widget_container DIV bekommt über die .rowspan-Klasse eine height in %. Das wäre dann zwar nicht ganz so schön wie bisher, aber wenn man das ausreichend kleinteilig wählt und mit passendem Alignment könnte es gehen. Hätte dafür den Vorteil des "Schachbretts".
- ??

Meine Meinung: Den ersten Teil kann man relativ gefahrlos umsetzen, für den zweiten wär eine geniale Idee total super.

Gruss,

der Jan

[JNK]

Nach einigem weiteren Suchen habe ich dann doch noch eine Möglichkeit gefunden. Die ist zwar nicht "schön" im Sinne von elegant, weil alle Stylesheets und alle sontigen Styles durchsucht werden müssen, aber da das ganze ja nur begrenzt oft beim ersten Aufbau der Seite passiert, ist das wohl zu verschmerzen.

Gruss,

der Jan

P.S.: Ich habe auch das <designtoggle /> dann gleich geändert, bei einem Designwechsel wird jetzt die Seite komplett neu geladen, nur eben mit dem neuen Design. Das umgeht alle Probleme mit Laufzeit-berechneten Styles.

[JNK]

Zur Breite: das Problem ist dabei, dass ich über $(foo).css('width') nur an die absolute Breite in px komme, nicht an das Setting 33%. Wenn ich jetzt diese Breite einfach multipliziere habe ich ein Problem, wenn das Fenster resized wird. Alle anderen widget_container ändern dann ihre Größe (weil im CSS relativ definiert) und das ge-colspan-te Widget bleibt gleich, weil es in px angegeben ist.

Das ist bei der Höhe kein Problem, weil die Widgets wegen der fixierten Schriftgrösse ihre Höhe alle nicht verändern.

Man müsste also entweder die colspan-Klassen nach einem Fenster-Resize neu berechnen, oder an die relative Breiteneinstellung aus dem CSS kommen. Ersteres kann ich nicht und zweiteres scheint nach meinen Recherchen nicht zu gehen.

Gruß,

der Jan


Sent from my iPhone using Tapatalk

[Chris M.]

ich hab gerade ein Changeset committed, in dem colspan und rowspan implementiert werden.

Sehr gut!
(Allerdings noch nicht getestet)

Wir haben im Augenblick zwei- und dreispaltige Designs, denkbar sind auch deutlich mehr Spalten (ich hab da noch was in Vorbereitung).

Wie schon wo anders geschrieben: 12 Spalten wäre das Optimum.

Es ist im aktuellen Design der templatengine.js nicht möglich zur Erzeuigungszeit des Widgets die Breite eines zukünftigen Widgets dynamisch zu bestimmen.

Verstehe ich gerade nicht wirklich. Was ist konkret das Problem und wo müsste wohl zur Lösung gedreht werden?

[JNK]

Nachtrag: Damit lässt sich über

<text colspan="2" /> ein zwei Spalten breiter Spacer erzeugen, entsprechend durch <text rowspan="2" /> ein zwei Zeilen hoher. Vielleicht entspricht das dem FR #3424088.

Gruss,

der Jan

[JNK]

Hallo zusammen,

ich hab gerade ein Changeset committed, in dem colspan und rowspan implementiert werden. Dazu gibt es folgendes zu sagen (swiss? Kannst Du das irgendwann mal konsistent in die Doku übernehmen wenn es fertig ist?):

colspan:

Wir haben im Augenblick zwei- und dreispaltige Designs, denkbar sind auch deutlich mehr Spalten (ich hab da noch was in Vorbereitung). Standardmäßig sind alle Widgets eine Spalte breit. Über colspan="2" bzw colspan="3" können die Widgets verbreitert werden, ein <text> kann somit über zwei Spalten gehen (z.B. als Überschrift), eine Grafik kann die gesamte Bildschirmbreite füllen etc.

Entwickler-Info: Auf Design-Programmierseite muss dazu neben der Breite von widget_container (wie bisher) auch noch die Breite der Klassen colspan2, colspan3 usw mitangegeben werden. Es ist im aktuellen Design der templatengine.js nicht möglich zur Erzeuigungszeit des Widgets die Breite eines zukünftigen Widgets dynamisch zu bestimmen. Widget-Programmierer: es muss, sofern gewünscht, dem Widget-Objekt ein data("colspanClass", foo) mitegebenen werden, wobei foo sich über die Funktion colspanClass(gewünschte Spaltenzahl) erzeugen lässt. Der default-Name für das Attribut heisst "colspan".

rowspan:

Die meisten Widgets sind eine Zeile hoch. Ausnahmen sind image (wird bestimmt über die Bildgrösse), iframe und ein paar andere, deren Höhe über das "height"-Attribut angegeben wird. "height" ist jedoch eine Angabe die sich auf en Widget-Content bezieht, nicht auf das Aussenhöhe. Mit rowspan="x" nimmt der widget_container genau die Höhe ein, zwei übereinanderliegende "Standard (=text, info, etc.)"-Widgets auch einnehmen.

Entwickler-Info: Auf Design-Programmierseite müssen keine weiteren Klassen definiert werden. Widget-Programmierer: es muss, sofern gewünscht, dem Widget-Objekt die eine Klasse "rowspanx" angehängt werden, die dynamisch erzeugt werdebn muss. Das übernimmt die Funktion rowspanClass(gewünschte Zeilenzahl), die auch den richtigen Klassennamen zurückgibt. Der default-Name für das Attribut heisst "rowspan".

Happy Testing,

der Jan