diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 7d163f834..d4d1a48cb 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -31759,7 +31759,7 @@ - + @@ -31846,7 +31846,8 @@

- + + @@ -31862,10 +31863,22 @@
  • aus der gegenwärtig im Clip gespeicherten Zeit ergibt sich dann ein Delta
    • +
  • + dieses Delta wird sofort auf den Clip angewendet +
    • +

    + Am Ende der Geste steht die neue Zeit-Position fertig im Clip und wird von dort per Command in den Steam-Layer gesendet. Später, nach der Verarbeitung in der Session kommt ein Update über den UI-Bus, welches die Position überschreibt und infolgedessen ggfs auch nochmal das Widget verschiebt +

    - + + + + + + + @@ -31877,12 +31890,33 @@

    - ...das heißt, durch die Drag-Geste entstehen vorübergehend lokal inkonsistente Koordinaten; der nächste DisplayEvaluation-Pass würde dies wieder beseitigen. Dieser Ansatz wäre rein logisch der konsktentere Weg, denn erst durch eine Rückmeldung von der Session wird eine neue Position auch offiziell. Allerdings müßte man bei diesem Ansatz vorsichtig vorgehen, und mögliche Interferenzen mit der DisplayEvaluation und dem Layout-Managment bedenken; besonders wenn man eine weite Strecke zurücklegt, könnte es passieren, daß der Clip dann plötzlich aus der Anzeige verschwindet und den Fokus verliert, weil eine DisplayEvaluation ihn wieder an seine gegenwärtig nominelle Position geschoben hat. + ...das heißt, durch die Drag-Geste entstehen vorübergehend lokal inkonsistente Koordinaten; der nächste DisplayEvaluation-Pass würde dies wieder beseitigen. Dieser Ansatz wäre rein logisch der konsistentere Weg, denn erst durch eine Rückmeldung von der Session wird eine neue Position auch offiziell. Allerdings müßte man bei diesem Ansatz vorsichtig vorgehen, und mögliche Interferenzen mit der DisplayEvaluation und dem Layout-Managment bedenken; besonders wenn man eine weite Strecke zurücklegt, könnte es passieren, daß der Clip dann plötzlich aus der Anzeige verschwindet und den Fokus verliert, weil eine DisplayEvaluation ihn wieder an seine gegenwärtig nominelle Position geschoben hat.

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

    + gehört er nun dem Layout-Manager, oder gehört er der Geste? +

    + +     + +     + + +     @@ -31899,9 +31933,22 @@ + + + + + + +

    + ...sonst bleibt ein inkonsistender Zustand irgendwo "hängen".
    Leider ist das nun das bekanntermaßen unlösbare Problem eines sicheren Verbindungsabbaus, und wir müssen uns deshalb mit einem Timeout, oder re-check-Mechanismus behelfen +

    + +     +     - - + + + @@ -31923,8 +31970,8 @@ - - + + @@ -31940,13 +31987,117 @@ - + + + + + + + + + + + + + + +

    + die Konsequenz aus Lösung-1 ist aber nicht wirklich abwegig +

    + +     + + + + + +

    + Warum möchte man denn überhaupt eine Geste "abbrechen können"? +

    +
      +
    • + weil sie versehentlich ausgelöst wurde +
      • +
    • + weil man besorgt ist, ein bereits Erreichtes dadurch "kaputt" zu machen +
      • +
    • + weil man ein «UNDO« nicht zuverlässig sieht +
      • +
    +

    + Die Konsequenz daraus ist dann, daß das UI von Lumiera stets offen, non-modal und manipulierbar ist. Und die zweite Konsequenz ist, daß wir ein klar und zuverlässig steuerbares «UNDO» brauchen. +

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

    + ..brauchen wir Widget und Subject und Canvas +

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

    + Registry hat zusätzlichen Overhead (sowohl Speicher, alsauch Management) und ist nur sinnvoll, wenn eine ID in mehreren Objekten vorkommt, oder die ID aus mehreren Thread-Kontexten benötigt wird +

    + +     +     +     + + + + + + +

    + ...insofern sie genau an die Struktur anbaut, welche ich schon zur Lösung der Querbeziehungen für das Layout genutzt habe +

    + +     + + +     +     +     + + + +