CometVisu - (interner) Beta-Test

[greentux]

Ich sehe da kein Problem. Wer sich eine xml baut, schafft es auch eine Kopie davon zu erzeugen. Dann kann er ja in Ruhe mal den Editor ausprobieren.
Ich sehe halt das Henne/Ei/Problem. Im Moment gibt es zu wenig Entwickler. Was aus dem angekündigten Wiregateman geworden ist, ist noch unklar, also brauchts mehr Ressourcen. Dazu muss man aber mal raus in die Welt. Momentan ists ja so, das sich jemand für KNX interessieren muß, um sich ins Forum zu verirren. Dort muss er es dann noch via Wiregate zur Cometvisu schaffen. Nicht gerade einfach...

[Chris M.]

Oder ich habe es anders verstanden als Bodo es meinte

Du hast es zumindest so verstanden wie ich es gemeint habe

@Bodo: Da meine Änderung (bzw. noch der Vorschlag dazu) rein auf der Code-Seite ist, hat der keine Auswirkung auf die Config-XML. Es lässt sich lediglich einstellen, ob der Editor entsprechende Widgets ignorieren soll oder nicht.
Wobei ich mir das Ingorieren so vorstelle, dass diese einfach nicht in dem Drop-Down angeboten werden.
Wenn der per Config darüber stolpert sollte er schon probieren damit möglichst gut umzugehen. Mindestanforderung ist dabei, sich nicht irritieren zu lassen. Aber ob - und wie - er dieses Widget dann wieder in die Datei schreibt ist undefiniert, es ist nur sicherzustellen, dass es valides XML bleibt.

[Bodo]

Ah ok.

[makki]

Ich kann mir vorstellen, dass man die Visu um die Gruppen erleichtert, die sind grade so der Hauptgrund wieso ich jedes mal verzweifel wenn ich am Editor arbeiten will.
...
PS:
Visu ohne Editor veröffentlichen ist meiner Einschätzung nach Selbstmord. Dafür ist der Erwartungsdruck inzwischen zu hoch. Selbst für eine Beta.

a) Klingt nach einem Plan!
b) Und Full-Ack: purer Selbstmord! Nur weil 5-10 von uns auch mit einem XML leben könnten, ist das für >>80% selbst ambitionierter IMHO immernoch pure Freakshow..
Ehrlich, ich halte es da - egal wie lange es dauert (!) - lieber mit dem Debian-Prinzip: es ist eben fertig, wenn es fertig ist.. Punkt. Als reiner Anwender (der ich hier nicht bin/sein will!) schätze ich das mehr, als meine Zeit mit halbgarem zu verfrickeln - Stichwort Erwartungshaltung. Natürlich bekommt man hier&heute schon was ziemlich brauchbares aber man muss halt etwas "drin sein".
-> Jeder der auch nur "Häh" sagen kann, bekam zugriff aufs Beta-Forum, wer nichtmal das schafft, ehrlich, der wird IMHO auch nichts weiterentwickeln oder qualifiziert Fehler/Probleme melden (auch wenns nur Verständniss/Doku-Anregung ist - auch wichtig!)

Halbgare Lösungen gibts schon genug, wenn man vor Anwender tritt braucht es eben noch feinschliff, das sind diese verdammt unbeliebten letzten 20% die leider 80% des Aufwandes machen
Die CometVisu ist technisch mal richtig geil, davon bin ich nach wie vor überzeugt, >1000 Posts sagen ein übriges
aber man muss halt viel feilen bis ein Rohdiamant perfekt aussieht.. (Nebenbei sollte man IMHO langsam evtl. in einem pre-alpha-zweig das Thema Websockets antesten; ich bräuchte das für die übergängliche einbindung des HS via HS-KO-GW [hsmon])

Zum Thema Weiterentwicklung: man (ich) sitzt hier immer zwischen allen Stühlen, die Anzahl der Ideen übersteigt die verfügbaren Resourcen ca. um Faktor 10 (wir suchen immernoch! alles!)

Das muss eben auch OSS richten, woran wir auch fundamental glauben (ich schätze fast 50% der hier freigeschalteten haben kein WG - ist auch absolut kein Primärkriterium..)

Mittelfristig würde ich dann endlich den 2D und ggf. 3D Modus einbauen, dann sollte hoffentlich klarer werden können wie der universelle Editor dann aussehen muss.

Ich muss ja erstmal aufholen aber hatte die letzte Woche das vergnügen nur mit klitzekleinen Mobilteilen zuzugreifen: ehrlich? Irgendwie No-go..
Da muss eine UI z.b. ähnlich diesem her (alternatives Design, templateengine, ?, ..) das mit dickem Daumen bedienbar ist..
Auf dicken Displays gehts schon sehr gut, ich bin ja nun absolut kein usability-Experte, aber für klein: da muss noch was..
Werde mich da auch engagieren soweit irgendwie die Zeit für bleibt!

Das soll jetzt keine Kritik sein sondern einfach nur eine sachlicher Praxisbericht;

Schwierigkeiten habe ich noch das derzeitige mit der CV-Struktur und jquery mobile in einklang zu bringen aber am Strand viel dazu gelesen..
Das wäre vielleicht ein Thema für eine DevCon

Soviel erstmal, eine Woche abwesend beschert 100 ungelesenes

Makki

[greentux]

Da das bei Debian mit "fertig wenn fertig" nicht mehr lange gut ging, haben sie dann doch was geändert. Mittlerweile trifft man den Termin dann schon deutlich besser...

[ctr]

Wie Julian bereits geschrieben hat, sehe ich ein Default-Design, dass jeweils überschrieben wird, nicht unbedingt als zielführend an.
Was aber Sinn macht (und IIRC schon umgesetzt ist), ist das man lokal eines der Designs überstimmen kann.

Ich spreche auch nicht von einem Default-Design sondern ein paar Default-Definitonen aus, z.B. für Farben (in den Sinn kommen mir aber auch Icons, die sich ja per background-image genauso umsetzen lassen sollten).
Ich halte es einem User gegenüber (von einer Integration der Styling-Definition in den Editor mal ganz abgesehen) für schlicht und ergreifend nicht vermittelbar, dass man im entsprechenden Design (ggf. in allen) prüfen muß ob eine bestimmte Definition vorhanden ist oder nicht.
Was spricht denn nun wirklich gegen eine "design/basic.css" in der mal ein paar grundlegende Werte definiert sind die aber jedes Design wieder überschreiben kann?

[Chris M.]

Ich disable die Gruppen

Mit
Revision: 420
erledigt.

Ich spreche auch nicht von einem Default-Design sondern ein paar Default-Definitonen aus, z.B. für Farben
[...]
Ich halte es einem User gegenüber [...] für schlicht und ergreifend nicht vermittelbar, dass man im entsprechenden Design (ggf. in allen) prüfen muß ob eine bestimmte Definition vorhanden ist oder nicht.

Das entspricht doch genau dem, was ich oben mal vorgeschlagen hatte:

Was aber Sinn macht, wäre ein paar Farbnamen zu definieren die jedes Design implementieren sollte.

Wie wäre es mit:

• Rot
• Grün
• Blau
• Gelb
• Cyan
• Magenta

Dabei sollte man sich auf wirklich wenige Farben beschränken, die das Design dann jeweils eigen interpretieren kann. Gerade im Zusammenspiel mit den Flavours (die aber wirklich Design spezifisch sind!) soll sich das nämlich nicht beißen.

Was spricht denn nun wirklich gegen eine "design/basic.css" in der mal ein paar grundlegende Werte definiert sind die aber jedes Design wieder überschreiben kann?

Es macht IMHO keinen Sinn Werte zu definieren, die ein Design gleich wieder rückgänig machen muss.

Ich finde es i.O. wenn es ein paar grundsätzliche Farben gibt, auf die man sich blind verlassen kann. (Und wenn man ehrlich ist, dürfte wesentlich mehr als Rot/Grün und ggf. Gelb nicht notwendig sein. Denn nur die haben eine universelle Bedeutung).

Aber für mehr (und insb. die Flavours) sollte jedes Design sich eine Seite im Wiki gönnen und die Features und Möglichkeiten vorstellen.

Oder, Alternativ-Vorschlag zu erzwungenen Farben: wir erzwingen keine Farben, sondern Aussagen.
D.h. jedes Design muss eine "Möglichkeit" für "Wichtig/Gefährlich/Aktiv" (z.B. Rot), "Unwichtig/Harmlos/nicht aktiv" (z.B. Grün) und "(Vor)warnung" (z.B. Gelb) definieren.

[swiss]

Soo..

Ich habe gerade ein "svn up" gemacht. Der Editor funktioniert soweit sehr gut und zerschiesst auch nicht mehr die Config (auch wenn der colorchooser immer noch falsch in die Config übernommen wird und von Hand wieder repariert werden muss).

Leider habe ich aber wieder ein altbekanntes Problem dass nun noch stärker zum tragen kommt da man nun den Editor wirklich nutzen kann....

Ich nutze den aktuellen Firefox.

Wenn ich ein Element z.B. eine Schaltfläche im Editor anlege und speichere wird sie im ersten Moment beim wechsel in den Normalmodus nicht angezeigt. Ist nicht weiter schlimm da nach einem Klick auf Reload die Schaltfläche korrekt erscheint und funktioniert.

Wenn ich nun aber wieder den Editor aufrufe wird scheinbar nicht automatisch ein force-reload gemacht. Das hat zur Folge, dass alle änderungen verschwunden sind. Wenn man dann auf speichern Klickt sind die Änderungen devinitiv weg

Das Problem kann ich umgehen, wenn ich vor dem wechseln in den Editor den Cache leere. Dann wird im Editor die aktuelle Config angezeigt und läst sich beliebig anpassen und ändern.


Dieses Problem sollte unbedingt von einem öffentlichen BETA-Test noch behoben werden. Kann man das mit einem einfach forcereload am Anfang des Editor-Code lösen?

[swiss]

Sorry wenn die Frage vieleicht etwas doof ist aber....

Gibt es in der Cometvisu ein Widget, dass 14-Byte-Texte vom BUS anzeigen kann? Das wäre ja eine von den grundlegendsten Funktionen in einer Visu dass Zustände und Meldungen in Klartext angezeitgt werden können.

[makki]

14byte Text sollte mit dem normalen Info-Widget gehen..

Makki

[swiss]

oO Danke für die Info Ich habe vergessen den DPT einzustallen und bekam desshalb keine Anzeige Jetzt funktioniert es

[netzkind]

Da ich den Code letztes WE mal wieder ausgegraben habe:
- was ist "addresstype" bei Gruppenadressen? Ich habs nur im Editor gefunden, hab ich da was auf Halde entwickelt? Ist das ein Vorgänger von "variant"?
- versteht der ColorChooser nun schon "variant"?

Ich hab den Code vom Editor inzwischen etwas umstrukturiert, anschließend sollte es leichter werden den Code aufzuräumen, das hab ich dann auch auf der Uhr.

Grüße,
Julian

[swiss]

Ich möchte da niemandem in's Handwerk pfuschen. Aber bekomme ich das Syntaxproblem des Colorchosser in der Config selber gefixt?

Wo (in welcher Datei) wird in Editor die Struktur für die Config festgelegt? Ich würde mich gerne mal in die Struktur einarbeiten und gewisse kleinigkeiten eventuell selber fixen.

[netzkind]

Aber bekomme ich das Syntaxproblem des Colorchosser in der Config selber gefixt?

Ich verstehe leider nicht was du mit "das Syntaxproblem" meinst, aber wenn du es selbst fixt brauche ich das vielleicht auch nicht
Aber: wenn du Fehler siehst, schreib doch bitte einen Bugreport bei sourceforge. Wenn es da schon einen Bug gibt, check ob der schon assigned ist - dann kümmert sich jemand drum (in dem Zusammenhang: assignen sollte man sich immer nur selbst, nicht jemand fremdes assignen - der weiß von seinem Glück vielleicht garnichts).

Wo (in welcher Datei) wird in Editor die Struktur für die Config festgelegt? Ich würde mich gerne mal in die Struktur einarbeiten und gewisse kleinigkeiten eventuell selber fixen.

Ich fürchte ich steh da ein wenig auf dem Schlauch.

Das ist ein Zusammenspiel aus der JS-Datei unter edit/ und der PHP-Datei save_config.php (Name?).

Da groß dran rumzuarbeiten halte ich im Moment für wenig ratsam, weil ich aktuell die Struktur des JS-Codes ganz massiv geändert habe, und die Änderungen schnellstmöglich ins SVN bringen will. Wenn sich in der Zwischenzeit am SVN-Stand des Editors was geändert hat, gibt es fiese Merge-Konflikte, die mich entweder mein Haupthaar kosten oder glatt übergebügelt werden.

Ich warte derzeit nurnoch auf die Beantwortung meiner letzten Frage zum Thema Colorchooser (Variant vs. Addresstype) bevor ich das einchecken kann. @Chris: ich hätte angenommen, du kannst was dazu sagen?

Grüße,
Julian

[swiss]

Ok. Dann lass ich mal die Finger davon.

Ich habe nur das Problem, dass nach dem speichern im Editor der Configeintrag das Colorchosser falsch ist. Da hat sich an der Syntax ja etwas geändert. Desshalb muss ich nach dem Speichern jedes mal wieder den fehlerhaften Configeintrag des Colorchosser ersetzen (reparieren).

Genau dem Problem wollte ich mal nachgehen aber wenn du dem Editor ohnehin eine Radikalkur verpasst, lass ich mal noch die Finger davon sonst gibts nur Versionsprobleme.