From a53032cfc5ac9439de34f2168f226e4f0b68856a Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sun, 9 Apr 2017 01:34:18 +0200 Subject: [PATCH] Analysis regarding the next step, integration of InstanceManagement into SessionCommand facade --- src/gui/ctrl/command-handler.hpp | 1 + src/lib/meta/tuple-record-init.hpp | 2 +- .../control/session-command-function-test.cpp | 2 +- tests/library/meta/tuple-record-init-test.cpp | 6 +- wiki/renderengine.html | 10 +- wiki/thinkPad.ichthyo.mm | 166 +++++++++++++++++- 6 files changed, 178 insertions(+), 9 deletions(-) diff --git a/src/gui/ctrl/command-handler.hpp b/src/gui/ctrl/command-handler.hpp index bf34348d6..6555d56c7 100644 --- a/src/gui/ctrl/command-handler.hpp +++ b/src/gui/ctrl/command-handler.hpp @@ -87,6 +87,7 @@ namespace ctrl{ * the GenNode::ID of the commandMsg (see CommandHandler(GenNode)), * extended by the subID and some random digits. * @throw error::Logic always, not yet implemented ///////////////////////////////////////////////////TICKET #1058 consider extension of UI-Bus protocol + * @deprecated as of 4/2017 it rather does not look like wer're going this path */ bool handle (string const& subID) override ///< the "bang!" message (command invocation) diff --git a/src/lib/meta/tuple-record-init.hpp b/src/lib/meta/tuple-record-init.hpp index 8332e8466..28d0f0fe1 100644 --- a/src/lib/meta/tuple-record-init.hpp +++ b/src/lib/meta/tuple-record-init.hpp @@ -27,7 +27,7 @@ ** passed in our "External Tree Description" form. This is relevant for structural ** diff and the invocation of actions driven by messages via the UI-Bus. ** - ** In those cases, a sequence of arguments will be passed in a run-time sequential + ** In those cases, a sequence of arguments will be passed within a run-time sequential ** container, as a sequence of GenNode entries. The latter are variant records, ** which means they can hold any of a small collection of basic types, like ** numbers, strings, time values etc. So we have to face two challenges here. diff --git a/tests/core/proc/control/session-command-function-test.cpp b/tests/core/proc/control/session-command-function-test.cpp index f8745b48f..13ea56bbf 100644 --- a/tests/core/proc/control/session-command-function-test.cpp +++ b/tests/core/proc/control/session-command-function-test.cpp @@ -287,7 +287,7 @@ namespace test { * when handling command messages from the UI-Bus * - use the help of an InvocationTrail, similar to what the * [generic UI element](\ref gui::model::Tangible) does - * - generate a argument binding message + * - generate an argument binding message * - generate a "bang!" message */ void diff --git a/tests/library/meta/tuple-record-init-test.cpp b/tests/library/meta/tuple-record-init-test.cpp index 65c73a50f..bbe68543a 100644 --- a/tests/library/meta/tuple-record-init-test.cpp +++ b/tests/library/meta/tuple-record-init-test.cpp @@ -23,8 +23,6 @@ /** @file tuple-record-init-test.cpp ** unit test \ref TupleRecordInit_test */ -///@file - #include "lib/test/run.hpp" @@ -37,7 +35,7 @@ #include #include -using lib::Literal; +using lib::Symbol; using lib::Variant; using lib::idi::EntryID; using lib::diff::Rec; @@ -96,7 +94,7 @@ namespace test { show_simpleUsage() { using NiceTypes = Types; - using UgglyTypes = Types, string, int, int64_t, double, Duration>; // various conversions and an immutable type (Duration) + using UgglyTypes = Types, Symbol, int, int64_t, double, Duration>; // various conversions and an immutable type (Duration) Rec args = MakeRec().scope("lalü", 42); Rec urgs = MakeRec().scope("lalü", "lala", 12, 34, 5.6, Time(7,8,9)); diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 7b1f04a8b..3bf437bcf 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -3402,7 +3402,7 @@ The InteractionDirector is part of the model, and thus we have to distinguish be !Collaborations -
+
A facility within the GUI to// track and manage one specific aspect of interaction state.//
 In a more elaborate UI, as can be expected for such a task like editing, there are interactions beyond "point and shot". For a fluid and natural interaction it is vital to build and exploit an operation context, so to guide and specify the ongoing operations. Interaction events can not be treated in isolation, but rather in spatial and temporal clusters known as ''gestures''. A good example is the intention to trim or roll an edit. Here the user has some clips in mind, which happen to be located in immediate succession, and the kind of adjustment has to be determined from the way the user approaches the junction point. To deal with such an interaction pattern, we need to track a possible future interpretation of the user's actions as a hypothesis, to be confirmed and executed when all pieces fall into place.
 
@@ -3411,7 +3411,13 @@ An InteractionState is a global component, but often not addressed directly. To
 &rarr; CommandInvocationAnalysis
 &rarr; InteractionControl
 &rarr; GuiCommandBinding
-&rarr; CommandUsage
+&rarr; CommandUsage + +! interaction state and the actual widgets +InteractionControl is conceived as an additional intermediary layer, distinct from the actual widgets. The whole idea is that we //do not want// intricate state managing logic to be scattered all over the concrete UI widget code -- doing so would defeat any higher level structuring and turn the UI code into highly tangled very technical implementation logic; ideally, UI code should mostly be specification, setup and wiring, yet void of procedural logic. + +For this reason, we decided against handling all of the GuiCommandCycle over the UI-Bus -- only the final stages are sent as messages, and they can be sent from //anywhere.// +
Because we rely on strong decoupling and separation into self contained components, there is not much need for a common quasi-global namespace. Operations needing the cooperation of another subsystem will be delegated or even dispatched, consequently implementation code needs only the service acces points from "direct cooperation partner" subsystems. Hierarchical scopes besides classes are needed only when multiple subsystems share a set of common abstractions. Interface and Implementation use separate namespaces.
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 6a8c818bc..11f44fa1b 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -11793,10 +11793,154 @@
 
 
 
-
+
+
 
 
 
+
+
+  
+    
+  
+  
+    

+ da dieser Zugriff wirklich für jedes Command passiert, +

+

+ möchte ich mit dem Minimum an Hashtable-Zugriffen auskommen. +

+

+ Daher prüfen wir als erstes den CommandInstanceManager, +

+

+ da dies der Regelfall ist. Wenn dies scheitert, suchen wir noch +

+

+ in der globalen Registry +

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

+ ....künftige Weiterung: +

+

+ auch in EntryID könnte ein Symbol-Stecken, +

+

+ mithin in der GenNode::ID +

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

+ d.h. wir müßten dann auch noch das Interface brechen +

+

+ und die Form der ID-Dokoration zur Konvention machen +

+ + +
+
+ + + + + + +

+ das heißt, für das ganze Thema InteractionControl +

+

+ schwebt mir eine Zwischenschicht unabhängig von den Widgets vor +

+

+ +

+

+ Wenn nun aber das Anfordern einer neuen Instanz über den Bus laufen soll, +

+

+ dann würde es wohl ehr direkt von den Tangibles (Widget / Controller) ausgehen. +

+

+ Das wollte ich genau nicht +

+ + +
+
+ + + + + + +

+ Tangible sollte InteractionState verwenden +

+ + +
+ + + + + +

+ ....und demnach sollte InteractionState eben grade nicht von Tangible wissen +

+

+ Demnach müßte sich InteractionState irgendwo "hinten rum" an den Bus ranmachen, +

+

+ z.B. über den InteractionDirector. Das ist aber nun wirklich absurrd, +

+

+ da es letztlich nur darum geht ein ohnehin öffentliches  Interface aufzurufen +

+ + +
+
+
+
@@ -12336,6 +12480,26 @@ + + + + + + +

+ das ist ein grundlegender Beschluß. +

+

+ InteractionControl ist eine eigene Schicht; +

+

+ deshalb ist auch der UI-Bus nicht das Universal-Interface schlechthin +

+ + +
+ +