Editor-Entwicklung

[Chris M.]

Auch das steckt schon in der Ideenschublade, hängt aber von der Performance ab, und ob wir eine saubere, dauerhafte (im Sinne von regression-fest) Schnittstelle vom Editor zur Visu hinbekommen.

Schlag mal vor, welche "Befehle" Du so brauchst. Da könnten wir ja evtl. eine API bauen.

Was genau meinst du hier mit "interaktiv"?

Das Drag&Drop der Widgets war sehr schön. Und bei 2D-Seiten IMHO auch bei externem Editor notwendig, da hier kaum jemand die Pixel-Koordinaten per Hand eingeben möchte...

Ansonsten würde mir vorschweben, dass bei Auswahl einer Page bzw. Widget im Tree auf die entsprechende Seite der Visu gesprungen wird bzw. das Widget dort gleich irgendwie hervorgehoben wird. Und umgekehrt.

[netzkind]

Schlag mal vor, welche "Befehle" Du so brauchst. Da könnten wir ja evtl. eine API bauen.

So weit bin ich noch nicht - das ist ein Problem späterer Tage

Das Drag&Drop der Widgets war sehr schön. Und bei 2D-Seiten IMHO auch bei externem Editor notwendig, da hier kaum jemand die Pixel-Koordinaten per Hand eingeben möchte...

FYI: 2D und 3D haben für den Editor bislang keine Prio.
Soweit ich das sehe, sind Koordinaten bislang nicht mal Teil des XSD.

Drag&Drop sehe ich nicht als WYSIWYG.

Ansonsten würde mir vorschweben, dass bei Auswahl einer Page bzw. Widget im Tree auf die entsprechende Seite der Visu gesprungen wird bzw. das Widget dort gleich irgendwie hervorgehoben wird.

Das ist dann eine Frage der Kommunikation, womit wir wieder bei der API sind, die jetzt noch nicht spezifiziert wurde. Was die Templateengine dann macht wenn der Editor sagt "zeig Element XY an" steht ihr dann aber frei

Und umgekehrt.

Sehe ich nicht.

Wie gesagt, Ziel ist erst mal ein rock-solid editor, dem die Templateengine "am ***** vorbeigeht". Lieber mache ich einmal ein Screencast dazu wie man den verwendet, als dass ich alle 2 Monate erkläre, wieso er schon wieder nicht mehr funktioniert - oder besser noch ständig hinterherarbeite.

[perf]

Die richtige Lösung ist, dass das alles in die XSD gehört.
Wenn's nicht drinnen ist, darf's aber auch nicht in die Demo-Config - denn die sollte immer valide sein!

Wer kann wgplugin_info in die XSD bringen?

/Per

[Chris M.]

So weit bin ich noch nicht - das ist ein Problem späterer Tage

Richtig, im Zweifel erst zum übernächsten Release.

FYI: 2D und 3D haben für den Editor bislang keine Prio.
Soweit ich das sehe, sind Koordinaten bislang nicht mal Teil des XSD.

Der Editor soll natürlich 2D und 3D können - genau in dem Umfang, wie die in der XSD stehen...

In der Demo-Config ist übrigens 2D schon drinnen - wichtigster Unterschied zu Text: die Koordinaten stehen im <layout>. Und das kann bereits x, y und z...

Das ist dann eine Frage der Kommunikation, womit wir wieder bei der API sind, die jetzt noch nicht spezifiziert wurde. Was die Templateengine dann macht wenn der Editor sagt "zeig Element XY an" steht ihr dann aber frei
[...]
Wie gesagt, Ziel ist erst mal ein rock-solid editor, dem die Templateengine "am ***** vorbeigeht".

Widerspricht sich ja nicht. Dem Editor kann und soll die templateengine egal sein. Und wenn's die API gibt, trotzdem mit der herrlich kommunizieren

[iwan]

=> Vorschlag wäre das UI zweiteilen:
Links den TreeView und rechts die Attribute (vergleichbar Windows Explorer, eMail Clients, ...)

sag ich ja ;-)

Iwan

[henfri]

Hallo,

schön, dass es mit dem Editor weiter geht! DANKE!

Ich habe den Editor gerade mal ausprobieren wollen, scheitere aber leider:

The configuration appears to be not valid. Please check with 'check_config.php' for details. Error: 'xsd does not match this configuration, or configuration is not valid for #text'

Im Anhang die Konfiguration, die ich getestet habe.
(Ist für mich nicht wichtig, da nur eine Metal-Demo; Wollt nur beim Entwickeln helfen)


Gruß,
Hendrik

[henfri]

Hallo nochmal,

mit meiner Konfiguration läuft der Editor.
Zwei Dinge, die mir aufgefallen sind:
Es wäre super, wenn ein Copy&Paste von Blöcken möglich wäre. Viele Seiten werden ja sehr ähnlich mehrmals vorkommen (z.B. erzeugt man einen Raum und kopiert den mehrmals und passt dann die GAs an).

Und: Es wäre toll, wenn man die GAs wieder auswählen könnte (drop-Down) und der DPT dann automatisch gewählt würde.

Aber nochmal: Toll, dass es weiter geht!

Gruß,
Hendrik

[makki]

-> Wird es für einen nächsten Release einen Konverter geben der die alten Konfigs automatisch "kompatibel" macht?

Das ist durchaus angedacht, wünschenswert (und IMHO machbar.. also vom Release zu nächsten, zwischendrin: )
Dafür sind aber erstmal jetzige strukturelle Schwachstellen in XML&XSD auszuräumen, was Julian ja gerade macht..
Ein "Preview" kann man dann zum schluss recht einfach machen, so der Plan..

Ich habe den neuen Editor kurz angeschat.

Hm... ich möchte ja niemenden zu nahe treten, aber mir war der Editor in der Release Version einiges sympatischer.

Wieso das Rad neu erfinden? Habe ich was verpasst?

Ich denke besonders auch an die "reinen" User, das "Drag and Drop", mit 1:1 Preview war schon klasse.

Nun, Julian hats schon gesagt, ich sags mal mit anderen Worten: Die Visu läuft dem Editor ständig davon, da hat keiner was von, also ist ein universeller Ansatz zu finden, damit man den Editor nicht wegen jedem Pups auch anpassen muss..

Richtig, im Zweifel erst zum übernächsten Release.

jow..

Der Editor soll natürlich 2D und 3D können - genau in dem Umfang, wie die in der XSD stehen...

Jetzt mal ehrlich? 30/70 - Malprogramme für Sehenscheidentzüdungs-Freunde in 2D/3D gibts schon genug, mein Fokus liegt auf "geht einfach". PC-Verkäufe sind 20% Rückläufig, aufm 4-7" dings muss ich nix malen, da steht eins unter dem anderen zwecks Übersicht, fertig..

Natürlich gibt es andere, anspruchsvollere Typen, die ihr Hobby darin sehen jeden Pixel optimal zu positionieren, die dürfen sich wegen mir auch austoben (können sie ja auch, da kommen echt tolle Sachen wie das Metal-Design bei raus!!) - aber Koordinaten haben -mit Verlaub - in der Visu-config für den Anwender nichts zu suchen.. (und damit im Editor, ist eine Frage des Designs, für den Rest gibts Photoshop)

Makki

[makki]

@henfri: Dropdown-GA ist natürlich ganz oben auf der Liste aber das ist einfach, Julian macht gerade den eher schwierigen Teil WiP..

Makki

[netzkind]

Hi Hendrik,

Im Anhang die Konfiguration, die ich getestet habe.

beim Kopieren des XML scheint es offenbar zu einem Fehler gekommen zu sein - die Daten sind nicht mehr wirklich XML. Schaut so aus, als wolltest du das XML aus dem Browser heraus kopieren: in dem Fall bitte immer den Quellcode der Seite kopieren (Firefox: STRG+U, Mac-Firefox CMD+U; andere Browser haben das meist entweder im Rechtsklick-Kontextmenü oder unter Ansicht versteckt).

Zu deinen Ergänzungsvorschlägen: die DEVELOPMENT.txt hält bereits einiges davon per TODO für eine arbeitsreiche Zeit bereit

Grüße,
Julian

[netzkind]

Darf ich mal kurz einhaken:

 Error: 'xsd does not match this configuration, or configuration is not valid for #text'

Macht nicht besonders schlau da mir check_config sagt dass alles gut ist. Gibt es da einen Anhaltspunkt ?

Keinen den der Anwender sehen könnte, bislang.
In dem Fall habe "ich" mit deiner Konfiguration zwei Probleme:
- Kommentar-Knoten im XML - das bekomme ich dem Editor problemlos beigeboben
- group-Elemente mit mehreren layout-Elementen; sollte eigentlich per XSD verboten sein, ist es aber nicht (bei Interesse vgl. https://knx-user-forum.de/cometvisu/...minoccurs.html)

Das mit den Kommentar-Knoten habe ich schon ins SVN eingecheckt (Revision 1168), beim anderen stehe ich noch da und kratze mich am Kopf ... als Quickfix kannst du in der Group bei "Terasse" das zweite layout-Element entfernen - die zwei sind identisch, und nach meiner Interpretation dürfte die doppelte Aufführung des Elements auch keine Auswirkungen haben.

Und bei deiner Konfiguration fällt mir auf, dass mein Rechner hier schlanke 10 Sekunden braucht um sie zu laden und zu validieren ... vielleicht merke ich mir das mal zur späteren Performance-Optimierung ...

Grüße,
Julian

[Chris M.]

beim anderen stehe ich noch da und kratze mich am Kopf ... als Quickfix kannst du in der Group bei "Terasse" das zweite layout-Element entfernen - die zwei sind identisch, und nach meiner Interpretation dürfte die doppelte Aufführung des Elements auch keine Auswirkungen haben.

2x <layout> in einem Element ist als Bug anzusehen und zu fixen, das Ergebnis davon ist undefiniert.

Wenn die XSD das (noch) nicht als Fehler findet, dann müssen wir die verbessern.

[henfri]

Hallo,

Nun, Julian hats schon gesagt, ich sags mal mit anderen Worten: Die Visu läuft dem Editor ständig davon, da hat keiner was von, also ist ein universeller Ansatz zu finden, damit man den Editor nicht wegen jedem Pups auch anpassen muss..

Warum ist das eigentlich so?
Ich meine:
Ein Anwender erzeugt ein neues Design. Dazu muss er x,y und z machen (keine Ahnung was..). Offensichtlich reichen x,y und z nicht aus, dass dann der Editor auch funktioniert.
Was wären a, b & c, die er noch machen müsste, damit der Editor weiterhin funktioniert?

Ich meine: Welche zusätzlichen Informationen/Methoden benötigt der Editior für seine Funktion ggü der eigentlichen Visu? Das kann doch eigentlich nicht so viel sein, oder?

Gruß,
Hendrik

[swiss]

Ich finde den neuen Editor einen interessanten Ansatz. Auch wenn ich die Vorschaufunktion etwas vermisse. Aber mann gewöhnt sich an alles. Auf jeden Fall DANKE für die tolle Arbeit

Hier noch eine Frage: Wie ist das verschieben der einzelnen Widgets angedacht? Drag&Drop oder mit Pfeilen hoch/runter?

[netzkind]

Ein Anwender erzeugt ein neues Design. Dazu muss er x,y und z machen (keine Ahnung was..). Offensichtlich reichen x,y und z nicht aus, dass dann der Editor auch funktioniert.
Was wären a, b & c, die er noch machen müsste, damit der Editor weiterhin funktioniert?

Das kann man wohl nicht generell sagen. Das bedeutet, dass jeder Entwickler, der Kleinigkeiten an Designs oder Widgets ändern will, sich damit beschäftigen muss, dass es im Editor funktioniert. Und dazu ggf. erst in den Editor einarbeiten, bzw. in die Kommunikation zwischen Visu und Editor. Ich glaube nicht, dass ein Designer der wenig Ahnung von Javascript hat sich das antun will. Was bedeutet, dass ein Design wie Metal möglicherweise nie entstehen würde, was schade wäre.

Deshalb ist entkoppelter Code gut für das Gesamtergebnis.

Ich meine: Welche zusätzlichen Informationen/Methoden benötigt der Editior für seine Funktion ggü der eigentlichen Visu? Das kann doch eigentlich nicht so viel sein, oder?

Möglicherweise verstehe ich die Frage nicht richtig, aber der Editor braucht verdammt viele strukturierte Informationen zur Konfiguration, muss die einzelnen Widgets auf dem Bildschirm finden, deren visuelle Grenzen kennen, die programmatischen Grenzen (welches div gehört noch dazu, und ist es überhaupt ein div?), und die der Eltern und Geschwister. Zusätzlich braucht der Editor Platz für seine eigenen Eingabelemente in direkter Nähe zum Widget. Das ist von Design zu Design anders, von Widget zu Widget,und teilweise auch nochbauf unterschiedlichen Seiten der Visu anders als auf anderen. Ohne das eine Ende meiner Aufzählung absehbar wäre, braucht der Editor auch ein inneres Verständnis davon, was ein Widget ist, welche Elemente dazu gehören (bspw. ein address-Element in einem switch), und wie das alles in der Darstellung im Browser zusammenspielt.

Kurzum: klar kann man auch wieder WYSIWYG machen, aber dann macht man das Ökosystem der Visu für andere Entwickler wesentlich schwerer verständlich. Die Einstiegshürde steigt, und wir haben zwar einen schöneren Editor, aber weniger Personen die sich an der aktiven Entwicklung beteiligen.

Grüße,
Julian