CometVisu - (interner) Beta-Test

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

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

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

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

[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

[Bodo]

Ah ok.

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

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

[netzkind]

=> Wenn Du's in Deine XML drinnen hast, wirst Du es sehen und nutzen können - aber der Editor wird es evtl. zerstören wenn Du ihn nutzt...

Stimmt, und das muss man auch ganz klar so sagen.

Den Vorschlag von Bodo mit dem "nochange" halte ich für nicht durchführbar, aufgrund dessen wie der Editor funktioniert: der Editor speichert nicht das XML, sondern er "serialisiert" was im Browser zu sehen ist. Was er da nicht kennt, kann er nicht serialisieren, das schafft es dann nicht bis zum serverseitigen Speichervorgang (das PHP) und damit ist es dann einfach weg. Dem PHP jetzt beizubringen das er aus dem ursprünglichen XML das er noch auf der Platte hat bestimmte Äste in das neue XML übernehmen soll dürfte schwer werden, denn was dient als Bezugspunkt im XML wenn sich der Baum massiv geändert hat?
Oder ich habe es anders verstanden als Bodo es meinte

Grüße,
Julin

[Bodo]

Meine Idee war den Widgets eine zusätzliche Eigenschaft namens "Maturity" zu geben die auf "release" (default) oder "development" stehen kann.
Der Editor würde dann alles unter "development" ignorieren - solange nicht global oder per URL-Parameter auf development geschaltet wird.

Hoi

Sehr gute Idee, vielleicht kann der User auch einzelne Sachen versiegeln mit dem Status "nochange"

[Chris M.]

Die Gruppen aber nicht in der Visu ausbauen oder?

Meine Idee war den Widgets eine zusätzliche Eigenschaft namens "Maturity" zu geben die auf "release" (default) oder "development" stehen kann.
Der Editor würde dann alles unter "development" ignorieren - solange nicht global oder per URL-Parameter auf development geschaltet wird.

=> Wenn Du's in Deine XML drinnen hast, wirst Du es sehen und nutzen können - aber der Editor wird es evtl. zerstören wenn Du ihn nutzt...

Vl. wäre immer noch überlegenswert, keinen WYSIWYG Editor zu haben, sondern eher eine Art XML Erstellungshilfe

Daran hatte ich ganz am Anfang gedacht - und gleich dazu geschrieben, das ich keinen Editor brauche und ihn deshalb nicht schreiben werde.

Julian hat dann den Ball aufgenommen und den genialen WYSIWG Editor geschrieben

Das wird ja bei 2/3D nicht einfacher.

Gerade da wird ein grafischer Editor wichtig! Koordinaten eintippen will ich niemanden zumuten.
Bedonders spannend wird es werden, wie man einen Editor für das 3D Gebäudemodell macht

Tschuldigung, wenn ich so direkt frage: Gibts dann noch jemanden, der sich um die Feature Requests zur derzeitigen Visu kümmert? Ich denke ja, 2D wird auch eine Weile dauern, da wär das ein oder andere Gimmick schon nett...

Jeder der will!

Das hier ist Open Source. Da macht jeder freiwillige das was sie/ihn interessiert.
Die langweiligen Themen werden dann oftmals von Firmen erledigt, die damit Geld verdienen wollen.

Ich persönlich mache die Features, die mich auch interessieren oder die schnell mal nebenbei gehen und wo ich einen hohen Nutzen für die Allgemeinheit sehe. Daher ich mein Ziel z.B. die 3D Visu die ich einbauen werde, die 2D Visu wird dabei nebenbei mit abfallen.

[greentux]

Die Gruppen aber nicht in der Visu ausbauen oder?

Vl. wäre immer noch überlegenswert, keinen WYSIWYG Editor zu haben, sondern eher eine Art XML Erstellungshilfe
Das wird ja bei 2/3D nicht einfacher.

Tschuldigung, wenn ich so direkt frage: Gibts dann noch jemanden, der sich um die Feature Requests zur derzeitigen Visu kümmert? Ich denke ja, 2D wird auch eine Weile dauern, da wär das ein oder andere Gimmick schon nett...

[Chris M.]

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.

Also Beta ohne Gruppen, dann ist in relativ kurzer Zeit vorstellbar auch den Editor dann up-to-date zu bringen.

OK, das klingt nach einem Plan!

Ich disable die Gruppen und Du bringst Editor für den Rest auf Stand.
(Zeit wäre bis Mitte KW40, vorher will ich kein Release, da ich dann nicht zum antworten kommen könnte...)

Frage: Was ist mit dem ColorChooser? Würde der dann funktionieren? Oder sollten wir als "Experten-Feature" deklarieren? Da's ein Plugin ist, könnten wir sogar ohne releasen...

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.

[vlamers]

Ich glaube auch nicht, das sich absolute Laien die Visu antun werden.

nur die mit einem übertriebenen Ehrgeiz was neues zu lernen. und die löchern die beta tester dann mit fragen.
Also ich muss sagen dass die CV mit bisschen bearbeiten der XML sogar für den täglichen Gebrauch schon sehr gut läuft. Und so schwierig ist die nachbearbeitung nicht dass sie gut läuft. Meiner Meinung nach wäre eine öffentliche beta Ok. Schwierig wird es imho wenn drastische Änderungen hinzukommen würden.
Gruß

Edit: ja ohne Editor wäre Wahnsinn

Sent from my LG-P920 using Tapatalk

[netzkind]

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.

Also Beta ohne Gruppen, dann ist in relativ kurzer Zeit vorstellbar auch den Editor dann up-to-date zu bringen.

Hintergrund ist, dass die Gruppen im Editor nicht funktionieren weil die Funktionsfähigkeit des benutzten jQuery-Plugins das verschieben einfach nicht hergibt. An das Plugin mag ich nicht rangehen (jQuery UI, namentlich dessen drag & drop).

Grüße,
Julian

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.