ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

return to topic: UI element protocol

Browse source 
next step will be to rig the mock element and set up
and cover the basic / generic element behaviour

This changeset
 - adapts the (planned) unit test to the semantic of
   the EventLog, which is now fully implemented

 - adjusts the function names on the public Tangible interface,
   to be better in line with the naming convention of the
   corrsponding operations on the UI-Bus:

   * "mark" operations are towards the UI element
   * "note" messages are from the UI element towards some
     state manager, which can be reached via the bus
This commit is contained in:
Fischlurch 2015-12-16 02:16:53 +01:00
parent cb4a0a6e60
commit a9a6aabcbc
4 changed files with 65 additions and 69 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
src/gui/model/tangible.hpp
View file

@ -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;

86
tests/gui/abstract-tangible-test.cpp
View file

@ -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<MockElm>("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"));
}

8
wiki/renderengine.html
View file

@ -2900,7 +2900,7 @@ The InstanceHandle is created by the service implementation and will automatical
&amp;rarr; see [[detailed description here|LayerSeparationInterfaces]]
</pre>
</div>
<div title="InteractionControl" creator="Ichthyostega" modifier="Ichthyostega" created="201511272315" modified="201511272320" tags="design decision Concepts GuiPattern draft discuss" changecount="2">
<div title="InteractionControl" creator="Ichthyostega" modifier="Ichthyostega" created="201511272315" modified="201512160022" tags="design decision Concepts GuiPattern draft discuss" changecount="3">
<pre>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 &quot;OK&quot; 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.</pre>
: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.</pre>
</div>
<div title="InteractionStateManager" creator="Ichthyostega" modifier="Ichthyostega" created="201511280402" tags="def design GuiIntegration draft" changecount="1">
<pre>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.//</pre>
</div>
<div title="UI-Element" creator="Ichthyostega" modifier="Ichthyostega" created="201511210307" modified="201511280638" tags="GuiPattern design draft decision" changecount="17">
<div title="UI-Element" creator="Ichthyostega" modifier="Ichthyostega" created="201511210307" modified="201512160029" tags="GuiPattern design draft decision" changecount="18">
<pre>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''.

32
wiki/thinkPad.ichthyo.mm
View file

@ -154,8 +154,7 @@
sinnvoll?
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<richcontent TYPE="NOTE"><html>
<head>
@ -165,8 +164,7 @@
was haben alle UI-Elemente wirklich gemeinsam?
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="help"/>
<node CREATED="1448658692023" ID="ID_888978058" MODIFIED="1448659524029" TEXT="generische Commands">
<richcontent TYPE="NOTE"><html>
@ -184,8 +182,7 @@
oder handelt es sich nur um ein Implementierungsdetail der UI-Bus-Anbindung?
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="help"/>
<node CREATED="1448659456882" ID="ID_946761955" MODIFIED="1448659469420" TEXT="Notwendig: Command-Name + Varargs"/>
</node>
@ -217,8 +214,7 @@
Problem: <b><font color="#8d02e1">InteractionControl</font></b>
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<arrowlink COLOR="#5f0ac8" DESTINATION="ID_329609486" ENDARROW="Default" ENDINCLINATION="219;-148;" ID="Arrow_ID_1101633958" STARTARROW="None" STARTINCLINATION="-205;4;"/>
</node>
</node>
@ -238,8 +234,7 @@
da im &#220;brigen das UI-Modell nur mit LUIDs und generischen Namen arbeitet
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
</node>
</node>
@ -257,8 +252,7 @@
besser: <b>InvocationTrail</b>
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<arrowlink COLOR="#81759f" DESTINATION="ID_1679641405" ENDARROW="Default" ENDINCLINATION="604;-108;" ID="Arrow_ID_1210299906" STARTARROW="None" STARTINCLINATION="702;0;"/>
<arrowlink COLOR="#aaa9c1" DESTINATION="ID_1193936433" ENDARROW="Default" ENDINCLINATION="392;0;" ID="Arrow_ID_1338946264" STARTARROW="Default" STARTINCLINATION="392;0;"/>
<icon BUILTIN="button_ok"/>
@ -296,8 +290,7 @@
bleiben zusammen
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1448683496794" ID="ID_821199097" MODIFIED="1448683517556" TEXT="unterst&#xfc;tzt weiterreichende Konzepte">
<node CREATED="1448683518496" ID="ID_1987782234" MODIFIED="1448683521843" TEXT="Perspektiven"/>
@ -350,8 +343,7 @@
Daher ist es besser, <i>einmal</i>, wenn die Argumente bekannt werden, diese zum Prototypen zu schicken
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
</node>
<node CREATED="1448691875184" ID="ID_642935499" MODIFIED="1448691904352" TEXT="f&#xfc;r die Invocation gen&#xfc;gt dann die reine ID"/>
@ -365,8 +357,7 @@
Wichtig <font color="#e10409">(offen)</font>: Instanz-Management
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1448692240015" ID="ID_58254695" MODIFIED="1448692245826" TEXT="es geht um Allokationen in Proc"/>
<node CREATED="1448692247478" ID="ID_1199512787" MODIFIED="1448692258689" TEXT="jede Instanz == Eintrag in der Command-Registry"/>
@ -383,8 +374,7 @@
mu&#223; auch geforkt werden
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="idea"/>
</node>
</node>
@ -427,7 +417,7 @@
<node CREATED="1448669854119" ID="ID_874080079" MODIFIED="1448669857794" TEXT="wertet Regeln aus"/>
<node CREATED="1448669869973" ID="ID_1259588429" MODIFIED="1448669888646" TEXT="sendet Enablement">
<node CREATED="1448669889514" ID="ID_1191247113" MODIFIED="1448669898645" TEXT="an die konkreten Trigger-Orte"/>
<node CREATED="1448669899113" ID="ID_990871123" MODIFIED="1448669910611" TEXT="er sendet jeweils einen CommandInvocationPath"/>
<node CREATED="1448669899113" ID="ID_990871123" MODIFIED="1450228230836" TEXT="er sendet jeweils einen CommandInvocationTrail"/>
</node>
</node>
</node>