While our UI widgets are implemented the standard way as proposed by GTKmm, some key elements -- which are especially relevant for the anatomy and mechanics of the interface -- are made to conform to a common interface and behaviour protocol. {{red{WIP 11/15 work out what this protocol is all about}}}. #975
As a starting point, we know
* there is a backbone structure known as the UI-Bus
@@ -8339,6 +8339,28 @@ These manipulations in itself do not constitute an action. But there typically i
A special case of state marking is the presentation of transient feedback. Such feedback is pushed from "somewhere" towards given elements, which react through an implementation dependent visual state change (flushing, colour change, marker icon). If such state marking is to be persistent, the interface element has in turn to send a specific state mark. An example would be a permanent error flag with a explanatory text showed in mouse over. Which in turn means there can also be sweeping state reset messages, which are to be broadcasted: A general "reset", an indication to collapse everything, or to clear pending error flags.
And finally, there are the //essential updates// -- any changes in the model //for real.// These are sent as notifications just to some top level element, expecting this element to request a diff and to recursively mutate contents into shape.
+
+
+!Interactions
+;new
+:connect to an existing term, supply the {{{EntryID}}} of the new element
+;act
+:send a GenNode representing the action
+;mark
+:send a GenNode representing the //state mark//
+;note
+:receive a GenNode representing the //feedback//
+;signals
+:the individual element exposes some generic signal slots
+:* sigMut prompts the element to draw a diff to alter its configuration
+:* sigExpand promts the element to transition into expanded / unfolded state. If this state is sticky, the element should answer with a ''mark''
+:* sigShow prompts the element to bring the indicated child into sight
+;diff
+:ask to retrieve a diff, which
+:* either is an incremental status update
+:* or is a from-scratch reconfiguration
+
+We should note that these conventions of interchange lead to a ''self similar design'' of the UI-Bus: Each {{{BusTerm}}} is a personalised connection to yet another {{{BusTerm}}}. Even the ''bus master'' appears as just another {{{BusTerm}}} to all the communication partners. The overall topology of the bus might be reshaped without the participating elements being aware of such a change.
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 7cdf46716..56bc7c20a 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -17,8 +17,7 @@
Struktur