CometVisu - (interner) Beta-Test

[Chris M.]

Ich würde gerne die 0.6.0-pre1 releasen. D.h. eine Version vor den Release-Candidates, da insb. beim Editor noch ein paar Punkte offen sind.

Ziel dieses Releases ist es, das ganze stabilisieren zu lassen. D.h. Feature-Freeze bis 0.6.0 (die öffentliche Beta) draußen ist.

Gibt es etwas, was dagegen spricht?

[StefanW]

Hab hier auch nichts zu melden, aber ein paar Vorschläge für Coding Style (weil ich war ein extremer Verfechter von sehr aufgeräumten Code als ich mal programmiert habe...):

• Klare Beschreibungsköpfe für jede Funktion / Prozedur / Methode oder wie das Zeugs heute heißt.
• Was für mich in den Beschreibungskopf mindestens rein gehört ist: Datum, Author, Version, Bezeichnung, Kurzbeschreibung
• Datum nur im ISO-Format YYYY-MM-TT, also heute ist der 2011-06-04
• Dateinamen: Nur alle Zahlen und Buchstaben (lower) aus 7-Bit-ASCII sowie - und _ . Keine Spaces! Früher hätten wir noch gesagt, nur in 8.3 notation, wahrscheinlich ist das heute relativ egal.

LG

Stefan (der in den nächsten Tagen seinen Teich mit der Comet Visu steuern wird)

[JNK]

Zum coding style:

Einrücken: Ich bin wohl optischer Grobmotoriker, deswegen finde ich 2 Spaces extrem unübersichtlich. irgendwas zwischen 3 und 5 finde ich gut.

Block-Klammern: Bin ich leidenschaftslos, aber in eigenem Code verwende ich:

if (jhkjh) {
blabla
} else {
blubblubb
}


case/uimlaute: sehe ich wie makki. Am Besten alles lowercase und am Besten Umlaute von der Tastatur streichen.

Gruss,

der Jan

[makki]

svn up: Sieht sehr gut aus.. Werde weiter testen..
Die Dateinamens-Regeln und das Umlaut-verbot sind übrigens nicht neu sondern 13J bewährte, beinharte ElabNET-Praxis
Und da fallen mir gleich noch ein paar ein (vielleicht teils nichts für den Coding-Style):
- Passwörter/Variablen haben keine leicht verwechselbaren Zeichen wie O/0. 1/I/l (eins, grosses i, kleines L), B/8, y/z (Qwertz/Qwerty), nur a-z, $,!,".","," - CamelCase hier aber erlaubt..

Makki

[Chris M.]

Den Slider (noch nicht den ColorChooser!) habe ich jetzt mal im Verhalten geändert - bitte ausgiebig testen!

Die Style-Punkte von Makki kopiere ich mal in's Wiki

[makki]

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

In der HS-Visu macht es mit dynamischen Symbolen z.B. nicht anders, wäre also quasi bewährt..

Coding-Style: Klingt gut, ich orientiere mach da gerne an dem jew. bearbeiteten, bin also eher leidenschaftslos solange es eingerückt & damit übersichtlich wirkt.. Tabs gehören verboten, richtig, wenn nicht jeder Editor eine andere Default-Ansicht dazu hätte
Hinzufügen würde ich noch
- Newline should be LF (\n, 0x0A)
für Dateinamen:
- nur a-z 0-9 -_ (und natürlich ohne Umlaute)
- kein CamelCase, filenames should lowercase

Makki

[vlamers]

Hmm

meines erachtens die sinnvollste. Per Slider bekomme ich nie 15.67 hin sondern 15 oder 15,5. Wenn es aber von ner logik ausgelöste 15.67 sein müssen (auch damit die logik kapiert das der soll wert erreicht ist, sonst schiebt die alle paar ms ein neues telegramm hinterher). So ein Laie über das Thema

Gruß

[Chris M.]

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

Klar, das ist sogar die leichter zu implementierende Möglichkeit.

[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ß

[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]

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.]

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?

[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.]

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?)

[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