From d3937261ab610b46a3ebd000be3b4997f7719fce Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Thu, 16 Feb 2017 21:51:53 +0100 Subject: [PATCH] detailed analyse regarding focus movements --- wiki/renderengine.html | 27 ++- wiki/thinkPad.ichthyo.mm | 487 +++++++++++++++++++++++++++++---------- 2 files changed, 385 insertions(+), 129 deletions(-) diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 49995a7c0..f566bb434 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -3245,7 +3245,7 @@ The InstanceHandle is created by the service implementation and will automatical → see [[detailed description here|LayerSeparationInterfaces]] -
+
This overarching topic is where the arrangement of our interface components meets considerations about interaction design.
 The interface programming allows us to react on events and trigger behaviour, and it allows us to arrange building blocks within a layout framework. Beyond that, there needs to be some kind of coherency in the way matters are arranged -- this is the realm of conventions and guidelines. Yet in any more than trivial UI application, there is an intermediate and implicit level of understanding, where things just happen, which can not fully be derived from first principles. It is fine to have a convention to put the "OK" button right -- but how to we get at trimming a clip? How do we how we are to get at trimming a clip? if we work with the mouse? or the keyboard? or with a pen? or with a hardware controller we don't even know yet? We could deal with such on a case-by-case base (as the so called reasonable people do) or we could aim at an abstract intermediary space, with the ability to assimilate the practical situation yet to come.
 
@@ -3266,9 +3266,9 @@ The interface programming allows us to react on events and trigger behaviour, an
 The primary insight is, that we build upon a spatial metaphor -- and thus we start out with defining various kinds of //locations.// We express interactions as //happening somewhere...//
 ;work site
 :a distinct, coherent place where some ongoing work is done
-:the work site might move along with the work, but we also may leave it temporarily to visit some other work site
+:the WorkSite might move along with the work, but we also may leave it temporarily to visit some other work site
 ;the spot
-:this is where we currently are -- taken both in the sense of a location and a spotlight
+:the [[Spot]] is where we currently are -- taken both in the sense of a location and a spotlight
 :thus a spot is always at some work site, but it can be navigated to another one
 ;focus
 :the concrete realisation of the spot within a given control system
@@ -3284,11 +3284,11 @@ The primary insight is, that we build upon a spatial metaphor -- and thus we sta
 :concrete coordinates to reach a specific work site
 :the focus path specifies the UI frame (top-level window), the perspective, and then some canonical path to navigate down a hierarchy to reach the anchor point of the work site
 ;the spot locator
-:this is what can be navigated, in order to move the sport from work site to work site
-:the spot locator is relocated by loading a new focus path to another work site
+:navigating means to move the SpotLocator, in order to move the spot from work site to work site
+:the spot locator is relocated by loading a new focus path to another [[work site|WorkSite]]
-
+
//the top-level controller within the UI.//
 In Lumiera, the structures of the model within the [[Session]] (the so called HighLevelModel) are mapped onto corresponding [[tangible UI entities|UI-Element]], which serve as a front-end to represent those entities towards the user. Within the model, there is a //conceptual root node// -- which logically corresponds to the session itself. This [[root element in model|ModelRootMO]] links together the actual top-level entities, which are the (multiple) timelines, with the asset management and defaults and rules configuration within the session.
 
@@ -3297,6 +3297,21 @@ And the counterpart of this root element within the UI is the {{{InteractionDire
 Why do we need a connection joint between those parts?
 Because issuing any actions on the model within the session -- i.e. any editing operation -- is like forming a sentence: we need to spell out //what we want to do// and we need to spell out the subject and the object of our activity. And any one of these can, and will in fact, be sometimes derived //from the context of the interaction.// Because, given the right context, it is almost clear what you want to do -- you just need to fill in that tiny little bit of information to actually make it happen. In Lumiera we want to build a good UI, which is an UI well suited to this very human way of interacting with one's environment within a given context.
 > to understand this, it is best → to [[look at some examples|CommandInvocationAnalysis]]
+
+!Children
+The InteractionDirector is part of the model, and thus we have to distinguish between model children and other UI components held as children.
+;model
+:anything related to global structures falls into that category
+:* some parts might be related to ''Asset management''
+:* some concerns might touch questions of ''configuration''
+:* and interaction state is closely related to ''persistent UI state''
+;interaction control
+:anything related to forming and tracking of user interactions → InteractionControl
+:* the SpotLocator is what is "moved" when the [[Spot]] of current activity moves
+:* the FocusTracker is responsible for //detecting changes in current selection and focus.//
+:* the [[Navigator]] is a special controller to handle moving the SpotLocator
+
+!Collaborations
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 5b105baf8..3a3227209 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -7,8 +7,8 @@ - - + + @@ -59,7 +59,7 @@ - + @@ -77,13 +77,14 @@ - + + - + @@ -102,10 +103,11 @@ Ganz anders Model::Tangible: dieses registriert sich bei der Konstruktion

- + + - + @@ -118,7 +120,8 @@ aber so herum macht es mehr Sinn

- + + @@ -142,7 +145,7 @@ - + @@ -171,7 +174,8 @@ BusTerm, das damit Nachrichten an den Nexus schicken kann.

- + + @@ -197,7 +201,7 @@ - + @@ -216,7 +220,8 @@ Term-Signal nicht ausgesendet würde.

- + + @@ -258,7 +263,7 @@ - + @@ -277,9 +282,10 @@ Anmerkung: ein "frestehendes" BusTerm ist valide und zugelassen, es hat halt nur eine uplink-Connection.

- + + - + @@ -292,7 +298,8 @@ es muß dazu auch jede Menge Methoden implementieren.

- + + @@ -324,7 +331,7 @@ - + @@ -340,7 +347,8 @@ startende Funktion zurückkehrt.

- + + @@ -559,7 +567,7 @@ - + @@ -572,7 +580,8 @@ indem wir ein GTK-Signal erzeugen, das das Hauptfenster schließt

- + + @@ -612,7 +621,7 @@ - + @@ -661,7 +670,8 @@ }

- + + @@ -703,7 +713,7 @@ - + @@ -719,7 +729,8 @@ und man damit jedes diff-iterable einbetten kann.

- + + @@ -1818,7 +1829,7 @@ - + @@ -1843,7 +1854,8 @@ diesen "aktuellen Kontext" irgendwo aufzufischen

- + + @@ -1885,7 +1897,7 @@ - + @@ -1898,7 +1910,8 @@ und verwendet, und das ist auch gut so

- + + @@ -2078,9 +2091,9 @@ - + - + @@ -2373,7 +2386,7 @@ - + @@ -2386,7 +2399,8 @@ und welchen Teil des Verhaltens überlassen wir GTK

- + + @@ -2427,7 +2441,7 @@ - + @@ -2443,7 +2457,8 @@ Details im  TiddlyWiki....

- + + @@ -2495,7 +2510,7 @@ - + @@ -2505,7 +2520,8 @@ braucht feste Speicher-Addresse

- + + @@ -2514,7 +2530,7 @@ - + @@ -2527,7 +2543,8 @@ und sei es auch bloß über ein Interface!

- + + @@ -2542,7 +2559,7 @@ - + @@ -2576,7 +2593,8 @@ - + + @@ -2803,7 +2821,7 @@ - + @@ -2813,7 +2831,8 @@ d.h. eine LUID

- + + @@ -2846,7 +2865,7 @@ - + @@ -2859,7 +2878,8 @@ Irgend eine BareEntryID genügt

- + + @@ -2882,7 +2902,7 @@ - + @@ -2892,13 +2912,14 @@ ...abstraktes Interface

- + + - + @@ -2914,7 +2935,8 @@ um die Bindung herzustellen

- + + @@ -2922,7 +2944,7 @@ - + @@ -2935,7 +2957,8 @@ oder eine Sequenz ohne root-Fork zulassen

- + + @@ -3338,7 +3361,7 @@ - + @@ -3348,7 +3371,8 @@ ...sie verwenden dann ein LabelWidget zur Darstellung

- + + @@ -3360,7 +3384,7 @@ - + @@ -3376,7 +3400,8 @@ Verwende das als Leitgedanke, um das Layout zu entwickeln

- + + @@ -3506,7 +3531,7 @@ - + @@ -3519,7 +3544,8 @@ mehr als ein top-level Fenster offen

- + + @@ -3528,7 +3554,7 @@ - + @@ -3541,7 +3567,8 @@ which reference actions from one or more action groups.

- + + @@ -3550,7 +3577,7 @@ - + @@ -3579,7 +3606,8 @@ AUA!

- + + @@ -3601,7 +3629,7 @@ - + @@ -3623,9 +3651,10 @@ auch nicht im Application-Shutdown!

- + + - + @@ -3638,13 +3667,14 @@ dock_.add_item(timelinePanel->getDockItem(),Gdl::DOCK_BOTTOM);

- + + - + @@ -3654,7 +3684,8 @@ Helper to build the menu and for registering and handling of user action events

- + + @@ -3667,7 +3698,7 @@ - + @@ -3680,7 +3711,8 @@ aber es kann davon mehrere geben

- + + @@ -3731,7 +3763,7 @@ - + @@ -3741,9 +3773,10 @@ heißt: Element registriert sich am UI-Bus

- + + - + @@ -3753,11 +3786,12 @@ heißt: Element deregistriert sich am UI-Bus

- + + - + @@ -3767,7 +3801,8 @@ ...ist immer ein tangible

- + + @@ -3817,7 +3852,7 @@ - + @@ -3827,10 +3862,11 @@ dafür genügt der normale Reset

- + + - + @@ -3840,9 +3876,10 @@ mark "clearMsg"

- + + - + @@ -3852,9 +3889,10 @@ mark "clearErr"

- + + - + @@ -3864,7 +3902,8 @@ mark "reset"

- + + @@ -3889,7 +3928,7 @@ - + @@ -3912,9 +3951,10 @@ was haben alle UI-Elemente wirklich gemeinsam?

- + + - + @@ -3930,7 +3970,8 @@ oder handelt es sich nur um ein Implementierungsdetail der UI-Bus-Anbindung?

- + + @@ -4005,7 +4046,7 @@ - + @@ -4018,10 +4059,11 @@ Dann mußte das allerdigns jeweils für alle Elemente sinnvoll sein

- + + - + @@ -4031,7 +4073,8 @@ und der muß vom konkreten Widget implementiert werden

- + + @@ -5561,7 +5604,7 @@ - + @@ -5574,7 +5617,8 @@ durch den das Problem mit der "absrakten, opaquen" Position entschärft wird

- + + @@ -9221,7 +9265,7 @@ - + @@ -9236,7 +9280,8 @@ - + + @@ -9370,7 +9415,7 @@ - + @@ -9383,7 +9428,8 @@ Der Nexus speichert nämlich eine direkte Referenz in der Routingtabelle

- + + @@ -9839,7 +9885,7 @@ - + @@ -9847,7 +9893,7 @@ - + @@ -9859,13 +9905,198 @@ - - + + + + + + + - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Focus/Spot wird mitbewegt +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -10082,7 +10313,7 @@ - + @@ -10100,14 +10331,15 @@ - + + - + @@ -10131,7 +10363,8 @@ - + + @@ -10146,7 +10379,7 @@ - + @@ -10159,11 +10392,12 @@ Implementierung der real-world-Variante fehlt!

- + + - + @@ -10179,7 +10413,8 @@ wie Session- und State-Managment, Commands etc.

- + + @@ -13335,7 +13570,7 @@ - + @@ -13345,7 +13580,8 @@ ...nicht mehr das klassische gtk::Main

- + + @@ -13368,7 +13604,7 @@ - + @@ -13381,7 +13617,8 @@ Siehe Beschreibung im Beispiel/Tutorial

- + + @@ -13432,7 +13669,7 @@ - + @@ -13442,9 +13679,10 @@ ....how does the event dispatching deal with partially covered widgets

- + + - + @@ -13454,7 +13692,8 @@ ...for embedded widgets

- + + @@ -13487,7 +13726,7 @@ - + @@ -13500,7 +13739,8 @@ i.e. the enclosing parent widget also gets a chance to redraw itself

- + + @@ -13689,7 +13929,7 @@ - + @@ -13717,7 +13957,8 @@ Kind-Widgets noch gar nicht festgelegt war (denn das passiert erst beim draw).

- + +