benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

ElementAccess: initial brainstorming about the interface mechanics

Browse source
This commit is contained in:
Fischlurch 2018-04-07 02:28:29 +02:00
parent dc97ab5546
commit 09359cf92a
11 changed files with 168 additions and 161 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

67
src/gui/ctrl/elem-access-dir.hpp
View file

@ -22,18 +22,18 @@
/** @file elem-access-directory.hpp
** Generic building block in the Lumiera GUI model.
** A model::Element has a unique identifier, which is tied to the
** identification scheme used in the "real" model in Proc-Layer.
** Model elements can be addressed receive mutations caused by changes
** and rebuilding of elements within the Session; moreover, a generic
** representation of attributes is provided.
** A service to discover and access raw UI elements in a cross cutting way.
** This is the actual low-level implementation of the model::ElementAccess interface
** Tightly coupled to the internals of Lumiera's GTK UI, this implementation embodies
** all the inside knowledge necessary to navigate over the various levels (Windows,
** panels, views, specific components) to get at those elements abstracted as
** UI-Coordinates.
**
** @note as of 1/2015 this is a first draft and WIP-WIP-WIP
** @todo WIP ///////////////////////TICKET #1134
** @note as of 4/2018 this is a first draft and will remain unimplemented for the time being
** @todo WIP-WIP-WIP need to learn more about the concrete UI implementation ///////////////////////TICKET #1134
**
** @see ////TODO_test usage example
** @see element.cpp implementation
** @see view-locator.hpp
** @see navigator.hpp
**
*/
@ -43,67 +43,46 @@
#include "lib/error.hpp"
#include "lib/nocopy.hpp"
#include "lib/hash-value.h"
#include "gui/model/element-access.hpp"
//#include "lib/symbol.hpp"
#include "lib/util.hpp"
//#include "lib/util.hpp"
#include <string>
//#include <string>
namespace gui {
namespace model {
namespace ctrl{
using lib::HashVal;
using util::isnil;
using std::string;
// using util::isnil;
// using std::string;
/**
* Basic (abstracted) view of...
*
* @see SomeSystem
* @see NA_test
* Low-level service to navigate the internals of the Lumiera GTK UI.
* @todo mostly not yet implemented as of 4/2018 -- need to learn more about aforementioned internals.
*/
template<class X>
class ElemAccessDir
: public model::ElementAccess
{
string nothing_;
public:
explicit
ElemAccessDir (string const& b)
: nothing_(b)
ElemAccessDir ()
{ }
// using default copy/assignment
/* == Adapter interface for == */
void
setSolution (string const& solution ="")
{
UNIMPLEMENTED ("tbw");
#if false /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1134
if (isDeaf())
this->transmogrify (solution);
#endif /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1134
}
protected:
void maybe () const;
friend HashVal
hash_value (Element const& entry)
{
return hash_value (entry.nothing_);
}
};
@ -113,16 +92,10 @@ namespace model {
/** @internal in case
*/
template<class X>
inline void
ElementAccess<X>::maybe () const
{
UNIMPLEMENTED ("tbw");
}
}} // namespace gui::model
}} // namespace gui::ctrl
#endif /*GUI_CTRL_ELEM_ACCESS_DIR_H*/

113
src/gui/model/element-access.hpp
View file

@ -22,18 +22,28 @@
/** @file element-access.hpp
** Generic building block in the Lumiera GUI model.
** A model::Element has a unique identifier, which is tied to the
** identification scheme used in the "real" model in Proc-Layer.
** Model elements can be addressed receive mutations caused by changes
** and rebuilding of elements within the Session; moreover, a generic
** representation of attributes is provided.
** Interface to discover and access raw UI elements in a cross cutting way.
** We have several orthogonal identification and access schemes within the UI.
** A naively written UI application just attaches the core logic below some widgets and
** controllers -- not only does this lead to a hard to maintain codebase, this approach
** is even outright impossible for Lumiera, since the core is able to run standalone and
** the UI is loaded as plug-in, which places us into the situation to connect a self
** contained core with a self contained UI. This is a binding, which, as a sideline, also
** generates a control structure of its own. An another kind of generic access happens
** when we _navigate_ the topological UI structure for focus management.
**
** @note as of 1/2015 this is a first draft and WIP-WIP-WIP
** This interface defines an abstract service to translate a generic element designation
** into a (language level) access to internal structures of the UI toolkit (GTK in our case).
** This access to low-level structure proceeds in two stages:
** - navigate down the UI topology. Optionally, this may involve a mutation (create element)
** - evaluate the result (found, not found, element created) and access the target,
** possibly with conversion (which might fail)
**
** @note as of 4/2018 this is a first draft and WIP-WIP-WIP
** @todo WIP ///////////////////////TICKET #1134
**
** @see ////TODO_test usage example
** @see element.cpp implementation
** @see ElementAccess_test
** @see elem-access-dir.hpp implementation
**
*/
@ -44,65 +54,54 @@
#include "lib/error.hpp"
#include "lib/nocopy.hpp"
#include "lib/hash-value.h"
#include "lib/result.hpp"
#include "gui/interact/ui-coord.hpp"
//#include "lib/symbol.hpp"
#include "lib/util.hpp"
//#include "lib/util.hpp"
#include <string>
//#include <string>
namespace gui {
namespace model {
using lib::HashVal;
using util::isnil;
using std::string;
using interact::UICoord;
// using util::isnil;
// using std::string;
/**
* Basic (abstracted) view of...
* Interface: access UI elements by navigating the UI topology.
*
* @see SomeSystem
* @see NA_test
* @see gui::interact::Navigator
* @see ElementAccess_test
*/
template<class X>
class ElementAccess
: util::NonCopyable
{
string nothing_;
public:
explicit
ElementAccess (string const& b)
: nothing_(b)
{ }
// using default copy/assignment
virtual ~ElementAccess () { } ///< this is an interface
template<class TAR>
using Result = lib::Result<TAR>;
/* == Adapter interface for == */
/* == Access by Location == */
void
setSolution (string const& solution ="")
{
UNIMPLEMENTED ("tbw");
template<class TAR>
Result<TAR&> access (UICoord destination);
template<class TAR>
Result<TAR&> access_or_create (UICoord destination);
protected:
#if false /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1134
if (isDeaf())
this->transmogrify (solution);
#endif /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1134
}
protected:
void maybe () const;
friend HashVal
hash_value (Element const& entry)
{
return hash_value (entry.nothing_);
}
};
@ -110,13 +109,31 @@ namespace model {
/** @internal in case
/** Navigate the UI topology to access the designated component
* @return suitably converted direct (language) reference to the desired element
* wrapped as _result proxy_
* @note when access was not possible because the element does not exist,
* the result proxy is empty and convertible to `bool(false)`
*/
template<class X>
inline void
ElementAccess<X>::maybe () const
template<class TAR>
inline ElementAccess::Result<TAR&>
ElementAccess::access (UICoord destination)
{
UNIMPLEMENTED ("tbw");
UNIMPLEMENTED ("delegate to a suitable polymorphic navigation function");
}
/** Navigate to the designated component, possibly create the element and parents
* @return suitably converted direct (language) reference to the desired element
* wrapped as _result proxy_
* @note when access was not possible because the element could not been created,
* the result proxy is empty and convertible to `bool(false)`
*/
template<class TAR>
inline ElementAccess::Result<TAR&>
ElementAccess::access_or_create (UICoord destination)
{
UNIMPLEMENTED ("delegate to a suitable polymorphic navigation/creation function");
}

28
src/lib/result.hpp
View file

@ -24,15 +24,13 @@
/** @file result.hpp
** Intermediary value object to represent the result of an operation.
** This operation might have produced a value result or failed with an exception.
** Typically, the Result token is used \em inline -- immediately either invoking
** Typically, the Result token is used _inline_ -- immediately either invoking
** one of the member function or employing the built-in result type conversion.
** It will be copyable iff the result value is copyable. There is an implicit
** valid or failure state, which can be tested. Any attempt to get the value
** of an invalid result token will cause in an exception to be thrown.
** of an invalid result token will cause an exception to be thrown.
**
** @todo WIP and rather brainstorming as of 2/10
**
** @see backend::ThreadJob usage example
** @see backend::ThreadJoinable usage example
*/
@ -58,7 +56,7 @@ namespace lib {
/**
* Optional Result value or status of some operation.
* It can be created for passing a result produced by the operation, or the
* It can be created for passing a result produced by the operation, or the
* failure to do so. The value can be retrieved by implicit or explicit conversion.
* @throw error::State on any attempt to access the value in case of failure
* @warning this class has a lot of implicit conversions;
@ -74,18 +72,18 @@ namespace lib {
public:
/** mark an invalid/failed result */
Result ()
: failureLog_("no result")
: failureLog_{"no result"}
{ }
/** failed result, with reason given.*/
Result (lumiera::Error const& reason)
: failureLog_(reason.what())
{ }
: failureLog_{reason.what()}
{ }
/** standard case: valid result */
Result (RES const& value)
: failureLog_("")
, value_(value)
: failureLog_{}
, value_{value}
{ }
@ -99,7 +97,7 @@ namespace lib {
void
maybeThrow() const
{
if (!isValid())
if (not isValid())
throw error::State (failureLog_, lumiera_error_peek());
}
@ -131,12 +129,12 @@ namespace lib {
public:
/** mark either failure (default) or success */
Result (bool success =false)
: failureLog_(success? "": "operation failed")
: failureLog_{success? "": "operation failed"}
{ }
/** failed result, with reason given.*/
Result (lumiera::Error const& reason)
: failureLog_(reason.what())
: failureLog_{reason.what()}
{ }
@ -150,7 +148,7 @@ namespace lib {
void
maybeThrow() const
{
if (!isValid())
if (not isValid())
throw error::State (failureLog_, lumiera_error_peek());
}
};

33
tests/gui/ctrl/element-access-test.cpp
View file

@ -20,16 +20,17 @@
* *****************************************************/
/** @file view-spec-dsl-test.cpp
** unit test \ref ViewSpecDSL_test
/** @file element-access-test.cpp
** unit test \ref ElementAccess_test
*/
#include "lib/test/run.hpp"
#include "lib/test/test-helper.hpp"
#include "gui/interact/view-spec-dsl.hpp"
//#include "gui/interact/view-spec-dsl.hpp"
#include "test/test-element-access.hpp"
#include "gui/interact/ui-coord.hpp"
#include "gui/interact/gen-node-location-query.hpp"
//#include "gen-node-location-query.hpp"
#include "lib/depend-inject.hpp"
#include "lib/format-cout.hpp"
//#include "lib/idi/entry-id.hpp"
@ -40,9 +41,9 @@
//#include <vector>
using std::string;
using lib::diff::MakeRec;
using lib::diff::Rec;
//using std::string;
//using lib::diff::MakeRec;
//using lib::diff::Rec;
//using lib::idi::EntryID;
//using lib::diff::GenNode;
//using util::isSameObject;
@ -50,13 +51,13 @@ using lib::diff::Rec;
namespace gui {
namespace interact {
namespace model {
namespace test {
// using lumiera::error::LUMIERA_ERROR_WRONG_TYPE;
using lib::test::showSizeof;
// using lib::test::showSizeof;
using MockLoationSolver = lib::DependInject<UILocationSolver>::Local<>;
using MockAccess = lib::DependInject<ElementAccess>::Local<TestElementAccess>;
namespace { //Test fixture...
@ -64,12 +65,12 @@ namespace test {
/******************************************************************************//**
* @test verify the mechanics of a functor based internal DSL
* to configure access and allocation patters for component views.
* @test verify the usage pattern of low-level UI element access, based on a
* mock implementation of the accessor directory.
*
* @see id-scheme.hpp
* @see ViewLocator
* @see UICoord_test
* @see ViewSpecDSL_test
*/
class ElementAccess_test : public Test
{
@ -77,6 +78,8 @@ namespace test {
virtual void
run (Arg)
{
MockAccess fakeDirectory;
// verify_basicProperties();
verify_standardUsage();
verify_alternatives();
@ -121,7 +124,7 @@ namespace test {
/** Register this test class... */
LAUNCHER (ElementAccess, "unit gui");
LAUNCHER (ElementAccess_test, "unit gui");
}}} // namespace gui::interact::test
}}} // namespace gui::model::test

0
src/gui/interact/gen-node-location-query.hpp → tests/gui/gen-node-location-query.hpp
View file

2
tests/gui/interact/ui-coord-resolver-test.cpp
View file

@ -29,7 +29,7 @@
#include "lib/test/test-helper.hpp"
#include "gui/interact/ui-coord.hpp"
#include "gui/interact/ui-coord-resolver.hpp"
#include "gui/interact/gen-node-location-query.hpp"
#include "gen-node-location-query.hpp"
#include "lib/diff/gen-node.hpp"
#include "lib/format-util.hpp"
#include "lib/util.hpp"

2
tests/gui/interact/ui-location-solver-test.cpp
View file

@ -29,7 +29,7 @@
#include "lib/test/test-helper.hpp"
#include "gui/interact/ui-coord.hpp"
#include "gui/interact/ui-location-solver.hpp"
#include "gui/interact/gen-node-location-query.hpp"
#include "gen-node-location-query.hpp"
#include "lib/format-cout.hpp"
#include <string>

2
tests/gui/interact/view-spec-dsl-test.cpp
View file

@ -29,7 +29,7 @@
#include "lib/test/test-helper.hpp"
#include "gui/interact/view-spec-dsl.hpp"
#include "gui/interact/ui-coord.hpp"
#include "gui/interact/gen-node-location-query.hpp"
#include "gen-node-location-query.hpp"
#include "lib/depend-inject.hpp"
#include "lib/format-cout.hpp"
//#include "lib/idi/entry-id.hpp"

39
tests/gui/test/test-element-access.hpp
View file

@ -43,22 +43,19 @@
#include "lib/error.hpp"
#include "lib/nocopy.hpp"
#include "lib/hash-value.h"
#include "gui/model/element-access.hpp"
//#include "lib/symbol.hpp"
#include "lib/util.hpp"
//#include "lib/util.hpp"
#include <string>
//#include <string>
namespace gui {
namespace model {
using lib::HashVal;
using util::isnil;
using std::string;
// using util::isnil;
// using std::string;
/**
@ -67,43 +64,23 @@ namespace model {
* @see SomeSystem
* @see NA_test
*/
template<class X>
class ElementAccess
class TestElementAccess
: public ElementAccess
{
string nothing_;
public:
explicit
ElementAccess (string const& b)
: nothing_(b)
TestElementAccess ()
{ }
// using default copy/assignment
/* == Adapter interface for == */
void
setSolution (string const& solution ="")
{
UNIMPLEMENTED ("tbw");
#if false /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1134
if (isDeaf())
this->transmogrify (solution);
#endif /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1134
}
protected:
void maybe () const;
friend HashVal
hash_value (Element const& entry)
{
return hash_value (entry.nothing_);
}
};
@ -113,12 +90,14 @@ namespace model {
/** @internal in case
*/
#if false /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1134
template<class X>
inline void
ElementAccess<X>::maybe () const
{
UNIMPLEMENTED ("tbw");
}
#endif /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1134

6
wiki/renderengine.html
View file

@ -9912,11 +9912,11 @@ In addition to querying the interpretation of a given coordinate spec with respe
__Navigation mutations:__ //In theory,// it would even be possible to extend the path by creating suitable child components; but actually this would require all &quot;elements&quot; to implement a suitable mutation interface -- which in the case of //generic elements// might be far beyond the common ground. For this reason, we keep mutation of the backing environment outside of a path mutator's scope and rather keep mutation limited to the path itself.
</pre>
</div>
<div title="UILowLevelAccess" creator="Ichthyostega" modifier="Ichthyostega" created="201804062255" tags="spec draft GuiPattern" changecount="1">
<div title="UILowLevelAccess" creator="Ichthyostega" modifier="Ichthyostega" created="201804062255" modified="201804062321" tags="spec draft GuiPattern" changecount="2">
<pre>//Cross cutting access to elementary UI structures.//
We have several orthogonal identification and access schemes within the UI. A naively written UI application just attaches the core logic below some widgets and controllers -- not only does this lead to a hard to maintain codebase, this approch is even outright impossible in our case, due to the strict decoupling between core and GUI, which places us into the situation to connect a self contained core with a self contained UI. This is a binding, which, as a sideline, also generates a control structure of its own. We can indeed write code dealing with a generic UI element -- but there needs to be some place where this kind of generic designation is translated into internal structures of the UI toolkit (GTK in our case), to obtain a direct (language) reference to some implementation widget finally.
We have several orthogonal identification and access schemes within the UI. A naively written UI application just attaches the core logic below some widgets and controllers -- not only does this lead to a hard to maintain code base, this approach is even outright impossible in our case, due to the strict decoupling between core and GUI, which places us into the situation to connect a self contained core with a self contained UI. This is a binding, which, as a sideline, also generates a control structure of its own. We can indeed write code dealing with a generic UI element -- but there needs to be some place where this kind of generic designation is translated into internal structures of the UI toolkit (GTK in our case), to obtain a direct (language) reference to some implementation widget finally.
A service to translate some generic address scheme into actual entities builds the foundation of designating a &quot;place withih the UI&quot; by abstracted topological [[UI coordinates|UICoord]]. It allows to define //rules// how some generic [[kind of view|GuiComponentView]] shall be //placed and allocated// into the existing UI structure.
A service to translate some generic address scheme into actual entities builds the foundation of designating a &quot;place within the UI&quot; by abstracted topological [[UI coordinates|UICoord]]. It allows to define //rules// how some generic [[kind of view|GuiComponentView]] shall be //placed and allocated// into the existing UI structure.
!Notes about design and implementation {{red{WIP 4/2018}}}
At the time of this writing, it is not really clear if we need such a facility and what form its implementation will take -- which in turn places several further planning steps and design consideration into dangling state. The programmer's usual remedy in such a situation is to create yet another abstraction as a tie break. We do not know what it is, but at least we can write unit tests against it to find out what it could be.

37
wiki/thinkPad.ichthyo.mm
View file

@ -12622,6 +12622,43 @@
</node>
</node>
</node>
<node CREATED="1523059565187" ID="ID_685856143" MODIFIED="1523059569334" TEXT="Implementierung">
<node CREATED="1523059570619" ID="ID_1720611397" MODIFIED="1523059579790" TEXT="Problem: Typisierung">
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1523059593831" ID="ID_1175935224" MODIFIED="1523059666434" TEXT="will mich nicht auf eine Basisklasse festlegen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
model::Tangible ist sch&#246;n,
</p>
<p>
aber ich wei&#223; nicht, ob das nicht zu eingeschr&#228;nkt ist.
</p>
<p>
Beispielsweise werden Panel oder WorkspaceWindow ganz sicher keine Tangibles sein,
</p>
<p>
aber es k&#246;nnte durchaus sein, da&#223; man auf sie generisch zugreifen m&#246;chte
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1523059669693" ID="ID_11075132" MODIFIED="1523059678809" TEXT="lib::AccessCasted">
<icon BUILTIN="idea"/>
</node>
</node>
<node CREATED="1523059717622" ID="ID_598506387" MODIFIED="1523059721041" TEXT="Grundstruktur">
<node CREATED="1523059685611" ID="ID_1274858318" MODIFIED="1523059711165" TEXT="lib::Result">
<icon BUILTIN="idea"/>
</node>
<node CREATED="1523059729276" ID="ID_117320755" MODIFIED="1523059751029" TEXT="sollte auf die Struktur von LocationQuery hinauslaufen"/>
<node CREATED="1523059751905" ID="ID_345254237" MODIFIED="1523059757668" TEXT="aber mit zus&#xe4;tzlichen Operationen...."/>
</node>
</node>
<node CREATED="1523053331956" ID="ID_563797148" MODIFIED="1523053334615" TEXT="Test">
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1523053336219" ID="ID_1234019560" MODIFIED="1523053434519" TEXT="ElementAccess_test">
<linktarget COLOR="#43667c" DESTINATION="ID_1234019560" ENDARROW="Default" ENDINCLINATION="-345;-1481;" ID="Arrow_ID_839730277" SOURCE="ID_1539184761" STARTARROW="None" STARTINCLINATION="-530;453;"/>