+ nachdem sich eine Instanz einer Rolle gemeldet hat, kann der Hook sie individuell verknüpfen, typischerweise als Lambda +
+ ++ also nicht generisch, sondern die spezifische Closure für z.B. den Fall drag-Clip +
+ ++ naja... sie besteht schon von Anfang an, insofern das Event-Konzept, wie auch die konkrete Quelle, ohnehin an das UI-Framework gebunden sind +
+ ++ im Beispiel: in dieser Closure wird zunächste eine Verdrahtung auf das button_down-Event angelegt. Wenn diese aktiviert wird, schaltet die die Beobachtung eines ebenfalls vorsorglich verdrahteten motion_notify_event ein, sowie analog das Warten auf ein button_up +
+ ++ die Umrechnung Zeit → Pixel habe ich im CanvasHook versteckt +
+ +
+ das bedeutet:
+
+ ...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. +
+ ++ ...wobei das auch noch halbfertig ist; später einmal muß es hier eine Abstimmung mit dem Layout-Manager geben, aber diese Abstimmung sollte eigentlich nicht über den ClipPresenter laufen +
+ ++ insofern wir die Storage nur einmal, im jeweilgen CmdContext der Geste vorsehen müssen +
+ + +