Meeting 2017 02 09
Martin hat TrCompose implementiert. Das führt die Verknüpfungen jetzt auf Ebene der doppelt komplexen Zahlen aus, nicht auf Ebene der 3x3-Matrizen. Darauf baut dann auch das IFS inzwischen auf, nachdem der vorherige Ansatz, aus den auf Pixelkoordinaten umgebauten Matrizen die doppelt komplexen Parameter zu rekonstruieren, zu Vorzeichenfehlern geführt hat.
Jürgen hat Bedenken, ob das alles ordentlich zu tracen ist. Martin meint, es sei ja alles nur elementare Arithmetik und daher analytisch. Michael wird beim Anschauen des Codes ein Auge offen halten, ob irgendwas Probleme beim Tracing machen könnte.
Laut #24 haben wir so langsam alle wesentlichen Algorithmen abgehakt. Wir sollten schauen, welche der noch ausstehenden wir unterstützen wollen, und wie.
- AngleMark: brauchen wir noch
- AnimationAlg: Knopf mit dem ein einzelner animierter Punkt gestartet und gestoppt werden kann. Braucht überhaupt erst mal Animationen, sollte bei deren Einführung bedacht werden.
- Area: brauchen wir noch
- Basis: wenig genutzt aber cool. Evtl. ließe sich das ersetzen wenn man einen Mechanismus hat, der abhäbgige Objekte bewegen lässt und dabei die Bewegung auf das Urbild überträgt. Halbfrei wird das noch mal schwieriger.
- Caluclation type==MOVE: Bewegt einen Punkt in Reaktion auf eine Berechnung. Vielleicht durch allgemeines Skripting überflüssig.
- Calculation type==TFM: Hat das was mit TrFunction zu tun?
- CindyScriptElement: auf CInderella-Seite noch experimentell. Operationen in CindyScript zu schreiben zu können wäre langfristig schon gut.
- CircleHelperForPolygons: Intern für PolygonPP. Anschauen wenn wir PolygonPP bekommen.
- CompassByRadius: SIgnatur [Point, Number], Kreis um Punkt mit definierter Zahl. z.B. um Winkel auf Länge zu übertragen. GUI wohl nicht vorhanden. Könnte man auch skripten.
- ComplexAdd: Nicht im GUI. Nicht akut wichtig.
- ComplexMult: Nicht im GUI. Nicht akut wichtig.
- Dist: brauchen wir noch
- Evolute: Spezielle Ortskurve. Nicht im GUI. Numerisch schwierig. Wäre am ehesten ein Plugin.
- ExtractTransform: Bei Punkt, der aus Transformationsgruppe entstanden ist, entsprechende Trafo von Original auf diesen Punkt bestimmen. GUI: Special / Element from group, derzeit defekt. Nicht akut wichtig.
- IFS: Martin ist dran, #517
- LabelText: keine zusätzliche Funktionalität über Text hinaus. Nicht wichtig, könnte man beim Export in Text übersetzen.
- Locus: brauchen wir noch, #62
- MTransform: Angenden einer Transformation Group (TG) auf ein Element. Ist als ganzes zu stylen. Baum aller Elemente wird mit gespeichert.
- PointOnCircleBasis: Braucht man nur wenn man Basis hat.
- PointOnLine type==CIRCULAR: Kommt nirgendwo in der Codebase vor, kann weg.
- PolygonCenter: Nicht im GUI. Nicht akut wichtig.
- PolygonMP: wollen wir haben. 7_2 und so was sind Sternpolygone. Sollte eine Liste von Punkten erzeugen.
- PolygonMPForPP: wollen wir auch.
- TG: Wäre cool, aber nicht dringend. Gemeinsam mit MTransform.
- TrCompose: brauchen wir, #580
- TrFunction: GUI: Transformation / Add Function. Formel für IFS oder TG. Selten genutzt.
- TrRotationLL: In Cinderella noch kaputt, da State nicht gespeichert wird. Wäre schon cool. Drehwinkel o.ä. als State sollte ausreichen.
- TrRotationPNumb: z.B. Längen auf Winkel übertragen. GUI existiert. Nicht akut wichtig.
- TrTranslationPP: Bermutlich ein Artefakt für Abwärtskompatibilität von Cinderella, durch TrTranslationPP ersetzt.
- Transform Möbius polygon: Nice to have, klappt in Cinderella auch noch nicht voll, macht Arbeit. Segment geht schon, das dürfte für viele Anwendungen reichen.
Standalone-Anwendung
Haupt Schwierigkeit bei Contenterstellung ist dass das nur über Export von Cinderella geht. Ist gerade beim Nachbasteln doof.
Bräuchte im wesentlichen zwei Punkte:
- Konstruktionswerkzeuge mit zugehörigen Buttons, visuellem Feedback, Snapping und so weiter.
- Inspector um Eigenschaften zu beeinflussen.
Visuelle Aufteilung ist nicht ganz klar. Insbesondere wie viele Fenster man haben will. Browser werden oft im Vollbild genutzt, das sollten wir ermöglichen. Evtl. ein großer Canvas, bei dem am Rand eine Seitenleiste reinfährt, in der Buttons, Inspector und/oder Script Editor rein kommen. Dazu ein Modus, in dem man die Größe und/oder das Seitenverhältnis der Konstruktion anpassen kann.
Ein Ansatz, um viele Konstruktionswerkzeuge unterbringen zu können wäre, einen einzigen Button zum Wechsel des Werkzeugs zu haben, und dann auf Druck hin alle davon anzuzeigen. Damit braucht jeder Werkzeugwechsel zwei Klicks und man kann sich genau merken, was wo ist. Bei jedem Wechsel alle Werkzeuge zu sehen macht allerdings den Konstruktionsvorgang sehr unruhig. Für Standard-Werkzeugwechsel ist das daher als Lösung ungeeignet. Dem könnte man begegnen, indem man die letzten benutzten Werkzeuge durch einen Klick zugreifbar hält.
Vielleicht eine Seitenleiste, die die letzten benutzten Werkzeuge und andere Einstellmöglichkeiten in eine Seitenleiste integrieren.
Anmerkung: Mail von Martin zu Tool-Icons per SVG nicht vergessen. Icons waren hässlich, aber die Struktur ist vielleicht doch nützlich.
Ein möglicher erster Schritt könnte sein, einen Text-Editor mit einer Live-Ansicht zu kombinieren, dazu Funktionalität um Koordinaten in den Text zurück zu speichern und Tool-Buttons um Templates für Operationen einzufügen. Aber die starke Basierung auf einen Text-Editor macht das vermutlich zur Sackgasse.
Irgendwann ja, jetzt nicht. Evtl. eher content als tool?
- #578 Martin reagiert noch auf Tweak-Vorschlag von Aaron, kann bald rein
- #573 wirkt sinnvoll, erst mal so nehmen
- #572 Michael und Jürgen testen
- #555 und co: conic drawing. Ab bestimmter Größe sollte man auch Kreise als Kegelschnitte rendern.
- #554 braucht review. Einfach.
- #549 an Martin
- #536 muss Michael noch was aufräumen
- #517 Aaron schaut drauf
- #501 soll rein weil nützlich, auch wenn noch kein benchmark vorliegt
- #426 MIDI. Martin versucht das noch hinzubekommen.
- #423 testet Aaron auf iPad, kann dann rein
- #420 braucht review. Einfach
- #399 schwer zu lesen. Details stehen in Commit-Messages. Michael schaut drauf.
- #360 tests brauchen noch Arbeit. Michael und Martin arbeiten dran.
- #299 Michael kümmert sich drum.
- #281 Hausaufgabe für Martin.
- #280 superseded by #555 & co.
- #199 Martin muss reviewen
- #194 muss auseinandergenommen werden
- #57 nicht akut nitwendig, aber manche Aspekte davon machen eindeutig Sinn
Die Beispielgalerie auf cindyjs.org läuft in manchen Punkten nicht so wie auf science-to-touch. Manchmal fehlt Autostart, Animation, Buttons oder dergleichen.
Aaron schaut mit Jürgen drauf.
Handling von unevaluierten Ausdrücken wäre gut. In Cinderella gibt es expressiontree, was wohl so was macht. Ein Analogon davon wäre in CindyJS auch möglich.
Schön wäre auch im Gegenzug einen Syntaxbaum in eine Funktionsdefinition übersetzen zu können.
Ein Modifier deep->true oder deep->["f","g"] wäre gut, um Funktionsaufrufe zu inlinen. Entweder alle oder nur die genannten, und natürlich nur wenn diese nicht rekursiv sind.
Es gibt derzeit Experimente mit Physik in drei Dimensionen. Eine Frage ist, wie viel davon wir im Kern von CindyJS haben wollen. Könnte auch ein Plugin sein. Es müsste noch eine Schnittstelle dazu, um aus Skripten an die 3D-Daten dran zu kommen.
- Fluidsimulation
- Projektion auf Propeller
- 3D-Modelle
- Komplexe Phasendiagramme
Ist noch irgendwas in der Pipeline, was in 0.8.4 rein soll? Nicht akut, ein paar von den PRs oben schaffen es vermutlich.
Mittwoch 8. März 16 Uhr