GUI für nodeMCU

Guten Morgen!

Sooo... nach vielem Lesen und Überlegen bin ich nun mit neuen Erkenntnissen zurück, bei diesem Thema: Bytecode.
Ich würde sagen: ja, es entsteht ein Bytecode. Das ist völlig richtig; auch "Bytecode-Interpreter".

Den Begriff Zwischencode würde ich hier aber ausklammern. Weil nichts mehr umgewandelt wird. Es ist ein endgültiger (Steuer)Code für den Interpreter. Am Ende wird Maschinencode von der CPU ausgeführt, aber der Code wird nicht in solche übersetzt.

Du beschreibst es mit: "ähnlich macht es ... " schon ganz richtig. Aufsteigend in Abstraktionsebenen werden Verarbeitungsschritte immer ähnlicher. An oberster Stelle können Symbole stehen, die in irgendeiner Weise angeordnet werden. Bei Programmablaufplänen ist es auch so. Interessanter Weise ist damit Inkas Frage nach, bzw. der Hinweis auf die Möglichkeit der Erstellung von PAPs gar nicht so weit weg. Zumindest nicht in der Richtung, was den Bytecode-Interpreter angeht. Ich habe da noch mal in den Quelltext rein geschaut. Die PAP-Geschichte war mal durchaus als Drag and Drop angelegt. Diese Vorgehensweise hat aber nie den Durchbruch gefunden. Statt dessen habe ich mich für eine einfachere Platzierung der Symbole, durch Klicken, entschieden. Ich habe mich damals viel an meinem kleinen Laptop orientiert, der zwar ein Touchpad hat, aber wo ich nie eine Maus verwendet habe, da war es mit Symbolen schieben eher schwierig.

Gruß

- - - Aktualisiert - - -

Ich habe mal einen PAP raus gesucht und eine Bildschirmkopie gemacht, für diese Abbildung hier, der nur klein ist und als Beispiel dient:

Bild hier  

Mit den PAPs habe ich damals die Umsetzung der Programmierung, mit Grafiksymbolen, geübt. Um das mal so zu sagen.
Ich wusste nicht, ob und wie man damit würde umgehen können. Fand aber den Ansatz äußerst interessant. So dass ich mich lange Zeit damit beschäftigt habe, bis es schlussendlich auch gebrauchsfertig war. Ich habe dann praktisch erfahren, dass ein PAP einen Ablauf gut beschreiben kann, aber als Grundlage zum Programmieren (als Eingabevariante, statt einem Texteditor) nur bedingt gut geeignet ist. Ich denke, das Handling mit einem Ablaufplan funktioniert erst ab einer bestimmten Abstraktionsebene gut. Ich habe versucht, das auf die Befehlsebene einer Programmiersprache anzuwenden. Das ist ähnlich, wie mit Objekten in den Baumabbildungen. Nur das Objektbäume kompakter und übersichtlicher sind. Bei den Ablaufplänen habe ich vor allem Probleme, mit dem zur Verfügung stehenden Platz, auf dem Bildschirm. Es sind relativ wenige Informationen unterzubringen. Man muss dann sehr oft zwischen PAPs wechseln, was unübersichtlich werden kann, weil ein sehr komplexer Programmablauf als PAP in seiner Gesamtheit nicht sinnvoll abzubilden ist.

Moin!
Kennst du die Programmierumgebung "RoboPro" von Fischertechnik? Die mach es praktisch genau so, mit PAP-Symbolen.
Scratch und Lego-GPLs ähnlich, aber mit abgewandelten PAP-Symbolen.
Die großen Grafik-Symbole snd aber sehr platzraubend und bei komplizierteren Programmen schnell unübersichtlich mit den ganzen Verbindungschnurknäueln, spätestens, wenn sie sich mehrfach überschneiden. Dies auf reinen Script-Text zu reduzieren finde ich weitaus besser.

Zitat:

---

Zitat von Moppi

Interessanter Weise ist damit Inkas Frage nach, bzw. der Hinweis auf die Möglichkeit der Erstellung von PAPs gar nicht so weit weg. Zumindest nicht in der Richtung, was den Bytecode-Interpreter angeht. Ich habe da noch mal in den Quelltext rein geschaut. Die PAP-Geschichte war mal durchaus als Drag and Drop angelegt.

---

ich hätte es halt interessant gefunden, wenn aufgrund eines PAP zumindest die grobe struktur des codes selbst erzeugt werden würde - oder auch umgekehrt...

nur ein Gestaltungs-Tipp:
ich würde die Ressourcen/Rubriken in eine linke Fenster-Spalte schreiben und den programmierten Programmstapel rechts davon.
Text-Ausgaben des Programms (ähnlich Serial Monitor) und Grafik-Dashboard etc. (ggf wie bei Processing oder per Rundinstrumente oder per Koordinatensysteme oder Turtle-Grafiken) könnten dann in einen 3. Bereich unten drunter angezeigt werden.

Für den Fall, dass es noch nicht bekannt ist, wie der Aufbau der Oberfläche aussieht, folgendes.

Es ist nicht ganz einfach, mit den Darstellungseigenheiten der unterschiedlichen Webbrowser, ein einheitliches Design hinzubekommen, das in jedem Browser zum gewünschten Ergebnis führt. Aus dem Grund bin ich hier schon dazu übergegangen, Frames einzubauen, die dann automatische Bildlaufleisten bekommen, wenn der Inhalt größer ist, als der Bildausschnitt.

Bild hier  

9: Ganz oben ist eine Statuszeile, mit zwei Reglern, um die Bereiche, horizontal, in der Breite verstellen zu können. Hier werden auch Informationen in Textform angezeigt.

8: Menüzeile. Ich habe Menüs ganz raus genommen. Weil ich denke, dass die wichtigen Funktionen einfach oben in einer Zeile Platz finden. Darüber lässt sich nun im Grunde die ganze Oberfläche bedienen.

7: Ein weitgehend frei zu gestaltender Bereich. Im Grunde ist nicht festgelegt, wo was stehen soll oder wie etwas angeordnet sein soll. Manchmal muss ich mich - zugunsten der Aufwandsreduzierung, bei der Programmierung - für bestimmte Strukturen entscheiden, damit der Programmcode unter der Oberfläche nicht "explodiert". Hier gibt es nur eine Struktur: Rubriken, die übereinander angeordnet sind und sich aufklappen lassen. Darunter dann, in abgestufter Form, weitere Objekte; durch die Baumstruktur sind Abhängigkeiten zu erkennen, ein Zweig wächst von links nach rechts. Wie viele Objekte einander untergeordnet sind, ist nicht festgelegt. Die Hauptobjekte sind ganz links angeordnet, eine Art Verzeichnis. Es lassen sich neue "Ordner" hinzufügen, die dann eine neue Umgebung abbilden. Alles in der Benutzeroberfläche folgt einem Sandbox-Prinzip. Auch die unterschiedlichen Bibliotheken, die JavaScript beinhalten. Jede Sandbox hat ihre Objekte. Code der Sandboxen kann nebeneinander ablaufen und wird durch übergeordnete Variablen und Mechanismen synchronisiert. Es existiert aber nur ein gemeinsames Objekt, für die HTML-Darstellung. Alle Objekte, die der Darstellung dienen, sind hier untergeordnet. Aus jeder Sandbox kann darauf zugegriffen werden. Was hier in diesem Bereich, Nr. 7, zu sehen ist, ist ein Frame im Browser, mit einer HTML-Seite. Alle Knoten-Objekte sind in einer Seite abgebildet und stellen eine Struktur dar, die einem bestimmten Aufbau folgt. Teile des Aufbaus werden ausgeblendet, damit sind manche Zweige nicht sichtbar, aber jeder Zeit vorhanden. Die gesamte Baumstruktur ist also zurzeit eine Einheit.

5: Zu jedem Objekt im Baum gibt es eine Beschreibung oder Erläuterung (irgendeinen erklärenden Text), der wird hier angezeigt.

6: Die Ausgabe für Debugger etc. In etwa das, was in der Arduino-IDE das serielle Terminal ist. Bloß gibt es hier bisher keine Möglichkeit der Eingabe. Es ist ein reiner Ausgabebereich.

1 bis 4: Weitere Anzeigebereiche. Für Ausgaben von unterschiedlichen Werten gedacht, die man irgendwie aus der Hardware geliefert bekommt. Bereich Nr. 1 könnte Werte von Encoder#1 anzeigen; Bereich Nr. 2 Werte vom ADC und die andern beiden Bereiche andere Sachen. Aus diesen vier Bereichen könnten auch sechs werden. Ich bin mir aber nicht sicher, ob das sinnvoll wäre.

Die Bereiche 7 und 6 sind über Regler in der Breite verstellbar, 1 bis 4 passen sich in der Breite an, damit insgesamt alles in das Browserfenster passt.

Die Informationen, die vertikal dargestellt werden können, verringern sich mit der Höhe des Browserfensters. Ebenso verhält es sich mit der Breite (hier können dann aber, wie beschrieben, die Bereiche etwas angepasst werden).
Werden die Bereiche in der Vertikalen kleiner, muss mehr gescrollt werden, deshalb versuche ich, diese möglichst groß zu halten. In der Horizontalen habe ich mehr Spielraum, auch weil Bildschirme heute vom Seitenverhältnis so angelegt sind.

Was noch nicht zu sehen ist, befindet sich zwischen Bereich 7 und 6. Dort ist noch ein Bereich, zurzeit ausgeblendet, wo zusätzliche Elemente untergebracht werden können. Ein Bereich, der frei zu gestalten sein sollte, also keinen festen Inhalt hat. Ich glaube, damit bin ich ziemlich am Ende angelangt, was auf einen Bildschirm passt.

Gruß
Moppi

- - - Aktualisiert - - -

Ich stelle hier mal die Frage, ob der Thread geschlossen werden kann? Ich tue mich mit der Abgrenzung zu abgeschlossenen oder fast abgeschlossenen Projekten etwas schwer.
Vielleicht ein Moderator-Kommentar dazu?

Zitat:

---

Ich stelle hier mal die Frage, ob der Thread geschlossen werden kann?

---

wieso schließen? willst du keine Fragen beantworten und keine Kommentare zulassen? (wenn das tatsächlich so ist, warum stellst du es dann hier im Forum vor?)

Zitat:

---

Zitat von HaWe

warum stellst du es dann hier im Forum vor?

---

im gegensatz z.b. zum "rumgucker" der nur schlaue sprüche hatte - bis er dann nun weg war... ich denke es gibt foren, wo das interesse an sowas grösser ist...

Zitat:

---

Zitat von HaWe

wieso schließen? willst du keine Fragen beantworten und keine Kommentare zulassen? (wenn das tatsächlich so ist, warum stellst du es dann hier im Forum vor?)

---

Weil es hier unter der Rubrik: Vorstellung zu geplanten Projekten/Bots steht. Da steht ausdrücklich, dass hier keine fertigen oder halbfertigen Projekte eingestellt werden sollen. Dafür gibt es eine eigene Rubrik. :)
Daran will ich mich nur halten, weiter nichts. Ich tu mich aber damit schwer. Weil ein Projekt hat irgendwann einen Anfang und wann es ist es dann fertig oder fast fertig? Ich hätte aber gerne erst eine Einschätzung von einem Moderator dazu, bevor ich dasselbe Projekt nochmals in der anderen Rubrik einstelle.

Gruß

ach so.... ;-)
aber dann können es die Mods auf Wunsch ganz einfach verschieben in eine andere Rubrik/Unterforum.

Dann bleibt es hier. Wenn es dann, inklusive der Hardware, so weit funktionstüchtig ist (richtig fertig in dem Sinn wird mein Car II, dass so flexibel ist, vermutlich sowieso nie), dann stelle ich das evtl. noch mal in der andern Rubrik vor.

Mich interessieren noch folgende Dinge:

1. Wie findet Ihr die Sache, dass die Benutzeroberfläche durch eigene Programmierung funktionell geändert bzw. erweitert werden kann?
Normal wird so etwas ja gar nicht angeboten. Die Funktion steht per Programmcode irgendwann fest und dann bleibt die so, bis die nächste Version erscheint.

2. Ist das Konzept verständlich oder schwer nachzuvollziehen (ich hoffe, dass es möglichst selbsterklärend ist)?

Was die Aufteilung der Oberfläche im Fenster angeht, hatte ich auch so eine ähnliche Idee, wie links ein Verzeichnis, rechts dessen Inhalt und unten drunter evtl. sowas wie einen Serial-Monitor. Ich fand aber so eine Aufteilung nicht so sehr praktisch, angesichts der Sachen, die ich alle unterbringen wollte und auch technisch umsetzen muss.


MfG