From ffcac2ea1eb9f25e916a779abaca0303b5f4e331 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Fri, 6 Dec 2019 23:19:09 +0100 Subject: [PATCH] Structure-Change: implement a simplistic implementation of re-ordering ...verified by the rather conceptual unit test --- src/stage/model/view-hook.hpp | 28 ++++++++++++- tests/stage/model/view-hook-test.cpp | 40 +++++++++++++----- wiki/thinkPad.ichthyo.mm | 61 ++++++++++++++++++---------- 3 files changed, 96 insertions(+), 33 deletions(-) diff --git a/src/stage/model/view-hook.hpp b/src/stage/model/view-hook.hpp index 0f9434fad..46fd01894 100644 --- a/src/stage/model/view-hook.hpp +++ b/src/stage/model/view-hook.hpp @@ -57,6 +57,17 @@ namespace model { template class ViewHook; + + /** + * Interface to represent _"some presentation layout entity",_ + * with the ability to _attach_ widgets managed elsewhere, to + * relocate those widgets to another position, and to re-establish + * a different sequence of the widgets (whatever this means). + * @remark some typical examples for the kind of facility modelled here: + * - a _canvas widget,_ (e.g. `Gtk::Layout`), allowing to attach + * child widgets at specific positions, together with custom drawing. + * - a tree or grid control, allowing to populate some lines a given widget. + */ template class ViewHookable { @@ -66,6 +77,7 @@ namespace model { virtual ViewHook hook (ELM& elm, int xPos, int yPos) =0; virtual void move (ELM& elm, int xPos, int yPos) =0; virtual void remove (ELM& elm) noexcept =0; + virtual void rehook (ViewHook& hook) noexcept =0; template void reOrder (IT newOrder); @@ -140,12 +152,26 @@ namespace model { + /** + * re-attach elements in a given, new order. + * @param newOrder a Lumiera Forward Iterator to yield a reference to + * all attached elements, and in the new order to be established. + * @remark this operation becomes relevant, when "attaching an element" also + * constitutes some kind of arrangement in the visual presentation, like + * e.g. a stacking order, or by populating some table cells in sequence. + * The expected semantics is for this operation to detach each given element, + * and then immediately re-attach it _at the "beginning"_ (whatever this means). + * The element as such, and all associated presentation entities are not destroyed, + * but continue to exist with the same identity (and possibly all signal wirings). + * Just they now appear as if attached with the new ordering. + */ template template void ViewHookable::reOrder (IT newOrder) { - UNIMPLEMENTED ("generic mechanism for re-attachment in given order"); + for (ViewHook& existingHook : newOrder) + this->rehook (existingHook); } diff --git a/tests/stage/model/view-hook-test.cpp b/tests/stage/model/view-hook-test.cpp index 8cae5d8f1..f93a7bf90 100644 --- a/tests/stage/model/view-hook-test.cpp +++ b/tests/stage/model/view-hook-test.cpp @@ -32,8 +32,6 @@ #include "lib/iter-adapter-stl.hpp" #include "lib/util.hpp" -//#include -//#include #include #include #include @@ -43,9 +41,6 @@ using util::contains; using util::isSameObject; using lib::iter_stl::eachElm; -//using util::isnil; -//using std::make_unique; -//using std::move; using std::vector; using std::forward_list; using std::shuffle; @@ -98,7 +93,7 @@ namespace test { .transform([](Attachment const& entry) { return entry.widget; - }); + }); } auto @@ -133,11 +128,21 @@ namespace test { and pos->posY == y_expected; } + /** verify our internal sequence matches the given one */ template bool testContainsSequence (CON const& refSeq) { - UNIMPLEMENTED("compare our internal sequence with the given one"); + // NOTE the implementation twist of using a std::forward_list, + // which causes reversed order of our internal elements + auto iRef = refSeq.crbegin(); + auto eRef = refSeq.crend(); + auto iInt = widgets_.cbegin(); + auto eInt = widgets_.cend(); + for ( ; iRef != eRef and iInt != eInt; ++iRef, ++iInt) + if (not (iInt->widget == **iRef)) return false; + return iRef == eRef + and iInt == eInt; } @@ -167,6 +172,17 @@ namespace test { { widgets_.remove_if ([&](Attachment const& a) { return a.widget == elm; }); } + + + void + rehook (WidgetViewHook& existingHook) noexcept override + { + auto pos = findEntry (*existingHook); + REQUIRE (pos != widgets_.end(), "the given iterator must yield previously hooked-up elements"); + Attachment existing{*pos}; + this->remove (existing.widget); + this->addDummy(existing.widget, existing.posX,existing.posY); + } }; } @@ -175,9 +191,13 @@ namespace test { /*************************************************************************************//** * @test verify the mechanism to attach widgets to a canvas, while keeping the - * canvas widget itself opaque. - * - bla - * - blubb + * canvas implementation itself opaque. + * - manage the attachment and detach automatically + * - ability to adjust the location parameter of an existing attachment + * - ability to re-attach existing attachments in a new sequence order + * @remark this test focuses on the concepts and the API, and thus uses a + * dummy implementation of the "Canvas", which just registers a + * list of widgets with a dedicated "position" for each. * @see view-hook.hpp */ class ViewHook_test : public Test diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index d628dd49e..5e7c27440 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -4987,7 +4987,7 @@ - + @@ -18532,7 +18532,7 @@ - + @@ -19021,12 +19021,16 @@ - + + - + + + + @@ -19264,11 +19268,11 @@ - + - - + + @@ -19310,8 +19314,8 @@ - - + + @@ -19393,9 +19397,9 @@ - + - + @@ -19503,13 +19507,26 @@ - - + + + + + + + + + + + + + + + - - + + @@ -19523,9 +19540,9 @@ - + - + @@ -21669,8 +21686,8 @@ - - + + @@ -21679,9 +21696,9 @@ - + - + @@ -36037,7 +36054,7 @@ - +