From d7d90bf491fe772d78e974d4dfdc0ae961398d45 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sun, 14 Feb 2016 05:03:08 +0100 Subject: [PATCH] Element protocol: broadcast of state reset messages unit test PASS This basically finishes definition of the fundamental UI-Element and Bus protocol -- with one notable exception: how to mutate elements by diff. This will be the next topic to address --- src/gui/interact/state-recorder.hpp | 6 + tests/gui/bus-term-test.cpp | 37 +++--- tests/gui/test/mock-elm.hpp | 2 + wiki/renderengine.html | 4 +- wiki/thinkPad.ichthyo.mm | 169 +++++++++++++++++++++++++--- 5 files changed, 188 insertions(+), 30 deletions(-) diff --git a/src/gui/interact/state-recorder.hpp b/src/gui/interact/state-recorder.hpp index 6ece9e36d..cb2d10178 100644 --- a/src/gui/interact/state-recorder.hpp +++ b/src/gui/interact/state-recorder.hpp @@ -176,6 +176,12 @@ namespace interact { { if ("reset" == stateMark.idi.getSym()) storage_.clearState (uiElm); + else + if ("clearErr" == stateMark.idi.getSym()) + storage_.clearProperty (uiElm, "Error"); + else + if ("clearMsg" == stateMark.idi.getSym()) + storage_.clearProperty (uiElm, "Message"); else storage_.record (uiElm, stateMark); } diff --git a/tests/gui/bus-term-test.cpp b/tests/gui/bus-term-test.cpp index b8d00f011..8e432b12d 100644 --- a/tests/gui/bus-term-test.cpp +++ b/tests/gui/bus-term-test.cpp @@ -268,14 +268,17 @@ namespace test { mockC.slotExpand(); CHECK (stateManager.currentState(charly, "expand") == GenNode("expand", true )); + // error states can be sticky + mockC.markErr("overinflated"); + CHECK (stateManager.currentState(charly, "Error") == GenNode("Error", "overinflated")); + mockC.reset(); CHECK (stateManager.currentState(charly, "expand") == Ref::NO); // back to void - ////////////////////////////////////////////////////////////////////////////////////////////////////TODO WIP + cout << "____Nexus-Log_________________\n" << util::join(gui::test::Nexus::getLog(), "\n") << "\n───╼━━━━━━━━━╾────────────────"< -
+
While our UI widgets are implemented the standard way as proposed by [[GTKmm|http://www.gtkmm.org/en/documentation.html]], some key elements -- which are especially relevant for the anatomy and mechanics of the interface at a whole -- are made to conform to a common interface and behaviour protocol. {{red{WIP 11/15 work out gradually what this protocol is all about}}}. #975
 As a starting point, we know
 * there is a backbone structure known as the UI-Bus
@@ -8432,7 +8432,7 @@ As a starting point, we know
 !Behaviours
 For some arbitrary reason, any element in the UI can appear and go away. This corresponds to attachment and deregistration at the UI-Bus
 
-In regular, operative state, an interface element may initiate //actions.// Even more: for //any conceivable, user visible, tangible action,// there is an interface element, which acts as point-of-service {{red{as of 12/15, this decision seems questionable}}}. There might be higher-level, cooperative [[gestures|Gesture]] within the interface, and actions might be formed like sentences, with the help of a FocusConcept -- however, in the end, there is a ''subject'' and a ''predicate''. And the interface element takes on the role of the underlying, the subject, the ''tangible''.
+In regular, operative state, an interface element may initiate //actions.// These correspond to invocation of [[Proc-Layer commands|CommandHandling]], after having supplied the necessary arguments. Commands are referred and called //by name// (~command-ID) and they are thus not bound to a specific UI-Element. Rather, it is the job of the UI to provide sensible command arguments, based on the context of the operation. There might be higher-level, cooperative [[gestures|Gesture]] within the interface, and actions might be formed like sentences, with the help of a FocusConcept -- however, in the end, there is a ''subject'' and a ''predicate''. And the interface element takes on the role of the underlying, the subject, the ''tangible''.
 
 Some actions are very common and can be represented by a shorthand. An example would be to tweak some property, which means to mutate the attribute of a model element known beforehand. Such tweaks are often caused by direct interaction, and thus have the tendency to appear in flushes, which might be batched to remove some load from the lower layers.
 
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index abd0a2842..f2659e943 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -118,14 +118,66 @@
 
 
 
-
-
-
-
-
+
+
+
+
+
+  
+    
+  
+  
+    

+      dafür genügt der normale Reset
+    

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

+      mark "clearMsg"
+    

+  
+
+
+
+
+
+  
+    
+  
+  
+    

+      mark "clearErr"
+    

+  
+
+
+
+
+
+  
+    
+  
+  
+    

+      mark "reset"
+    

+  
+
+
 
 
-
+
+
+
 
 
   
@@ -346,7 +398,74 @@
 
 
 
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+    
+  
+  
+    

+      nach Broadcast von "reset"
+    

+    

+      sollte logischerweise der PresentationStateManager leer sein
+    

+  
+
+
+
+  
+    
+  
+  
+    

+      ist er aber nicht notwendig,
+    

+    

+      denn er kann Zustand von nicht mehr existierenden Elementen aufgezeichnet haben.
+    

+    

+      Nur Elemente, die im Moment angeschlossen sind, bekommen die "reset"-Nachricht mit;
+    

+    

+      sofern sie tatsächlich abweichenden Zustand haben, sollten sie sich resetten
+    

+    

+      und eine state mark "reset" zurückschicken...
+    

+  
+
+
+
+
+
+
+
+
+
 
 
 
@@ -599,10 +718,10 @@
 
 
 
-
+
 
 
-
+
 
 
 
@@ -638,7 +757,8 @@
 
 
 
-
+
+
 
 
 
@@ -704,9 +824,10 @@
 
 
 
-
+
 
 
+
 
 
 
@@ -739,7 +860,9 @@
 
 
 
-
+
+
+
 
 
   
@@ -763,8 +886,23 @@
 
 
 
-
+
+
+  
+    
+  
+  
+    

+      konzeptionell: fertig
+    

+    

+      Implementierung der real-world-Variante fehlt!
+    

+  
+
+
 
+
 
 
   
@@ -900,7 +1038,8 @@
 
 
 
-
+
+
 
 
   
@@ -960,7 +1099,7 @@
 
 
 
-
+