diff --git a/doc/devel/draw/StaveBracket.FCStd b/doc/devel/draw/StaveBracket.FCStd new file mode 100644 index 000000000..804f0e9f4 Binary files /dev/null and b/doc/devel/draw/StaveBracket.FCStd differ diff --git a/doc/devel/draw/StaveBracket.svg b/doc/devel/draw/StaveBracket.svg new file mode 100644 index 000000000..36c9da99f --- /dev/null +++ b/doc/devel/draw/StaveBracket.svg @@ -0,0 +1,193 @@ + + + + + StaveBracket + + + + + + + + image/svg+xml + + StaveBracket + + Feb.2023 + + + Ichthyostega + + + + + Lumiera Documentation: CC by SA or GPL 2+ + + + Design of the brackets to indicate a Track's scope in the Lumiera Timeline UI + + + + + + + + + + + + + + + + + + + + Φ + + + + + + + + + + + + + + diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index a3518210f..e0753654a 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -5715,6 +5715,7 @@ + @@ -5740,7 +5741,7 @@

- wenn man den Filter entfernt / auf Null dreht (Blur), dann wendet Inkscape die Transformation + wenn man den Filter entfernt / auf Null dreht (Blur), dann wendet Inkscape die Transformation an

@@ -28076,6 +28077,427 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ nominell: 96dpi +

+ + + + + + + + + +

+ mein Display: 90dpi +

+ + + + + + + +

+ Ich habe beim Upgrade auf Debian-Stretch mal nachgemessen: tatsächlich hat mein Display 94dpi. Demnach wäre der andere weithin übliche Wert von 96dpi präziser. Jedoch bin ich nach mehreren Experimenten bei 90dpi geblieben, da für mich so die Schriftarten die „richtige Größe“ haben — das mag auch daran liegen, daß ich leicht kurzsichtig bin und typischeweise etwas näher am Bildschirm sitze. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ ich kann zwar einrasten, aber ich kann weder um einen definierten Punkt drehen, noch kann ich Schnittpunkte ermitteln +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ "Mathe für 6-13 järige" etc +

+ + + + + + + + + + + + + + + + + + + + + + + + +

+ b = 0.6180339887498948482 +

+ + + + + + + + + + +

+ wenn man nachträglich einzelne Objekte modifiziert, ändern sicn nur diese, aber keine davon abhängigen weiteren Schritte der Konstruktion +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Anweisungen in der Statuszeile: wähle ersten Punkt, setze zweiten Punkt.... +

+ + + + + + + + + + + + + + + + + + + + + + + +

+ man zeichnet nicht, sondern man stellt eine Liste von Operationen zusammen +

+ + + + + + + + + + + + + + +

+ embedded browser control +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Das liegt vielleicht auch an der etwas „alten“ Version von ca. 2018. +

+

+ Könnte aber auch auf grundsätzliche Limitierungen hinweisen; man hat eben vor allem an das Design von 3D-Bauteilen gedacht +

+ + + + + + + + + +

+ Das UI-Design ist vom konkreten Einzelfall-Nutzen ausgegangen, nicht von einem stimmigen Gesamtentwurf. Alles ist auf das Konstruieren von 3D-Bauteilen in typischem handlichen Format ausgelegt: eine kleine Zahl an Einzelobjekten im cm-Bereich.... +

+

+ +

+

+ Ich komme jetzt mit einer Konstruktion im Sub-Millimeter-Bereich, und ich bräuchte sich überlappende Formen .... +

+
    +
  • + die Anzeige-Handhabung wird dann "frickelig" +
    • +
  • + die Beschriftungen sind viel zu groß und lassen sich nicht sinnvoll platzieren +
    • +
  • + es gibt nur die starre Unterscheidung in »Hilfslinien« (construction) und »Geometrie« +
    • +
  • + letztere muß überschneidungsfrei sein +
    • +
  • + für mein Design habe ich dann ca 50 nummerierte Constraints, die anhand der Anzeige kaum mehr sinnvoll nachvollziehbar sind... +
    • +
+ + + + + + + + + +

+ Die Geometrie-Elemente in den Sketch-Objekten sind eine Spezial-Implementierung, und keine »first class citizens«. Es ist nicht klar, wie man sie aus Expressions referenzieren kann (kein sauberes DSL-Design). Das Dependency-Management ist viel zu naiv implementiert, und es wird empfohlen, mit Tricks und Kniffen zu arbeiten. +

+ + + + + + + + + + +

+ Eine Funktion, um eine Linie gemäß Proportion zu teilen, wird zwar oft gewünscht, ist aber derzeit (2022) noch in Entwicklung. Daher kann man im Moment nur eine feste Basislänge als benannter Constraint vorgeben, und dann andere Längen per Expression =Constraint.basis * (1+sqrt(5)/2  daran binden. Außerdem kann man solche Expressions zwar einmal initial eigeben, dann aber nur noch über das XML editieren. +

+ + + + + + + + + + + +

+ ⟹ ich kann das Ergebnis nicht exportieren +

+ + + + + + + + + + + +

+ a bytes-like object is required, not "str" +

+ + + + + + + + + + + + + + + + +

+ die konkrete Aufgabe ist mit FreeCAD elegant
— aber Resultate sind schwer zugänglich — +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -28126,7 +28548,7 @@ - + @@ -69784,6 +70206,141 @@ + + + + + + + + + + + + + + + + +

+ anscheinend gibt es eine Konvention, welche die im UI sichtbaren Koordinaten in vertikaler Richtung spiegelt; auch ist der auf dem Lineal angezeigte Ursprung unten links +

+ + + + + + + + + + + + + +

+ Koordinaten »versäubern« +

+ + + + + + + + + + + + + + + + + + + + + + + + +

+ ...und Inkscape wird das erhalten, solange man die betr. Features nicht wieder aktiviert. Im Besonderen kann man +

+
    +
  • + alle "Stroke"-Features entfernen, wenn der Stroke deaktiviert ist +
    • +
  • + opacity:1 weglassen +
    • +
  • + die Defaults "color:#000000;display:inline;overflow:visible;visibility:visible;"  kann man meist weglassen +
    • +
  • + diverse Vector-Filter und display-styles weglassen (wenn sie auf dem default-Wert stehen) +
    • +
+ + + + + + + + + +

+ style="fill:black;fill-opacity:0.5;stroke:#5a8fb2;stroke-opacity:1;stroke-width:0.1" +

+ + + + + + + + + +

+ style="fill:#ffffff;fill-opacity:0.75;stroke:none;stroke-width:0.05" +

+ + + + + + + + + + +

+ aber leider nur als globales Verhalten der Inkscape-Installation +

+ + + + + + + + + + + + +

+ Behaviour > Transforms > store optimised +

+ + + + + + +