Editor Weiterentwicklung

[MGK]

Der Editor stellt in der linken hälfte den Aufbau der Visu in einer Baumstruktur (ähnlich der Exploreransicht bei Windows) dar. Wenn man ein Element aus dieser Baumstrucktur anklickt, werdeninder Rechten Hälfte die Optionen eingeblendet. Viele der Einstellungen können dabei durch Auswahllisten getätigt werden. Daduch wird die Konfiguration vereinfacht und Fehler eingeschränkt.

Aus Anwender-Sicht ist das ein Editor der die Struktur der Visu intuitiv anzeigt und in Benutzer freundlichen Dialogen sämtliche Möglichkeiten bietet, die die CV bietet.
(Das diese Struktur genau die ist, die auch im XML liegt ist eher ein Beweis dafür das die CV-Syntax intelligent gemacht wurde, als das man hier "nur" einen XML-Editor hat. Im Gegenteilt, für einen allgemeinen XML-Editor ist der CV-Editor wieder etwas zu speziell)

Der Anwender hat in der aktuellen Version des Editors den Nachteil, dass er das Ergebnis der Einstellungen nicht unmittelbar sieht (per Vorschau-Button aber dennoch leicht erreichbar).
Das ist natürlich ein (deutlicher) Schritt zurück vom 0.6er Editor. Aber hier hoffe ich auf eine zukünftige Erweiterung. Das ist kein prinzipielles Problem des neuen Editor-Ansatzes.

hört sich für mich nicht schlecht an... links den Visu-Baum, recht oben die Attribute, dann muss "nur noch" eine Darstellung der aktuell ausgewählten Visu-Seite rechts unten dazugebaut werden. Oder in einem Extra-Preview-Fenster, das müsste halt "nur" den Inhalt der aktuellen Seite darstellen? Aber die Visu wird ja eh im Browser dargestellt, man müsste halt "nur" den selben Code nehmen der jetzt die Seiten baut um die richtige "Seite" der Visu darzustellen.

Also mir wäre sowas WYSIWYG-mässig genug, für mich muss kein Drag&Drop wie jetzt sein.

Das dürfte m.E. auch relativ wenig neuen Code erfordern wenn der Editor so weit entwickelt ist.

Michael

P.S. vielleicht liege ich auch völlig falsch mit dem "wenig Aufwand", ich habe (ausser kurzen Shellscripten) lange nicht programmiert...

[Chris M.]

Richtig. Genau der integrierte Preview fehlt noch (der externe ist schon da). (Hatte ich im Posting https://knx-user-forum.de/289905-post256.html bereits beschrieben)

Daher bin ich ja auch der Meinung, dass der neue Entwicklungsansatz richtig ist. Ist zwar nicht WYSIWYG - aber nah genug dran.

[henfri]

Hallo,

was für ein Release auch noch nötig ist -s.o.- ist eine vernünftige Installationsanleitung.

Zum Editor:
Mir ist das momentan noch zu viel geklicke auf +.
Kann man das nicht auf das Wesentliche reduzieren?

Ich denke, es sollten einfach alle Parameter sofort sichtbar sein.
Elemente, die nur einen Parameter haben, sollten keinen Unterpunkt haben, sondern der Unterpunkt sollte direkt angezeigt werden:
Statt:
Label
+Text
Wohnzimmer

Label Text: Wohnzimmer

Ein live-Preview des aktuellen Element wäre aber schon super, so wie du das skizziert hast.

Was ich auch nicht verstehe ist, warum man nicht direkt darin editieren kann.
Also klick auf den Text und man kann den Text ändern. Rechtsklick auf einen Slider und man kann die GAs ändern.

Zur Smartvisu/Smarthome:
Ich bin nicht ganz sicher, ob ich dich bzgl. Backend richtig verstehe. Was nett ist an der Kombination sh/sv ist die Autogeneration von Konfigurationen. Das würde ein CV-Backend für sh.py ja nicht adressieren.
Und die Tatsache, dass ich statt Gruppenadressen direkt die sh.py Items (also z.B. eg.wohnzimmer.licht.dimmwert) adressieren kann. Würde das mit einem CV-Backend gehen?

Gruß,
Hendrik

[Gringo885]

Nachtrag:

Evtl. kenn auch jemand einen Studenten (oder gar einen fitten Schüler...) der sich hier in den Semesterferien ein Zubrot verdienen möchte und gleichzeitig ein gewisses Skill-Set aufbauen oder nachweisen möchte (macht sich bei zukünftigen Jobs oder gar Arbeitgebern immer gut!).

Dann dürften wir sicher deutlich günstiger zu einer passenden Lösung kommen

Was wären denn die Anforderungen an die Person und wie groß wäre das Zubrot, also mit was könnte man denn Werben ? ^^

Ich kann sonst einfach mal nen paar Informatiker an unserer TU fragen bzw. das mal in das Studentenforum eintragen. Wenn Anforderungen / Auftrag und Lohn stehen könnte sich da vlt wer finden. Sind ja im mom Klauuren bzw. Semesterferien

Gruß Gringo

[swiss]

Hmm... Man könnte eine art Spendenkonto einrichten auf dass jeder der das Projekt Editor unterstützen möchte etwas überweisen könnte. Dann könnte man auf Wunsch auch anonym spenden.

Da mir die CometVisu und einen benutzerfreundlichen Editor sehr am Herzen liegt, wäre ich mit 50 dabei. Aber man müsste dann auch einen Leistungskatalog zusammenstellen, in dem steht, was der neue Editor können muss. Und wie er aussehen sollte. Sonnst weiss man ja nicht, was man am Ende für sein Geld bekommt.

[Chris M.]

Was wären denn die Anforderungen an die Person und wie groß wäre das Zubrot, also mit was könnte man denn Werben ? ^^

Vermutlich hängen die genauen Vorlieben davon ab, wer letztendlich die Bezahlung übernimmt.

Ich würde (ohne dass ich mich um die Bezahlung kümmern würde!) als Grundanforderung sehen:

• Selbstständiges Arbeiten
• Auch etwas Nehmerverhalten im Sinne des Boxsportes

Fachlich wäre sicher noch geschickt (je mehr um so besser, ein interessierter der sich einarbeitet ist mir aber immer lieber als ein unmotivierter, der schon was kann...):

• JavaScript
• HTML
• CSS
• Ggf. etwas PHP
• Ggf. etwas ästhetisches Empfinden
• Linux oder Unix Grundkenntnisse

Grundsätzlich könnte man sich hier auch eine Arbeit im Rahmen vom Google Summer of Code vorstellen - außer dass ich nicht weiß, wie man das einsteuert und wir für dieses Jahr schon zu spät sind...


Fachliche Betreuung sollte über das Forum und eMails leicht organisierbar sein. Da sehe ich keine Probleme.

[netzkind]

Aber man müsste dann auch einenn Leistungskatalog zusammenstellen, in dem steht, was der neue Editor können muss. Und wie er aussehen sollte. Sonnst weiss man ja nicht, was man am Ende für sein Geld bekommt.

Wir könnten ja mal einen Wünsch-dir-was Thread zum Editor aufmachen, oder alternativ ein öffentliches Dokument zur allgemeinen Bearbeitung, um mal alle "Anforderungen" zu sammeln die ein Editor in unser aller Augen erfüllen soll. Dann hat man immerhin mal einen Überblick.
Alternativ kann man auch über Feature Requests steuern was zu tun ist, und wer will, kann ernstgemeinte bounties (Prämien) zu einzelnen Feature Requests ausschreiben. Damit bekommt man vielleicht schneller was man selber will, ohne warten zu müssen dass anderer Leute Wünsche umgesetzt werden.

Mich würde so ein WYSIWYG Editor auch wieder reizen, aber ich gehe sowas nicht an, solange mir die Interaktion zwischen Editor und Visu nicht so klar ist, dass sie noch in 24 Monaten läuft.

Grüße,
Julian

[Chris M.]

Wir könnten ja mal einen Wünsch-dir-was Thread zum Editor aufmachen, oder alternativ ein öffentliches Dokument zur allgemeinen Bearbeitung, um mal alle "Anforderungen" zu sammeln die ein Editor in unser aller Augen erfüllen soll. Dann hat man immerhin mal einen Überblick.

Format ist mir egal, so lange das Ergebnis passt.
(Thread hat sicher die geringste Einstiegshürde, halte ich aber zu unübersichtlich. Würde aber die Diskussion gut ermöglichen.
Evtl. ist ein Forum-Lexikon-Artikel dann die beste Lösung - die man auch gut mit Thread kombinieren kann.
Feature Request Tracker dürfte das offensichtlichste und von mir präferierte sein; CV-Wiki wäre aber auch nicht verkehrt)

und wer will, kann ernstgemeinte bounties (Prämien) zu einzelnen Feature Requests ausschreiben. Damit bekommt man vielleicht schneller was man selber will, ohne warten zu müssen dass anderer Leute Wünsche umgesetzt werden.

Klar das steht immer offen.
Wobei ich spontan nicht wüsste wie man hier die beste "Geschäfts-Anbahnung" organisiert.

Mich würde so ein WYSIWYG Editor auch wieder reizen,

Der optimale Editor wäre eine Vereinigung des WYSIWYG (vgl. 0.6) mit dem "externen Editor" (vgl. 0.8-pre)!

Je nach Editier-Aufgabe ist das eine oder das andere Konzept das effizientere.

aber ich gehe sowas nicht an, solange mir die Interaktion zwischen Editor und Visu nicht so klar ist, dass sie noch in 24 Monaten läuft.

Na dann lass uns die doch endlich mal festklopfen!

Was brauchst Du denn?
Vermutlich eine Art von Reflection-API, d.h. in der geladenen Visu den Widget-Baum durchiterieren und von jedem Widget die Attribute abfragen.
Außerdem vermutlich ein Live-Ändern der Attribute und ein ändern des Baums, oder?

Wie soll das API laufen?
Ursprünglich hatte ich an reines JS gedacht - aber vermutlich ist es besser die Visu per IFrame einzubinden, denn dann kann man bewusst geringe IFrame-Größen einstellen um andere Auflösungen (z.B. Touch PC in der Wand) im Editor zu simulieren.
Dann dürfte https://developer.mozilla.org/en/DOM/window.postMessage wohl eine gute Basis für die API darstellen (nach Can I use... Support tables for HTML5, CSS3, etc quasi überall implementiert)

[netzkind]

Na dann lass uns die doch endlich mal festklopfen!

Was brauchst Du denn?
Vermutlich eine Art von Reflection-API, d.h. in der geladenen Visu den Widget-Baum durchiterieren und von jedem Widget die Attribute abfragen.
Außerdem vermutlich ein Live-Ändern der Attribute und ein ändern des Baums, oder?

Die wichtigste Frage die sich mir stellt, ist, wie identifiziert man einen Knoten. Also wenn die GUI sagt "bearbeite Knoten XY", oder der Editor sagt "Element XY hat sich verändert". Wie wird XY ermittelt, so dass es eindeutig ist? Xpath dürfte ausscheiden, ich glaube nicht, dass wir das geparsed kriegen. Jedem Element

Ich hätte noch überlegt, die Visu intern auf JSON umzustellen. Also dass beim Laden der Config alle Knoten geparsed und als Objektstruktur abgelegt werden. Dadurch müssten alle Widgets nicht mehr per jQuery auf das XML zugreifen, sondern per Objektzugriff. Sie könnten außerdem "this" in der Struktur ablegen, so dass man später einfach die Daten im Objekt ändern und ein redraw-Kommando an das Widget senden kann. Außerdem würde es die oben benannte Adressierung lösen, da man nicht adressiert, sondern Referenzen übergibt.
Ich hab noch nicht geschaut, was das für Performance und Speicherbedarf bedeutet, und man würde einen Teil des Editors quasi in die Visu holen (Methoden für redraw, Eigenschaften für editable,...) und es wäre ein major rewrite der Visu notwendig.

Als eigentlichen Editor würde ich weiterhin das nutzen was aktuell im SVN ist, da ich in-place-editing nicht sehe (wie sollte das klappen?), sondern aus der Visu heraus Elemente zur Bearbeitung auswählen würde. Themen wie Sortierung, Copy/Paste müsste man dann noch mal separat betrachten, oder erst mal im Editor belassen.

Das sollte man aber in einem separaten Thread besprechen, also vielleicht kann das einer mit den notwendigen Rechten hier rauslösen und einen Querverweis anlegen.

[netzkind]

Format ist mir egal, so lange das Ergebnis passt.
([..] CV-Wiki wäre aber auch nicht verkehrt)

Sehe ich nicht, da das dann nicht mehr frei editierbar ist, und die Schwelle sich zu beteiligen höher, da man sich erst registrieren/freischalten lassen muss.
Ich dachte, wenn Dokument, an sowas wie öffentliches Google Docs Dokument oder Etherpad.

[Chris M.]

In diesem Thread habe ich die bzgl. Editor-Weiterentwicklung relevanten Beiträge aus Nächstes Release 0.8.0 - wann? verschoben oder kopiert.

[Chris M.]

Ich dachte, wenn Dokument, an sowas wie öffentliches Google Docs Dokument oder Etherpad.

Ist auch ok. Hab mal eines angelegt unter TitanPad: 9JGlZwYeux

[Chris M.]

Die wichtigste Frage die sich mir stellt, ist, wie identifiziert man einen Knoten. Also wenn die GUI sagt "bearbeite Knoten XY", oder der Editor sagt "Element XY hat sich verändert". Wie wird XY ermittelt, so dass es eindeutig ist? Xpath dürfte ausscheiden, ich glaube nicht, dass wir das geparsed kriegen.

XPath halte ich für deutlichen Overkill.

Um die Widgets zu adressieren gibt es schon jetzt ein Schema (vgl. ID Berechnung für die Subseiten):

• Alle Widgets einer Seite werden bei 0 startend durchnummeriert
• Bei einer (Sub-)Seite wird die ID der Seite genommen und per Underscore getrennt die Widget-Nummer auf dieser Seite angehängt

Beispiel "ID_0_10_2":
=> Das zweite Widget auf der Seite, die als zehntes Widget auf der Hauptseite eingebunden wurde.

Was dann ein Widget alles enthält definiert ja die XSD und sind für mich alles Attribute - auch wenn die im XML per Element dargestellt werden müssen um komplexere Datenstrukturen zu erlauben (vgl. Adresse)
Die Ausnahme dieser Regel: Container-Widgets - die dürfen nämlich andere Widgets enthalten. (-> Page und Group)

Ich hätte noch überlegt, die Visu intern auf JSON umzustellen. Also dass beim Laden der Config alle Knoten geparsed und als Objektstruktur abgelegt werden. Dadurch müssten alle Widgets nicht mehr per jQuery auf das XML zugreifen, sondern per Objektzugriff. Sie könnten außerdem "this" in der Struktur ablegen, so dass man später einfach die Daten im Objekt ändern und ein redraw-Kommando an das Widget senden kann. Außerdem würde es die oben benannte Adressierung lösen, da man nicht adressiert, sondern Referenzen übergibt.
Ich hab noch nicht geschaut, was das für Performance und Speicherbedarf bedeutet, und man würde einen Teil des Editors quasi in die Visu holen (Methoden für redraw, Eigenschaften für editable,...) und es wäre ein major rewrite der Visu notwendig.

Hab ich leider noch nicht ganz verstanden, was Du da wie ändern möchtest.

Als eigentlichen Editor würde ich weiterhin das nutzen was aktuell im SVN ist, da ich in-place-editing nicht sehe (wie sollte das klappen?), sondern aus der Visu heraus Elemente zur Bearbeitung auswählen würde. Themen wie Sortierung, Copy/Paste müsste man dann noch mal separat betrachten, oder erst mal im Editor belassen.

Sehe ich auch so.
Der neue Editor ist vom Konzept her genau richtig. Nur das unmittelbare und optisch identische Feedback fehlt halt.

Das sollte man aber in einem separaten Thread besprechen, also vielleicht kann das einer mit den notwendigen Rechten hier rauslösen und einen Querverweis anlegen.

Done.

[netzkind]

Beispiel "ID_0_10_2":
=> Das zweite Widget auf der Seite, die als zehntes Widget auf der Hauptseite eingebunden wurde.

Was dann ein Widget alles enthält definiert ja die XSD und sind für mich alles Attribute - auch wenn die im XML per Element dargestellt werden müssen um komplexere Datenstrukturen zu erlauben (vgl. Adresse)
Die Ausnahme dieser Regel: Container-Widgets - die dürfen nämlich andere Widgets enthalten. (-> Page und Group)

Dem Editor ist das nicht gleich, da gibt es Knoten, und keine Widgets. Für den Editor sind auch nur Attribute Attribute, und Knoten sind keine Attribute, sondern Knoten. Deshalb kann man das Schema nicht einfach übernehmen, es sei denn es gibt im Adressierungs-Baum keine non-widget-Knoten (address als kleinstes Element wird nie adressiert, da es in der Visu garnicht "anklickbar" ist.

Deshalb die Idee, eine Objektstruktur zu erstellen, die sowohl Visu als auch Editor verstehen, und in der keine Elemente identifiziert werden, sondern bei denen einfach das relevante Element selbst übergeben wird. Also statt "bitte Knoten XY bearbeiten"/"Knoten XY neu laden" ein "bearbeite $this und rufe $this.redraw() auf wenn du fertig bist".
Dazu muss aber die Visu umgestellt werden, dass sich die Widgets nicht mehr am XML bedienen, sondern an einer neuen Abstraktionsschicht die eben den kompletten Baum als Objekte darstellt.

[Chris M.]

Für mich gibt es im Addressierungs-Baum nur Widgets, sonst nichts. (Zumindest was unter dem obersten <page /> liegt, <meta /> ist natürlich die Ausnahme der Regel - aber das ist im WYSIWYG auch nicht greifbar).

Und ein Widget gibt es in genau zwei Varianten (verallgemeinerbar sogar auf eine einzige):

• Container-Widget - kann und wird als Knoten im Addressierungs-Baum auftauchen; aktuell gibt's nur <page> und <group>, in Zukunft könnte man sich evtl. noch ein <popup> vorstellen.
• Widget - ist immer Blatt und das relevante für die meisten Widgets

Die in der Config da drunter existierende XML-Struktur ist nur für die Config. Die ist für mich auch nicht mehr einzeln anklickbar, das ist integraler Bestandteil eines Widgets.


Welche "non-widget-Knote" könntest Du Dir denn vorstellen?