diff --git a/src/gui/model/tangible.hpp b/src/gui/model/tangible.hpp index 215fd6683..5134c4de9 100644 --- a/src/gui/model/tangible.hpp +++ b/src/gui/model/tangible.hpp @@ -91,10 +91,10 @@ namespace model { void slotExpand() { this->doExpand(); } void slotReveal() { this->doReveal(); } - void noteMsg (string m) { this->doMsg(m); } - void noteErr (string e) { this->doErr(e); } - void noteFlash() { this->doFlash();} - void noteMark(GenNode const& n) { this->doMark(n);} + void markMsg (string m) { this->doMsg(m); } + void markErr (string e) { this->doErr(e); } + void markFlash() { this->doFlash();} + void mark(GenNode const& n) { this->doMark(n);} protected: virtual void doReset() =0; diff --git a/tests/gui/abstract-tangible-test.cpp b/tests/gui/abstract-tangible-test.cpp index 95056097f..98876c815 100644 --- a/tests/gui/abstract-tangible-test.cpp +++ b/tests/gui/abstract-tangible-test.cpp @@ -113,49 +113,55 @@ namespace test { } - /** @test how to retrieve and enumerate session contents - * as operation initiated from GUI display code + /** @test verify the UI widget unit test support framework. + * The generic backbone of the Lumiera UI offers a mock UI element, + * with the ability to stand-in for actual elements present in the real GUI. + * This allows us to rig a emulated test user interface to cover interactions + * involving some communication from or to interface elements. After setting up + * a [MockElm] with a suitable name / ID, we're able to operate this element + * programmatically and to send messages and responses from the core "up" + * to this mocked interface. And since this mock element embodies an + * [event log][EventLog], the unit test code can verify the occurrence + * of expected events, invocations and responses. */ void verify_mockManipulation () { MockElm mock("dummy"); - mock.verify("ctor"); - mock.verifyEvent("ctor"); - mock.verify("ctor").arg("dummy"); + CHECK (mock.verify("ctor")); + CHECK (mock.verifyEvent("ctor")); + CHECK (mock.verify("ctor").arg("dummy")); CHECK ("dummy" == mock.getID().getSym()); CHECK (EntryID("dummy") == mock.getID()); - VERIFY_ERROR (ASSERTION, mock.verifyCall("reset")); + CHECK (!mock.verifyCall("reset")); mock.reset(); - mock.verify("reset"); - mock.verifyCall("reset"); - mock.verifyEvent("reset"); - mock.verify("reset").after("ctor"); - mock.verify("ctor").before("reset"); - VERIFY_ERROR (ASSERTION, mock.verify("reset").before("ctor")); - VERIFY_ERROR (ASSERTION, mock.verify("ctor").after("reset")); + CHECK (mock.verify("reset")); + CHECK (mock.verifyCall("reset")); + CHECK (mock.verifyCall("reset").on("dummy")); + CHECK (mock.verifyEvent("reset")); + CHECK (mock.verify("reset").after("ctor")); + CHECK (mock.verify("ctor").before("reset")); + CHECK (mock.ensureNot("reset").before("ctor")); + CHECK (mock.ensureNot("ctor").after("reset")); - mock.verify("reset").before("reset"); - mock.verify("reset").beforeEvent("reset"); - mock.verifyCall("reset").before("reset"); - mock.verifyCall("reset").beforeEvent("reset"); - VERIFY_ERROR (ASSERTION, mock.verifyCall("reset").afterCall("reset")); - VERIFY_ERROR (ASSERTION, mock.verifyCall("reset").afterEvent("reset")); - VERIFY_ERROR (ASSERTION, mock.verifyEvent("reset").afterEvent("reset")); + CHECK (mock.verify("reset").before("reset")); + CHECK (mock.verify("reset").beforeEvent("reset")); + CHECK (mock.verifyCall("reset").beforeEvent("reset")); + CHECK (!mock.verifyCall("reset").afterEvent("reset")); CHECK (!mock.isTouched()); CHECK (!mock.isExpanded()); - mock.noteMsg("dolorem ipsum quia dolor sit amet consectetur adipisci velit."); - mock.verifyNote("Msg"); - mock.verifyCall("noteMsg"); - mock.verifyCall("noteMsg").arg("lorem ipsum"); - mock.verifyCall("noteMsg").argMatch("dolor.+dolor\\s+"); - mock.verifyMatch("Rec\\(note.+kind = Msg.+msg = dolorem ipsum"); + mock.markMsg("dolorem ipsum quia dolor sit amet consectetur adipisci velit."); + CHECK (mock.verifyNote("Msg")); + CHECK (mock.verifyCall("noteMsg")); + CHECK (mock.verifyCall("noteMsg").arg("lorem ipsum")); + CHECK (mock.verifyCall("noteMsg").argMatch("dolor.+dolor\\s+")); + CHECK (mock.verifyMatch("Rec\\(note.+kind = Msg.+msg = dolorem ipsum")); EventLog log = mock.getLog(); log.verify("ctor") @@ -164,30 +170,30 @@ namespace test { MockElm foo("foo"), bar("bar"); foo.verify("ctor").arg("foo"); - bar.verify("ctor").arg(); + bar.verify("ctor").arg("bar"); bar.ensureNot("foo"); log.ensureNot("foo"); mock.ensureNot("foo"); - VERIFY_ERROR (ASSERTION, foo.ensureNot("foo")); + CHECK (!foo.ensureNot("foo")); bar.joinLog(mock); foo.joinLog(mock); - log.verifyEvent("logJoin").arg("bar") - .beforeEvent("logJoin").arg("foo"); + CHECK (log.verifyEvent("logJoin").arg("bar") + .beforeEvent("logJoin").arg("foo")); - mock.verifyEvent("logJoin").arg("bar") - .beforeEvent("logJoin").arg("foo"); - mock.verify("ctor").arg("foo"); - log.verify("ctor").arg("foo"); - log.verify("ctor").arg("dummy") - .before("ctor").arg("bar") - .before("ctor").arg("foo"); + CHECK (mock.verifyEvent("logJoin").arg("bar") + .beforeEvent("logJoin").arg("foo")); + CHECK (mock.verify("ctor").arg("foo")); + CHECK (log.verify("ctor").arg("foo")); + CHECK (log.verify("ctor").arg("dummy") + .before("ctor").arg("bar") + .before("ctor").arg("foo")); mock.kill(); - foo.noteMsg("dummy killed"); - log.verifyEvent("dtor").on("dummy") - .beforeCall("noteMsg").on("foo"); + foo.markMsg("dummy killed"); + CHECK (log.verifyEvent("dtor").on("dummy") + .beforeCall("noteMsg").on("foo")); } diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 5fee35901..ad0e5c0e7 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -2900,7 +2900,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. Obviously, there needs to be some kind of coherency in the way matters are arranged -- this is the realm of conventions and guidelines. But, in any more than trivial UI application, there is an intermediate level, where things go on, which can not fully be just 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? 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 strive at an abstract intermediary space, with the ability to assimilate the practical situation yet to come.
 
@@ -2913,7 +2913,7 @@ The interface programming allows us to react on events and trigger behaviour, an
 ;shift of perspective
 :and while we work, the focus moves along. Some things are closer, other things are remote and require us to move and re-orient and reshape our perspective, should we choose to turn towards them.
 ;the ability to arrange what is relevant
-:we do the same stuff again and again, and this makes us observe and understand matters. As we reveal the inner nature of what we're doing, we desire to arrange close at hand what belongs together, and to expunge the superficial and distracting.
+:we do the same stuff again and again, and this makes us observe and gradually understand matters. As we reveal the inner nature of what we're doing, we desire to arrange close at hand what belongs together, and to expunge the superficial and distracting. 
A facility within the GUI to// track and manage one specific aspect of interaction state.//
@@ -8371,7 +8371,7 @@ The UI-Bus is a ''Mediator'' -- impersonating the role of the //Model// and the
 
 The ~MVC-Pattern as such is fine, and probably the best we know for construction of user interfaces. But it doesn't scale well towards the integration into a larger and more structured system. There is a tension between the Controller in the UI and other parts of an application, which as well need to be //in control.// And, even more important, there is a tension between the demands of UI elements for support by a model, and the demands to be placed on a core domain model of a large scale application. This tension is resolved by enacting these roles while transforming the requests and demands into //Messages.//
-
+
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
@@ -8384,7 +8384,7 @@ As a starting point, we know
 * these in turn request a diff and then update themselves into compliance.
 
 !Behaviours
-For some reason, any element in the UI can appear and go away. This corresponds to attachment and deregistration at the UI-Bus
+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. //This is a decision.// 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''.
 
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 9fda46f65..4a338ae48 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -154,8 +154,7 @@
       sinnvoll?
     

   
-
-
+
 
   
     
@@ -165,8 +164,7 @@
       was haben alle UI-Elemente wirklich gemeinsam?
     

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

   
-
-
+
 
 
 
@@ -217,8 +214,7 @@
       Problem: InteractionControl
     

   
-
-
+
 
 
 
@@ -238,8 +234,7 @@
       da im Übrigen das UI-Modell nur mit LUIDs und generischen Namen arbeitet
     

   
-
-
+
 
 
 
@@ -257,8 +252,7 @@
       besser: InvocationTrail
     

   
-
-
+
 
 
 
@@ -296,8 +290,7 @@
       bleiben zusammen
     

   
-
-
+
 
 
 
@@ -350,8 +343,7 @@
       Daher ist es besser, einmal, wenn die Argumente bekannt werden, diese zum Prototypen zu schicken
     

   
-
-
+
 
 
 
@@ -365,8 +357,7 @@
       Wichtig (offen): Instanz-Management
     

   
-
-
+
 
 
 
@@ -383,8 +374,7 @@
       muß auch geforkt werden
     

   
-
-
+
 
 
 
@@ -427,7 +417,7 @@
 
 
 
-
+