Neues Feature: colspan/rowspan

[ctr]

Ja, colspan/rowspan ist jetzt per <layout> anzugeben.
=> Du kannst Deine Config entsprechend anpassen.

Gilt das nur für <text> oder alle Elemente (page, group, slider)? Ich habe gerade bei mir vor alle colspan Attribute ein "><layout" eingefügt (nachdem es nach einem svn up mit der alten Syntax nicht mehr ging), aber nun bleibts bei "Loading..." hängen

[Jockel]

Grundsätzlich ist es bei Work-in-Progress so: man nicht generisch sagen, wann Bug-Meldungen stören und ab wann sie hilfreich sind

Mal als Vorschlag, da wir bei uns damit gute Erfahrungen gemacht haben: Neue Features werden auf einem eigenen Branch (pro Feature ein neuer) entwickelt und nach der Fertigstellung auf den Trunk gemergt.

Damit hat man natürlich viele Feature-Branches, die nach kurzer Zeit wieder verwaisen, das sehe ich aber nicht als Problem. Dafür ist der Trunk immer (einigermaßen) Funktionsfähig und Bugs im Trunk sollen grundsätzlich gemeldet werden, da der Entwickler die Features ja für fertig hält. Ein weiterer Vorteil ist, das mehrere parallele Neuimplementierungen sich nicht stören.

[Chris M.]

Gilt das nur für <text> oder alle Elemente (page, group, slider)? Ich habe gerade bei mir vor alle colspan Attribute ein "><layout" eingefügt (nachdem es nach einem svn up mit der alten Syntax nicht mehr ging), aber nun bleibts bei "Loading..." hängen

Das mit dem <layout> gilt überall. Wenn's wo noch nicht funktionieren sollte (könnte z.B. bei CV-Plugins passieren...) dann ist's ein Bug und gehört behoben.

Wenn's bei Loading... stehen bleibt kann's z.B. eine defekte Config-Datei sein. Was sagt der Check Config?

Mal als Vorschlag, da wir bei uns damit gute Erfahrungen gemacht haben: Neue Features werden auf einem eigenen Branch (pro Feature ein neuer) entwickelt und nach der Fertigstellung auf den Trunk gemergt. [...] Ein weiterer Vorteil ist, das mehrere parallele Neuimplementierungen sich nicht stören.

Danke für den Vorschlag! Ich fürchte aber, wir sind zu klein, bzw. viel zu wenige Entwickler, als dass wir davon profitieren würden:
Kurz vor dem letzten Release hatten wir die Weiterentwicklung während des Feature Freeze in einen anderen Branch ausgelagert - mit dem Effekt dass die Testtiefe gerade während der kritischen Phase überschaubar war. Und da ich das Gefühl habe zur Zeit hier alleine zu entwickeln sehe ich auch keine Gefahr von konkurrierenden Parallel-Entwicklungen...

Ich bin aber für jedes Entwicklungsmodell offen, was für eine hohe Beteiligung sorgt!

[vlamers]

Colspawn/rowspawn gehen bei mobile devices die sich als nicht Desktop Ausgeben nicht. Dass hat zur Folge dass sie einfach nicht angezeigt werden. (Android: Opera, FF [Beta,Aurora,Nightly], Chrome). Bin mir aber nicht sicher ob dass ein Bug oder so gewollt ist.
Für einen Tipp in welcher Datei dass festgelegt ist, wäre ich dankbar, würde da gerne ein wenig testen/spielen.

Gruß

[ctr]

Wenn's bei Loading... stehen bleibt kann's z.B. eine defekte Config-Datei sein. Was sagt der Check Config?

Das mit Loading waren nur vergessene "/" im Layout Element.
Allerding stolpert check_config noch über Layout im Zusammenhang mit Group:

Error 1871: Element 'layout': This element is not expected. Expected is one of ( line, break, text, switch, toggle, trigger, multitrigger, infotrigger, designtoggle, slide ).

[Chris M.]

Colspawn/rowspawn gehen bei mobile devices die sich als nicht Desktop Ausgeben nicht. Dass hat zur Folge dass sie einfach nicht angezeigt werden. (Android: Opera, FF [Beta,Aurora,Nightly], Chrome). Bin mir aber nicht sicher ob dass ein Bug oder so gewollt ist.
Für einen Tipp in welcher Datei dass festgelegt ist, wäre ich dankbar, würde da gerne ein wenig testen/spielen.

Ah, ok. Das kann (noch) sein - ich würde mal auf Code in der Ecke der templateengine.js um Zeile 332 tippen.

Was man auch mal beantworten müsste, wäre die Frage wie ein Layout möglichst transparent von großen auf kleine Geräte skaliert.
Das ursprüngliche Pure Design hat das dadurch versucht, dass aus zwei Spalten eine wird - bei den 12 Spalten inkl. colspan geht das zumindest nicht mehr trivial.

Wie sollen wir hier vorgehen?

Von 12 auf 6, 4, 3, 2 und schließlich 1 Spalte gehen?

Das mit Loading waren nur vergessene "/" im Layout Element.

Nur?!?!!?!?? - Du hattest eine ungültige XML-Datei erzeugt, es hätte die Welt untergehen können!

Allerding stolpert check_config noch über Layout im Zusammenhang mit Group:

Error 1871: Element 'layout': This element is not expected. Expected is one of ( line, break, text, switch, toggle, trigger, multitrigger, infotrigger, designtoggle, slide ).

Ah, da muss die XSD wohl noch angepasst werden...

[vlamers]

Hmm ich würde bei mobile geräten von hausaus 3 vorgeben. Tablets sollten ja einen anderen UA haben. Denen würde ich die Desktop Version geben.
so könnte man mit 2 Einstellungen alle Devices "erschlagen".
Mir als User würde dass vollkommen ausreichen, (zur zeit am Tablet die desktop version, am handy eine config ohne col/rowspan)

Gruß

[vlamers]

OK

die Zeile 332 hab ich noch Verstanden, dass darunter nicht

wenn ich die folgendermaßen Anpasse:

if (!/(Mobile|Opera Mobi|blackberry|iphone|ipod|series60|symbian|windows ce|palm)/i.test(navigator.userAgent.toLowerCase())) {

Also das Android raus, Oper Mobi und Mobile rein, dann sind folgende Browser am Handy OK: Opera, Firefox (Chrome teste ich gleich wenn ich ihn am Handy hab)
Am Tablet outen sich Opera, Firefox und Chrome anders, so dass die die Desktop Version bekommen.

Am Handy steht im UA immer ein Mobile dabei (ausser bei Opera).

Was natürlich noch nicht geht ist die navbar. Da macht sich meine Unwissenheit aber bemerkbar , so dass ich dass nicht anpassen kann...

Gruß

[JuMi2006]

Ich hab noch ein kleines Syntax-Problem in der aktuellen SVN-Version.
Die colspan/rowspan Attribute hab ich via layout hinzugefügt und funktionieren prächtig.

Jetzt frage ich mich aber wie ich mappings, formate etc. einbinde ???
Der code unten sorgt auf jeden fall fürs richtige colspan/rowspan aber schmeißt mir die Infos dahinter weg.
Wohin muss jetzt format, series, refresh etc. ?

<diagram_info><layout colspan="4" rowspan="1" format="%.1f °C" series="day" refresh="300" gridcolor="#707070" tooltip="true"/>
  <label><icon name="temp_temperatur"/>Wohnzimmer</label>
  <axis position="right" min="15" max="30" label="Temperatur °C" unit=" °C">percent</axis>
  <address transform="DPT:9.001" variant="" >7/1/50</address>
  <rrd yaxis="temp" color="#FF00FF" label="Raumtemperatur">28.5D41F0020000_temp</rrd>
  <rrd yaxis="temp" color="#FFFF00" label="Estrichtemperatur">28.2A2723030000_temp</rrd>
</diagram_info> 

[chrisper]

Ich kann jetzt nicht nachschauen, aber ich glaube das soll so auschauen:

<diagram_info><format="%.1f °C" series="day" refresh="300" gridcolor="#707070" tooltip="true"/>
  <layout colspan="4" rowspan="1"/>
  <label><icon name="temp_temperatur"/>Wohnzimmer</label>
  <axis position="right" min="15" max="30" label="Temperatur °C" unit=" °C">percent</axis>
  <address transform="DPT:9.001" variant="" >7/1/50</address>
  <rrd yaxis="temp" color="#FF00FF" label="Raumtemperatur">28.5D41F0020000_temp</rrd>
  <rrd yaxis="temp" color="#FFFF00" label="Estrichtemperatur">28.2A2723030000_temp</rrd>
</diagram_info> 

[JuMi2006]

O.K. nicht ganz aber guter Ansatz

so läufts:

<diagram_info format="%.1f °C" series="day" refresh="300" gridcolor="#707070" tooltip="true">
  <layout colspan="4" rowspan="1"/> 

Jetzt wo ich es fertig sehe ergibt es auch einen Sinn.

[makki]

Mal als Vorschlag, da wir bei uns damit gute Erfahrungen gemacht haben: Neue Features werden auf einem eigenen Branch (pro Feature ein neuer) entwickelt und nach der Fertigstellung auf den Trunk gemergt.

Mal ehrlich, ich glaube es gibt hier <10 die überhaupt wissen was branch&trunk sind, ich halte das für overkill bw. unnötige Arbeit, weil irgendwer muss das auch pflegen und machen..

Solange es überschaubar ist und der Rest eh lieber seine ganz eigene Kindergarten-visu als one-man-show zusammenbastelt macht es IMHO keinen Sinn, da mords Aufwand reinzustecken, 50 branches etc zu überblicken..

Makki

[Jockel]

Solange es überschaubar ist und der Rest eh lieber seine ganz eigene Kindergarten-visu als one-man-show zusammenbastelt macht es IMHO keinen Sinn, da mords Aufwand reinzustecken, 50 branches etc zu überblicken..

Es war ja nur als Vorschlag gedacht um WIP vom "halbstabilen" Trunk zu trennen, das war ja ein oben angesprochenes Problem. Ich verstehe auch die Argumente dagegen, aber Aufwand ist das eigentlich nicht. Ich handhabe das sogar bei den Projekten bei denen ich alleine an der SW arbeite.

[greentux]

In der Tat wäre das eine gute Idee. Da ich selber aber keinen Code beisteuern kann (jedenfalls nicht von geeigneter Qualität), kann ich mich da nicht wirklich einmischen.
Es würde jedenfalls auch dem "release often, release early"-Grundsatz etwas bringen, der vielen anderen OSS-Projekten hilft, frühzeitig auch unbedarften Nutzern eine SW an die Hand zu geben, die dann ausführlicher getestet werden würde.

[Chris M.]

Es würde jedenfalls auch dem "release often, release early"-Grundsatz etwas bringen, der vielen anderen OSS-Projekten hilft, frühzeitig auch unbedarften Nutzern eine SW an die Hand zu geben, die dann ausführlicher getestet werden würde.

Hast Du hier - das ist die SVN Version.

Anspruch an SVN ist immer, dass es grundsätzlich läuft, sonst sollte nicht commitet werden. (Seltene und bewusste) Ausnahmen werden hier vorher angekündigt - und wenn's schief gegangen ist, kann man's hier auch meist lesen.