Editor-Entwicklung

[Chris M.]

Siehe SVN. So ein paar Zeilen Code sind dazugekommen.

Super

Beim Spielen sind mir v.a. zwei Sachen aufgefallen:

1. Ich finde das UI noch nicht intuitiv.
   Zumindest unterm Chromeium (hab nur damit getestet) muss ich rechts klicken um z.B. neue Elemente hinzufügen zu können, das Popup(?) erscheint aber ganz tief unten am Bildschirm, so dass ich dorthin scrollen muss...
   Grundsätzlich ist auch alles sehr groß und somit für mich viel verschwendeter Platz auf dem Inhalt sein könnte. Es gibt auch riesige leere Flächen.(*)
   
   Zum Glück alles wohl leicht und schnell lösbar...
   Neben einer allgemeinen Design-Optimierung würde ich mir die Kontext-Menü-Punkte (die sind gut, sparen Maus-Bewegung!) parallel noch als Icons/Button wünschen, so dass man ohne Wissen um des Kontext-Menüs die auch selbsterklärend erreichen kann.
2. Beim Speichern kommt nun "The configuration is not valid, and as such can not be saved.". Fairer Punkt - aber wenn die mir nicht sagt wo, muss ich mir nun einen Wolf suchen...
   
   GGf. macht es Sinn Muss-Felder halb-sinnvoll vorzubefüllen (und wenn's nur Page-Name=Page1 bis Page99 ist...), so dass der User immer speichern drücken darf.

--
(*) Ist das ggf. einer gewünschten Pad-Bedinung geschuldet? Finde ich gut - aber geht z.Zt. deutlich zu lasten einer PC+Maus-Bedienung, die ich noch für einige Zeit als Hauptnutzung sehe

[swiss]

Hallo Julian

Ich habe gerade mal ein SVN Update gemacht. Leider kann ich nun den Editor nicht mehr aufrufen.

Bei mir hängt er bei der Meldung:

Loading and validating configuration, this may take several seconds...

Muss man der URL noch einen Parameter mitgeben?

EDIT: Hab den Fehler gefunden... Ich habe alle Iframe-Widgets aus der Config entfernt nun lädt der Editor

[netzkind]

Das nächste SVN-Commit wird schon speichern können. Wenn alle brav sind, gibt es das vielleicht noch zu Weihnachten (!= Heiligabend).

Siehe SVN. So ein paar Zeilen Code sind dazugekommen.

Und ja, ich hab mich der Anmerkungen zur Seitenaufteilung angenommen - sieht man aber erst über 1200px Browserbreite.

Grüße,
Julian

[vlamers]

Na ich hab auch nicht behauptet ihn benutzen zu wollen
Ich befand mich gerade dabei meine metal config weiter zu bauen und dachte ich kann mich mal wieder auf den neuesten Stand bringen.
Da in dem Thread einige kommentare über das design sind, hab ich mir gedacht, dass er zumindest soweit kommen sollte....

ich wollt nur gucken

Gruß

[netzkind]

woran könnte das scheitern?

Bekannter Fehler: iframes.
Werden in der Config in Kürze durch "web" ersetzt. Siehe entsprechender Thread.

Makki hat dennoch Recht

Das nächste SVN-Commit wird schon speichern können. Wenn alle brav sind, gibt es das vielleicht noch zu Weihnachten (!= Heiligabend).

Grüße,
Julian

[makki]

Hmm, ich kann mich nicht erinnern, das jemand gesagt hätte, das der neue Editor schon benutzbar wäre Sorry..

Makki

[vlamers]

Hallo,

wollte heute mal den neuen Editor testen.
Leider startet er bei mir gar nicht er bleibt beim: "Loading and validating configuration, this may take several seconds..." hängen.

Folgende Fehlermeldung:

Uncaught TypeError: Cannot read property 'document' of undefined

Mit Bezug auf die: jquery.js zeile5553

Folgendes Codefragment befindet sich dort:

contents: function( elem ) {
		return jQuery.nodeName( elem, "iframe" ) ?
			elem.contentDocument || elem.contentWindow.document :
[COLOR="Red"]Uncaught TypeError: Cannot read property 'document' of undefined[/COLOR]
			jQuery.merge( [], elem.childNodes );
	}

getestet im Chorme und FF

woran könnte das scheitern?

Danke

Gruß

[makki]

Hallo,

ob du es glaubst, oder nicht Makki, man kann auch zur Entwicklung beitragen, ohne zu coden.

Das glaube ich durchaus! das kann ich sogar beweisen, die meisten hilfreichen Beiträge zu eibd, owfs&Co von mir waren nicht Code sondern "nur" qualifizierte Bugreports (ok, bei owfs musste ich dann am Ende trotzdem selber..)

Nach meinem -zugegeben mangeldem- Verständnis muss im Editor-Modus doch lediglich ein "edit", ein "X" und ein kleines Quadrat an jedem und ein Rahmen um jedes Element angezeigt werden. Dies ist doch nicht design-spezifisch, oder?

Ehrlich, ich auch nicht

Und das funktioniert doch schon.

Hmm, mit einigem Aufwand..
Lass Dich mal überraschen, wir meinen denke ich dasselbe, nur ein bisschen anders umgesetzt ( mit erheblich weniger Aufwand )

wie ich ohne den WYSIWYG Editor ein ansprechendes Design hinbekommen soll. Da wäre das schon ein großer Mehrwert.

Der soll nicht verloren gehen, nur anders, einmal klicken +3s dürfte Ok sein, oder?

Makki

[henfri]

Hallo,

ob du es glaubst, oder nicht Makki, man kann auch zur Entwicklung beitragen, ohne zu coden.
Gerade letzte Woche habe ich einfach nur durch kritisches Hinterfragen und nachbohren bei einem Thema von dem ich nur begrenzt Ahnung hatte meinen Gesprächspartner auf eine patentwürdige Idee gebracht.

Deshalb mache ich das hier jetzt auch mal.

Nach meinem -zugegeben mangeldem- Verständnis muss im Editor-Modus doch lediglich ein "edit", ein "X" und ein kleines Quadrat an jedem und ein Rahmen um jedes Element angezeigt werden. Dies ist doch nicht design-spezifisch, 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.

Und das funktioniert doch schon.

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.

Und wenn der Editor nur im Standard-Design funktioniert?
Dann kann man zumindest damit anfangen. Ganz ehrlich: Ich habe keinen Schimmer, wie ich ohne den WYSIWYG Editor ein ansprechendes Design hinbekommen soll. Da wäre das schon ein großer Mehrwert.

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.

Aber das gilt doch für jeden Editor, ob WYSIWYG oder nicht.
Der aktuelle (Release) Editor springt doch auch in eine neue Ansicht wenn man die Parameter editiert.

Gruß,
Hendrik

[makki]

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.

Eben.. Deswegen ist es so wie es ist..
Henfri steht es frei, eine Zeile code beizusteuern, die es besser macht

Ich bin guter Dinge, das es wieder eine "preview" gibt, wenns mal fertig ist! Den Punkt bin ich aber nur bereit zu diskutieren - wenn schonmal eine Zeile kam

Makki

[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

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

[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

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

[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