CometVisu - (interner) Beta-Test

[vlamers]

Ok kein Problem.
Wollte nur in Erfahrung bringen ob das an meinen Endgeräten liegt oder ...? Galaxy S hat offizielles gingerbread und meine nur eine zurechtgebogenene halb gut funktionierende Version

Danke

Gruß Volker

[Chris M.]

@JNK bzgl. infotrigger: getestet hab ich's noch nicht wirklich. Aufgefallen sind mir aber zwei Punkte

1. Du hast etwas wie "[-] [+] <Wert>" - wäre es nicht intuitiver statt dessen "[-] <Wert> [+]" zu haben?
2. Wäre es bei der CSS Klasse switchInvisible nicht sinnvoller den Rahmen per "border: none" verschwinden zu lassen, als den nur Rahmen schwarz zu machen?
   Ich kann mir gut Designs vorstellen, die je nach Flavour die Hintergrundfarbe ändern...

Aber mach doch mal bitte einfach ne Ansage was das zurücksenden angeht, ich füge mich dieser auch brav

Ich werde das Lösen. Da wird kein RO/WO o.ä. notwendig sein.

[makki]

Ich werde das Lösen. Da wird kein RO/WO o.ä. notwendig sein.

Klingt gut, bin schon ruhig Solange es das Kernproblem löst, eine Visu die ungefragt Werte sendet ist halt nur schwer vermittelbar (ich hatte hier ehrlich weniger lustige Effekte als Rolladen +-1%, meine Chefin ist das ja gewohnt, aber..)

Makki

P.S.: fürs interne: ich bin die nächsten 2 Tage So/Mo "offline"

[JNK]

1. Du hast etwas wie "[-] [+] <Wert>" - wäre es nicht intuitiver statt dessen "[-] <Wert> [+]" zu haben?
2. Wäre es bei der CSS Klasse switchInvisible nicht sinnvoller den Rahmen per "border: none" verschwinden zu lassen, als den nur Rahmen schwarz zu machen?
   Ich kann mir gut Designs vorstellen, die je nach Flavour die Hintergrundfarbe ändern...

zu 2) Stimmt. Ich hab das CSS Zeug nicht ganz verstanden, und das war das einfachste um es erstmal ans Laufen zu bekommen, und danach habe ich es vergessen. Völlig ohne diese Klasse ist der Wert nicht vertikal zentriert, das sieht nicht aus. Fixe ich im SVN

zu 1) Ich glaube, das is eine Philosophie-Frage. Ich habe das gerade mal ausprobiert. Machbar ist natürlich beides, aber mein PAF(*) und WAF ist grösser, wenn es -/+/Wert ist. Man könnte natürlich eine Option dafür einbauen..... So a la variant="..." mit "..."

• dvu -> -/wert/+
• duv -> -/+/wert
• vdu -> wert/-/+
• vud -> wert/+/-
• udv -> +/-/wert
• uvd -> +/wert/-

Auch wenn ich nicht weiss, wozu man man manche davon benötigen können sollte. Und nen default auf dvu oder duv.

Gruss,

der Jan

*) PAF = Persönlicher Acceptance Factor

[Chris M.]

zu 1) Ich glaube, das is eine Philosophie-Frage. Ich habe das gerade mal ausprobiert. Machbar ist natürlich beides, aber mein PAF(*) und WAF ist grösser, wenn es -/+/Wert ist. Man könnte natürlich eine Option dafür einbauen..... So a la variant="..." mit "..."

Ein variant wäre ja für das <address> Element, aber ein info_position={0,1,2} würde reichen, denn ob die Buttons jetzt +/-, -/+, hoch/runter, rechts/links, ignorieren/abbrechen, Licht/Weltuntergang ... heißen und machen ist vollkommen egal, das stellt man ja in den anderen Attributen ein.

[Santonian]

Ich mische mich jetzt auch einfach mal hier ein.
Hab die letzten Tage ein wenig mit dem aktuellen SVN Inhalt rum probiert. Und folgende Punkte wollte ich mal kurz ansprechen:

- Die Visu lässt sich auf nem iphone1 nicht laden. Liegt das an dem veraltetem Safari? (HTML5?)

- Wenn ich das neue Gruppen Element benutze zerschießt der Editor mir früher oder später meine config Datei. Ist das bekannt? (Löscht z.B. vorhandene Elemente)

- Das Gruppen Element scheint mir noch nicht in der .xsd Datei enthalten zu sein.

- Ich hab ne kleine Anpassung in der check_config gemacht, damit ich sehe in welcher Zeile der config der Fehler ist und nicht in welcher Zeile von check_config der schema_validate Aufruf ist. Wie regelt ihr das mit einchecken, abstimmen vorm einchecken usw.?

Ansonsten klasse Arbeit bis jetzt!

Gruß
Reinhard

[JNK]

Hallo,

- Wenn ich das neue Gruppen Element benutze zerschießt der Editor mir früher oder später meine config Datei. Ist das bekannt? (Löscht z.B. vorhandene Elemente)

In SourceForge gibt es ein Bug-Management-System. Da kannst du sehen, was es an "known-bugs" gibt und ob schon jemand daran arbeitet. In diesem Fall ist das so.

- Das Gruppen Element scheint mir noch nicht in der .xsd Datei enthalten zu sein.

Da nicht, das habe ich nachgetragen und werde das fixen.

Gruss,

der Jan

@Chris: info-position habe ich so eingecheckt.

[Chris M.]

Coding style

Je mehr Leute am Code mitmachen - was höchst erfreulich ist - um so wichtiger ist es, ein paar Dinge zu vereinheitlichen.

Besonders beliebt: der Coding Style.

Es gibt hier unzählige Möglichkeiten und vermutlich noch viel mehr Flame Wars darüber. Daher nehme ich jeden Vorschlag gerne an, behalte mir aber vor die Diskussion ggf. ziemlich schnell abzubrechen und ein Ergebnis festzulegen.

Unter https://sourceforge.net/apps/mediawi...su/CodingStyle habe ich schon mal ein paar Punkte aufgeführt.

[netzkind]

Juhu, coding-rules.

Tab = 8, Shift = 2 ... irgendwie fehlt mir grade was ein Shift ist.
Ich nehme an das ist die Einrückung am Zeilenanfang je nach Verschachtelungstiefe?

Das würde ich beides einheitlich auf 4 Leerzeichen setzen (/* vim: set expandtab tabstop=4 shiftwidth=4 softtabstop=4: */)

Und ich würde die Zeichen pro Zeile auf bspw. 120 setzen - Sinn ist ja, dass man auf dem Monitor genug Platz dafür hat, und ich nehme an, dass die meisten in einer IDE arbeiten, und nicht auf einer 80x40-Konsole.
Wenn wir bei 80 Zeichen umbrechen müssen, kann das die Lesbarkeit stellenweise wieder stark verschlechtern (ist meine Erfahrung).

Was mir noch gefällt, ist einheitliches Verhalten zur Position der geschweiften Klammern. Ich mags gerne auf der Zeile der öffnenden Funktion/Bedingung, schließend auf eigener Zeile mit 1 Tab Einrückung (verglichen mit dem ersten Zeichen der öffnenen Funktion/Bedingung). Aber ich bin froh wenn es überhaupt einheitlich wird

Grüße,
Julian

[Chris M.]

Ah, schön, es geht schon los

Tab = 8, Shift = 2 ... irgendwie fehlt mir grade was ein Shift ist.
Ich nehme an das ist die Einrückung am Zeilenanfang je nach Verschachtelungstiefe?

Ja, genau

Das würde ich beides einheitlich auf 4 Leerzeichen setzen

Nö, genau da bin ich hart.
Ein Tab hat 8 breit zu sein, sonst bekommt man in allem was nicht die IDE ist, grässlich formatierten Code (SVN-Logs, Diff, Forum, ...)
Und um es für alle einheitlich zu machen, sicherheitshalber gleich den Tab verbieten. (= Hosenträger + Gürtel)

Ich lasse eher noch über die Shiftwidth=2 diskutieren - aber 4 halte für verschwenderisch. Ist auch schon mal aufgefallen, dass 2 Spaces so breit sind wie ein Char hoch? D.h. mit 2 gibt's ein schönes rechteckiges Raster.

(/* vim: set expandtab tabstop=4 shiftwidth=4 softtabstop=4: */)

Sollten wir nach dem diktatorisch festgelegten Konsens in die Dateien hängen.

Und ich würde die Zeichen pro Zeile auf bspw. 120 setzen - Sinn ist ja, dass man auf dem Monitor genug Platz dafür hat, und ich nehme an, dass die meisten in einer IDE arbeiten, und nicht auf einer 80x40-Konsole.
Wenn wir bei 80 Zeichen umbrechen müssen, kann das die Lesbarkeit stellenweise wieder stark verschlechtern (ist meine Erfahrung).

Da bin ich relativ offen. Habe deswegen im Wiki auch nur "should 80" geschrieben.
Platz wäre bei mir genug da - aber was ist mit Copy&Paste in Mails und hier im Forum? Wäre da eine freiwillige Beschränkung auf 80 nicht besser?

Was mir noch gefällt, ist einheitliches Verhalten zur Position der geschweiften Klammern. Ich mags gerne auf der Zeile der öffnenden Funktion/Bedingung, schließend auf eigener Zeile mit 1 Tab Einrückung (verglichen mit dem ersten Zeichen der öffnenen Funktion/Bedingung).

Hast Du ein Beispiel - die Bechreibung verstehe ich leider nicht

Aber ich bin froh wenn es überhaupt einheitlich wird

Ja, wurde Zeit - inzwischen gibt's drei Varianten im Code, die auch noch inkompatibel sind (vgl. diese teuflischen Tabs. Hab ich schon mal erwähnt, dass die verboten gehören?)

[Bodo]

Hoi

Ich hab' hier gar nichts zu sagen mach's aber trotzdem.

Ich finde zwei Leerzeichen zum Einrücken besser als 4 oder TAB.

und das mit den geschwoffenen Klammern:

func() {
  if() {
    bla;
  }
}

[Chris M.]

Neben der Style fragen, hier noch was konkretes

Solange es das Kernproblem löst, eine Visu die ungefragt Werte sendet ist halt nur schwer vermittelbar

Dieses Thema will ich gerade angehen. Sehr schön lässt es sich auf der Demo-Config nachvollziehen:
Dort ist in der magentafarbenen Gruppe ein Slider, der nur alle 0,5 einen Wert annimmt. Also z.B. -5,5 oder -6.

Sende ich nun über den Bus z.B. von der Komandozeile des WireGate aus ein

groupwrite ip:localhost 12/4/250 85 CC

würde der Slider sich gerne auf -5,64 setzten - was aber nicht geht, da dass ja kein vielfaches von 0,5 ist. Folglich ändert jQuery den Wert auf -5,5 ab.

Aktuell ist das nun so, dass der Slider sieht -5,5 != -5,64 und daher -5,5 versendet. Folglich ist auch der in der Slide Group angezeigte Wert bei "Slide Info" dann -5,5.
Wenn man an der passenden Stelle im FireBug (structure_pure.js, Zeile 240) einen Breakpoint setzt, den Wert sendet und dann schrittweise durch den Code geht, kann man sehr schön nachvollziehen, dass die Slide Info sogar erst die -5,64 anzeigt und dann auf -5,5 springt.

Was ist nun gewünscht?
Soll der Slider in der Mitte zwischen den Werten stehen bleiben?
Was wäre mit einem Slider der nur die Werte 0, 1 und 2 darstellen darf (z.B. als Lüftungs-Regler) und nun einen Wert 0,5 gesendet bekommt?

Oder soll der Slider sich einfach und still auf den nächstbesten Wert setzen?

[vlamers]

Lässt sich das nicht einfach unter "step" lösen? Wenn ich da Step = 1 eingebe sollte er nur ganze werte nehmen oder?

Gruß

[Chris M.]

Lässt sich das nicht einfach unter "step" lösen? Wenn ich da Step = 1 eingebe sollte er nur ganze werte nehmen oder?

Das ist ja genau das Problem: Wie soll sich der Slider verhalten, wenn der per Step=1 nur ganze Werte anzeigen darf, aber trotzdem über den Bus ein Wert dazwischen kommt?

[vlamers]

Ahhhh jetzt hab ichs auch kapiert.

Der Slider soll den gerundeten Wert anzeigen aber im Hintergrund mit dem Empfangenen weiter arbeiten, bis er über den Slider einen neuen Wert empfängt. Geht das?

Gruß