MasterOfGizmo hat geschrieben:
Hab' s selbst auf dem TXT noch nicht getestet, sondern nur auf dem PC. Ist auch wieder so ein 22MB-Riesen-Install.
Da ist ja auch ein Haufen Zeug bei, das wir eigentlich gar nicht brauchen - insbesondere die (unkomprimiert) gut 23 MB in "demos", der Grossteil der 3.6 MB in "msg" (auch wenn ich die Community-Firmware gerne sauber internationalisieren will werden wir die allermeisten da vertretenen Sprachen so schnell wohl nicht brauchen) und die kompletten 3.6 MB in "tests". Was übrig bleibt ist nicht mehr so arg groß, und - auch wenn ich mir das noch nicht genau angeschaut habe - dazu auch noch wohl zu einem großen Teil redundant.
Ich vermute, am Ende brauchen wir von dem ganzen Kram nur "blockly_compressed.js" (und das bringt dann grade mal etwas über 600kB auf die Waage) und etwas eigenes HTML und Javascript drumrum um daraus ein System zu bauen mit dem man auch Modelle steuern kann. Aber viel mehr als ein MB alles zusammen wird das wohl eher nicht werden.
MasterOfGizmo hat geschrieben:
Da stellt sich dann recht schnell die Frage, ob man das Server-seitig (also auf dem TXT) oder Client-seitig (also auf dem PC/Tablet/Handy) ausführen lassen will. Intuitiv hätte ich erstmal Server-seitig gesagt, da man ja möglichst latenzarm den TXT steuern will.
Ganz klar serverseitig. Clientseitig hätte ich auch genausogut mit Snap! weitermachen können.
Der wesentliche Grund, warum ich mit Blockly was neues anfangen will ist, dass Blockly nicht nur (anders als Snap!) von vornherein darauf ausgelegt ist, aus den Blöcken Code in einer "traditionellen" Sprache zu generieren, sondern sogar schon einen fertigen Codegenerator für Python mitbringt.
MasterOfGizmo hat geschrieben:Aber das erschwert im Gegenzug alles, was man dann mit dem Client machen will. Also 'ne schöne Modell-spezifische GUI im Browser.
So arg schwer ist das auch nicht. Auf "Blockebene" läuft das auf die "üblichen Verdächtigen" raus (Sprites, sowas wie "Turtle Graphics" für deren Bewegung, Bilder, mit denen man Sprites "kostümieren" kann, irgendeine Art Textausgabe, ...), und die Implementation untendrunter ist ein bißchen Fingerübung in Javascript und Websockets.
Aber das ist denke ich auch ziemlich nachrangig. Scratch-artige Systeme, die irgendwelche Bilder im Browser hin- und herschieben gibts inzwischen wie Sand am Meer. Und einige davon sind verdammt beeindruckend - schau dir z.B. mal
https://blockly-games.appspot.com/ an, das ist ein kompletter Anfänger-Programmierkurs mit Blockly, als Browserspiel verpackt. Und es macht echt Spaß
Mit sowas kann (und will) ich gar nicht konkurrieren.
Ich will auf was anderes raus: Einen Code-Editor, mit dem man vollwertige Apps für die Community-Firmware entwickeln kann. Vielleicht nicht so komplex wie deinen Rubiks-Cube-Solver, aber für den Anfang allemal auf dem Level der Roboter aus dem TXT Discovery Set. Und dafür braucht man am Anfang vor allem die IOs (haben wir, macht ftrobopy), dann das lokale Display (da verpackt man dann halt QT-Widgets in passende Blöcke, für den Anfang dürfte da sogar eine simple Message-Box und vielleicht eine Dialogbox reichen) und vielleicht Gimmicks wie Soundausgabe (Basis: Dein MP3-Player). Blöcke für Kameraansteuerung, Bilderkennung, Zeug am I2C-Bus, sonstige Hardware und so weiter kann man immer noch später nachrüsten.
Wichtig ist meiner Meinung nach erst mal ein sauberes Programmiermodell als Basis. Und das darf durchaus fortgeschritten sein: Für Modellsteuerung drängt sich ein eventgetriebenes Programmiermodell schließlich quasi auf - und das läßt sich zum einen in blockorientierten Sprachen auch richtig schön intuitiv umsetzen. Das ist da mehr oder weniger das natürliche Modell (zumindest wenn man von Scratch das Konzept des "Hut-Blocks" am Anfang jedes Blockstapels borgt, der dann auf irgendwelche Events anspringt und den zugehörigen Codeblock triggert).
Und die naheliegende Umsetzung "nach hinten raus" ist dann ebenso natürlich ein Python-Programm, das beim Start anfängt auf Events zu lauschen und die dann passend auf die einzelnen Codeblöcke verteilt. Die natürlich jeweils in einem eigenen Thread laufen. Und sich gegenseitig durch Abschicken eigener "Events" triggern.
Der Nutzer sieht davon natürlich erst mal nicht viel - nur seine Codeblöcke. Von denen wird einer halt auf irgendeine magische Art und Weise aufgerufen, wenn jemand auf den Schalter an I1 drückt, und startet dann den Motor an M1. Und der andere Codeblock wird aufgerufen, wenn C1 > 100 ist, und stoppt den Motor wieder.
Et voila, eine waschechte Multi-Thread-Modellsteuerung mit Kommunikation per Message Passing, programmiert von einem Anfänger.
Und wenn man erst mal so weit ist, ist der Schritt zu einem verteilten System auch nicht mehr weit - da löst man dann halt ein Event aus, das einen Codeblock auf einem anderen TXT (oder im Browser - bzw in
irgendeinem der Browser, die vielleicht gerade mit der laufenden Applikation verbunden sind) anstößt.
Und wenn der Anfänger irgendwann mal kein Anfänger ist, bleibt ihm immer noch eine saubere, nach dem aktuellen Stand der Technik programmierte TXT-App in Python als Basis für weitere Experimente und Erweiterungen. Die fällt bei der Blockly-App nämlich als "Objektcode" hinten raus