Erstes Feedback einholen

[nittka]

@GWRon, @jukey: Ich habe im Edior-Repository eine Readme für das Aufsetzen hinterlegt. Da man aktuell den Editor noch selbst bauen muss, ist es etwas aufwändiger als es final sein wird. Ich würde mich dennoch freuen, wenn Ihr es mal ausprobiert. Bei Fragen und Problemen stehe ich natürlich zur Verfügung.

Im Laufe der Zeit werde ich Features ergänzen und erweitern. Der Mechanismus für diese Updates (Pull im Editor-Repository, etc.) sind noch nicht beschrieben. Mittelfristig werden diese Schritte wohl aus der Readme ins Wiki wandern.

[GWRon]

Hmm das ganze wirkt von der Beschreibung her, als wenn es ein textbasierter Editor ist. Also aehnlich eines Programmiersprachen-Editors.

Das mag fuer uns ja schon eine Unterstuetzung sein..ist aber nix, mit dem sich Otto-Normalbuerger beschaeftigen woellte.

Inwieweit kann das alles am Ende "dau"-freundlich gemacht werden?

[GWRon]

XML Generierung ... done

Wenn ich dann trotzdem (siehe links - zwei Bereiche fehlerhaft) launchen woellte:

problems:

[nittka]

Hmm das ganze wirkt von der Beschreibung her, als wenn es ein textbasierter Editor ist. korrekt Inwieweit kann das alles am Ende "dau"-freundlich gemacht werden? Darauf kann ich keine zufriedenstellende Antwort geben. Für mich ist das der erste Schritt, überhaupt die verfügbaren Einstellungen und Zusammenhänge kennenzulernen. Für mich ist der Aufwand, einen solchen Texteditor mit Frameworkunterstützung zu schreiben ungleich leichter, als einen Standalone-GUI-Editor.

Für mich ist dieser Editor also zunächst Rapid-Prototyping; Diskussionsgrundlage für "Best-Practice", welche Konfigurationswerte vielleicht wegen geringer (oder entfallener) Nutzung rausfliegen können, welche "Standardtemplates" für News, Programme etc. benötigt werden. Auf dieser Basis könnte dann ein "einfacher" Editor entstehen, der nur das Nötigste unterstützt; vielleicht auch nur das Ergänzen eigener Elemente. Es ist ein wenig das Henne-Ei-Problem - wieviele der Spieler sind im Formum aktiv, wieviele verirren sich auf Github, wievel Aufwand möchte man in Tooling investieren, das am Ende vielleicht niemand nutzt (Zeit, die auch in die Verbesserung des Spiels hätte fließen können).

[nittka]

XML Generierung ... done Welche Eclipse-Distribution hast Du verwendet? Bei der Java-Entwicklerversion sollte der View links eigentlich der Package-Explorer sein und nicht der Project Explorer. (Und Du bist auch noch im "ersten" Eclipse; nicht im Runtime-Eclipse, oder?) Öffne mal die Java-Perspektive. Wenn dann im Package-Explorer alle Projekte auf der obersten Ebene sichtbar sind, ist es schon besser. (die beiden Test Projekte könntest Du per Kontext-Menü auch einfach schließen)

Wenn weiterhin nur das parent-Projekt sichtbar ist, öffne bitte das Kontextmenü auf dem Parent-Projekt und wähle "Import Projects". (ggf. den nested-projects-Haken setzen) Es müssen alle Projekte selektiert sein.

[GWRon]

Ich habe die C-Variante / Flavor der eclipse Community 2020-12 Version drauf gehabt. Sollte genauso funktionieren.

[nittka]

Du kannst auch einfach mal probieren, das Runtime-Eclipse trotz der Fehler (die Testprojekte sind für den Editor nicht relevant) zu starten. Die Datenbank-Dateien werden allerdings nur "fehlerfrei" sein, wenn Du den cleanup-Branch des PRs verwendest. Ansonsten bekommst Du die Probleme zu sehen, die ich in dem Branch beheben will.

[GWRon]

Der Fehler von Bild drei ist der, wenn ich trotzdem launchen wollte.

[nittka]

"Proceed" sollte eigentlich funktionieren. Wie gesagt, sieht es so aus, als ob die Compile-Fehler nur in den Testprojekten sind, die für die Editor-Funktionalität nicht relevant sind.

[GWRon]

"Proceed" hatte ich natuerlich probiert - und dann kommt obiger Fehlerlog. In Textform sieht der dann so aus:

!SESSION 2021-04-09 22:34:53.543 -----------------------------------------------
eclipse.buildId=4.18.0.I20201202-1800
java.version=11.0.10
java.vendor=Ubuntu
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=de_DE
Framework arguments:  -product org.eclipse.platform.ide
Command-line arguments:  -product org.eclipse.platform.ide -data /home/ronny/eclipse-workspace/../runtime-EclipseXtext -dev file:/home/ronny/eclipse-workspace/.metadata/.plugins/org.eclipse.pde.core/Launch Runtime Eclipse/dev.properties -os linux -ws gtk -arch x86_64

!ENTRY org.eclipse.equinox.http.jetty 4 0 2021-04-09 22:34:58.387
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: Could not resolve module: org.eclipse.equinox.http.jetty [145]
  Unresolved requirement: Import-Package: org.eclipse.jetty.servlet; version="[9.4.0,10.0.0)"
    -> Export-Package: org.eclipse.jetty.servlet; bundle-symbolic-name="org.eclipse.jetty.servlet"; bundle-version="9.4.35.v20201120"; version="9.4.35"; uses:="javax.servlet,javax.servlet.descriptor,javax.servlet.http,org.eclipse.jetty.http.pathmap,org.eclipse.jetty.security,org.eclipse.jetty.server,org.eclipse.jetty.server.handler,org.eclipse.jetty.server.handler.gzip,org.eclipse.jetty.server.session,org.eclipse.jetty.util,org.eclipse.jetty.util.annotation,org.eclipse.jetty.util.component,org.eclipse.jetty.util.resource"
       org.eclipse.jetty.servlet [204]
         Unresolved requirement: Import-Package: org.eclipse.jetty.jmx; version="[9.4.35,10.0.0)"; resolution:="optional"
         Unresolved requirement: Import-Package: org.eclipse.jetty.util.ajax; version="[9.4.35,10.0.0)"

    at org.eclipse.osgi.container.Module.start(Module.java:463)
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1845)
    at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136)
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1838)
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1779)
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1743)
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1665)
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
    at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)
    at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345)

!ENTRY org.tvtower.db.tests 4 0 2021-04-09 22:34:58.543
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: Could not resolve module: org.tvtower.db.tests [437]
  Unresolved requirement: Require-Bundle: org.junit.jupiter.api; bundle-version="[5.0.0,6.0.0)"

    at org.eclipse.osgi.container.Module.start(Module.java:463)
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1845)
    at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136)
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1838)
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1779)
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1743)
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1665)
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
    at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)
    at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345)

...

[GWRon]

Es hat aber beim initialen Setup maven installiert (dazu aber zwei Fenster aufgeploppt - dann nochmal 4 Fenster, dass es was aktualisieren muss - konnte nur eines fortsetzen, das andere dann schliessen - und danach konnte das fortgesetzte die Lizenzbestaetigung anzeigen -- und installieren).

Ich mag Eclipse schon seit vielen Jahren nicht ... liegt aber generell an meiner Ablehnung von toolchains und "eierlegenden Wollmichsaeuen". Den gleichen Mist hat man auch mit IntellJ (bzw Android Studio etc) und Visual Studio (Code).

Schon alleine der Umfang der Anleitung um einen Editorprototypen zu starten ... ist durchaus abschreckend (auch wenn Du wirklich Schritt fuer Schritt versuchst zu erklaeren). Wenn man die IDE nicht nutzt schaut man echt drauf und muss jeden Minischritt in der Anleitung nachlesen um ja nix falsch zu machen.

Und wenn man die Eclipse IDE schliesst:

Wie gesagt - C/C++-Edition, das sollte aber an sich nicht relevant sein. Kanns aber natuerlich trotzdem. Muss also uebern Mittag mal die Javavariante dazuholen.

[nittka]

Ja, versuche es bitte mit der Java-Edition. Der Aufwand ist auch so hoch, da in diesem Aufbau der Editor selbst gebaut werden muss. Das Oomph-Setup könnte auch erweitert werden, dass der Generierungsschritt automatisch ausgeführt wird - das hilft aber nur bedingt, da man bei Grammatik-Änderungen auch wieder manuell generieren muss. Es ist immer eine Abwägungsfrage "Aufwand für mich" vs. "Aufwand für dich".

Wenn der Editor fertig wäre, könnte das Setup den Eclipse-Editor insallieren, das TVTower-Repo klonen und importieren, so dass man dann "ersten" Eclipse selbst die Datenbankdateien editieren kann.

[nittka]

Achtung - wegen der Windows-Abhängigkeiten in der Launch-Runtime-Eclipse-Konfiguration wirst Du dieselben Probleme wie @jukey bekommen. Siehe #3 ... Am Ende ist es doch weniger aufwändig, wenn ich eine temporäre Updatesite zur Verfügung stelle, mit der Ihr testet.

[GWRon]

Soweit funktioniert das.

Ein eventueller "fertiger" Editor - waere das dann eine "jar" oder muss das immer ueber Eclipse laufen?

Wie schaut moegliche UI-Unterstuetzung aus?

Fuer "Normalnutzer" waere ja eher etwas mauslastigeres von Vorteil - wie mein rudimentaerer Editor der direkt die Quellcodes von TVTower anzapft (und somit weiss, was TVTower weiss).

Ich hoffe, dass dein Aufwand es dann ermoeglicht, automatisch Listen zu fuellen und zu aktualisieren (Stichwort "Trigger" und "Newsketten"). Nicht dass am Ende nur ein XML-Editor rauskommt, der die TVTower-Eigenheiten kann und Tooltips gibt. Das hilft dann wohl wirklich nur denen, die "wissen", was machbar ist - sprich die Interna von TVT schon kennengelernt haben.

[nittka]

Ich glaube, der Aufwand daraus einen Standalone-Editor oder eine GUI-Editor zu machen wäre weiter ziemlich hoch. Wie weit ist denn Dein rudiementärer Editor. Selbst wenn die Xtext-Variante dann nicht für alle Nutzer interessant wäre, lässt sich dort leicht Validierung einbauen (siehe meine PR - solche Sachen wie die nicht existierenden Nachfolge-News bekommt man fast geschenkt). Analog zu dem TVTDictionary-Check könnte dieser Editor mindestens zur Konsistenzprüfung verwendet werden.

[GWRon]

Der is nicht viel weiter...seit 4 Jahren. Das Problem ist die ganze GUI-Interaktion und dynamische Listen.. Einfach enormer Aufwand.

Gleiches gilt fuer die ganze Widget-Anordnung.

Naja..und validieren muss man sicher auch...

[nittka]

Ich mache dieses Ticket mal zu. Der Prozess ist in Gang gesetzt.