diff --git a/src/gui/ctrl/elem-access-dir.hpp b/src/gui/ctrl/elem-access-dir.hpp new file mode 100644 index 000000000..a249a252b --- /dev/null +++ b/src/gui/ctrl/elem-access-dir.hpp @@ -0,0 +1,128 @@ +/* + ELEM-ACCESS-DIR.hpp - service to access generic elements in the UI + + Copyright (C) Lumiera.org + 2018, Hermann Vosseler + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of + the License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +*/ + + +/** @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. + ** + ** @note as of 1/2015 this is a first draft and WIP-WIP-WIP + ** @todo WIP ///////////////////////TICKET #1134 + ** + ** @see ////TODO_test usage example + ** @see element.cpp implementation + ** + */ + + +#ifndef GUI_CTRL_ELEM_ACCESS_DIR_H +#define GUI_CTRL_ELEM_ACCESS_DIR_H + + +#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 + + + +namespace gui { +namespace model { + + using lib::HashVal; + using util::isnil; + using std::string; + + + /** + * Basic (abstracted) view of... + * + * @see SomeSystem + * @see NA_test + */ + template + class ElemAccessDir + { + string nothing_; + + public: + explicit + ElemAccessDir (string const& b) + : nothing_(b) + { } + + // 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_); + } + }; + + + + + + + /** @internal in case + */ + template + inline void + ElementAccess::maybe () const + { + UNIMPLEMENTED ("tbw"); + } + + + + + +}} // namespace gui::model +#endif /*GUI_CTRL_ELEM_ACCESS_DIR_H*/ diff --git a/src/gui/interact/view-spec-dsl.hpp b/src/gui/interact/view-spec-dsl.hpp index cd862e5c9..8d3feb355 100644 --- a/src/gui/interact/view-spec-dsl.hpp +++ b/src/gui/interact/view-spec-dsl.hpp @@ -134,7 +134,7 @@ namespace interact { * LocatorSpec is basically a set of [UI coordinates](\ref UICoord), with the additional possibility * of specifying several alternatives, with the intention to pick the first applicable one. * @tparam depth the level in the tree addressed by this locator - * @remarks Locator is build from a DSL expression, which is basically a UICoord::Builder. + * @remarks Locator is built from a DSL expression, which is basically a UICoord::Builder. * This coordinate spec describes a sequence of several places where to locate * the UI-Element in question. The template parameter clarifies if we're talking * about windows here, or panels or views. The latter is the [default case](\ref ViewSpec). diff --git a/src/gui/model/element.hpp b/src/gui/model/element-access.hpp similarity index 87% rename from src/gui/model/element.hpp rename to src/gui/model/element-access.hpp index e65a3ea93..0955760d6 100644 --- a/src/gui/model/element.hpp +++ b/src/gui/model/element-access.hpp @@ -1,5 +1,5 @@ /* - ELEMENT.hpp - a generic element in the UI-Model + ELEMENT-ACCESS.hpp - access to generic elements in the UI Copyright (C) Lumiera.org 2015, Hermann Vosseler @@ -21,7 +21,7 @@ */ -/** @file element.hpp +/** @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. @@ -30,7 +30,7 @@ ** representation of attributes is provided. ** ** @note as of 1/2015 this is a first draft and WIP-WIP-WIP - ** @todo WIP ///////////////////////TICKET #959 + ** @todo WIP ///////////////////////TICKET #1134 ** ** @see ////TODO_test usage example ** @see element.cpp implementation @@ -38,8 +38,8 @@ */ -#ifndef GUI_MODEL_ELEMENT_H -#define GUI_MODEL_ELEMENT_H +#ifndef GUI_MODEL_ELEMENT_ACCESS_H +#define GUI_MODEL_ELEMENT_ACCESS_H #include "lib/error.hpp" @@ -67,13 +67,13 @@ namespace model { * @see NA_test */ template - class Element + class ElementAccess { string nothing_; public: explicit - Element (string const& b) + ElementAccess (string const& b) : nothing_(b) { } @@ -87,10 +87,10 @@ namespace model { setSolution (string const& solution ="") { UNIMPLEMENTED ("tbw"); -#if false /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #888 +#if false /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1134 if (isDeaf()) this->transmogrify (solution); -#endif /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #888 +#endif /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1134 } @@ -114,7 +114,7 @@ namespace model { */ template inline void - Element::maybe () const + ElementAccess::maybe () const { UNIMPLEMENTED ("tbw"); } @@ -124,4 +124,4 @@ namespace model { }} // namespace gui::model -#endif /*GUI_MODEL_ELEMENT_H*/ +#endif /*GUI_MODEL_ELEMENT_ACCESS_H*/ diff --git a/tests/gui/ctrl/element-access-test.cpp b/tests/gui/ctrl/element-access-test.cpp new file mode 100644 index 000000000..15e33e4ad --- /dev/null +++ b/tests/gui/ctrl/element-access-test.cpp @@ -0,0 +1,127 @@ +/* + ElementAccess(Test) - verify mechanics of low-level UI element access + + Copyright (C) Lumiera.org + 2018, Hermann Vosseler + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of + the License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +* *****************************************************/ + +/** @file view-spec-dsl-test.cpp + ** unit test \ref ViewSpecDSL_test + */ + + +#include "lib/test/run.hpp" +#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 "lib/depend-inject.hpp" +#include "lib/format-cout.hpp" +//#include "lib/idi/entry-id.hpp" +//#include "lib/diff/gen-node.hpp" +//#include "lib/util.hpp" + +//#include +//#include + + +using std::string; +using lib::diff::MakeRec; +using lib::diff::Rec; +//using lib::idi::EntryID; +//using lib::diff::GenNode; +//using util::isSameObject; +//using util::isnil; + + +namespace gui { +namespace interact { +namespace test { + +// using lumiera::error::LUMIERA_ERROR_WRONG_TYPE; + using lib::test::showSizeof; + + using MockLoationSolver = lib::DependInject::Local<>; + + namespace { //Test fixture... + + }//(End)Test fixture + + + /******************************************************************************//** + * @test verify the mechanics of a functor based internal DSL + * to configure access and allocation patters for component views. + * + * @see id-scheme.hpp + * @see ViewLocator + * @see UICoord_test + */ + class ElementAccess_test : public Test + { + + virtual void + run (Arg) + { +// verify_basicProperties(); + verify_standardUsage(); + verify_alternatives(); + + verify_genericInvocation(); + } + + + void + verify_basicProperties() + { + UNIMPLEMENTED ("basic properties of the view spec DSL"); + } + + + void + verify_standardUsage() + { + } + + + void + verify_alternatives() + { + UNIMPLEMENTED ("querying and selection of location alternatives"); + } + + + void + verify_genericInvocation() + { + /////////////////////////////////////////////////////////////////////////////////////////TICKET 1134 : how to create ViewLocator mock without global context?? + //-------------------------------------------------------------Test-Fixture + //--------------------------------------------------------------(End)Test-Fixture + +// ErrorLogView errorLog = viwLocator.get(); +// TimelineView timeline = viwLocator.get(); + + /////////////////////////////////////////////////////////////////////////////////////////TICKET 1134 : use an EventLog to verify the forwarded invocations?? + } + }; + + + /** Register this test class... */ + LAUNCHER (ElementAccess, "unit gui"); + + +}}} // namespace gui::interact::test diff --git a/tests/gui/test/test-element-access.hpp b/tests/gui/test/test-element-access.hpp new file mode 100644 index 000000000..fb3edfaf6 --- /dev/null +++ b/tests/gui/test/test-element-access.hpp @@ -0,0 +1,128 @@ +/* + TEST-ELEMENT-ACCESS.hpp - fake access directory to handle generic UI entities for test + + Copyright (C) Lumiera.org + 2018, Hermann Vosseler + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of + the License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +*/ + + +/** @file test-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. + ** + ** @note as of 1/2015 this is a first draft and WIP-WIP-WIP + ** @todo WIP ///////////////////////TICKET #1134 + ** + ** @see ////TODO_test usage example + ** @see element.cpp implementation + ** + */ + + +#ifndef GUI_MODEL_TEST_ELEMENT_ACCESS_H +#define GUI_MODEL_TEST_ELEMENT_ACCESS_H + + +#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 + + + +namespace gui { +namespace model { + + using lib::HashVal; + using util::isnil; + using std::string; + + + /** + * Basic (abstracted) view of... + * + * @see SomeSystem + * @see NA_test + */ + template + class ElementAccess + { + string nothing_; + + public: + explicit + ElementAccess (string const& b) + : nothing_(b) + { } + + // 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_); + } + }; + + + + + + + /** @internal in case + */ + template + inline void + ElementAccess::maybe () const + { + UNIMPLEMENTED ("tbw"); + } + + + + + +}} // namespace gui::model +#endif /*GUI_MODEL_TEST_ELEMENT_ACCESS_H*/ diff --git a/wiki/renderengine.html b/wiki/renderengine.html index dc3ca42a0..9e6767098 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -2906,7 +2906,7 @@ Command instances are like prototypes -- thus each additional level of different see the description in &rarr; CommandSetup -
+
//A view within the UI, featuring some component of relevance to »the model«.//
 While any UI is comprised of numerous widgets acting as //view of something,// only some of those views play the prominent role to act as //building block component// of the user interface.
 Such UI component views exhibit some substantial traits
@@ -3037,6 +3037,7 @@ It is not clear yet {{red{as of 2/2018}}}, if those additional complexities are
 
 !!!Semantics of allocation
 While the process of probing and matching the location specification finally yields an explicit UICoord path to the desired element, it is up to the allocation step actually to decide on the action to be taken. Some allocation operations impose some kind of limit, and are thus free to ignore the given spec and rather return an existing element in place. In the end, the purpose of this whole matching and allocation process is to get hold of a suitable UI component without knowing its precise coordinates in the UI topology. And this is the very property to enable flexible mapping of the strictly hierarchical session structures onto the UI in a fluid way.
+&rarr; [[low level component access|UILowLevelAccess]]
@@ -4357,7 +4358,7 @@ The UI-Bus offers a dedicated API to direct ~MutationMessages towards {{{Tangibl In the case at hand, the basic building block of the Lumiera UI, the {{{Tangible}}} offers this interface and thus the ability to construct a concrete TreeMutator, which in turn is bound to the internals of the actual UI-Element in question. Together this allows for a generic implementation of MutationMessage handling, where the designated UI-Element is reshaped by applying a concrete diff sequence embedded in the message with the help of a {{{DiffApplicator<DiffMutable>}}}, based on the TreeMutator exposed.
-
+
//Service to navigate through the UI as generic structure.//
 The Navigator is a component maintained by the InteractionDirector, and the actual implementation is backed by several facilities of the GuiTopLevel. It serves as foundation to treat the UI as a topological network of abstracted locations, represented as [[UI-Coordinates|UICoord]]. This design, together with the UI-Bus helps to reduce coupling within the UI implementation, since it enables to //get somewhere// and reach //some place// -- without the necessity to rely on concrete widget implementation structure.
 
@@ -4391,7 +4392,7 @@ From these use cases we conclude that the actual requirements for a Navigator co
 In fact it is sufficient to keep //the actual element// entirely opaque, so the Navigator works on [[UI coordinates|UICoord]] solely. The result -- some other UI coordinates -- can then be used to accomplish some tasks implemented elsewhere, like allocating a new view or actually moving [[the Spot|Spot]] (&rarr; InteractionControl)
 
 !Challenges of the implementation
-Some tricky problems remain to be solved, though: since the Navigator works on UI coordinates, the fundamental problem remains how to acquire the initial coordinates to start navigation. This is a problem of //reverse lookup:// given a concrete element of the UI, find it's UI coordinates. While we should note that it might not be necessary to "discover" coordinates, because in fact we may know them already -- either the element has to store them (on creation), or some lookup index table could be maintained to serve the same purpose
+Some tricky problems remain to be solved, though: since the Navigator works on UI coordinates, the fundamental problem remains how to acquire the initial coordinates to start navigation. This is a problem of //reverse lookup:// given a concrete element of the UI, find it's UI coordinates. While we should note that it might not be necessary to "discover" coordinates, because in fact we may know them already -- either the element has to store them (on creation), or some lookup index table could be maintained to serve the same purpose. The actual access to low-level UI entities generates a host of further tecnicalities, which we attempt to stash away into a different low-level service, the  [[gui:ctrl::ElmAccessDir|UILowLevelAccess]].
 
 Moreover, the design of coordinate matching and resolving incurs a structure similar to [[render job planning|FrameDispatcher]] -- and the corresponding design problems remain to be solved in a satisfactory way &rarr; [[some notes...|AboutMonads]]
 
@@ -9845,7 +9846,7 @@ The dispatch of //diff messages// is directly integrated into the UI-Bus -- whic
 
 The Graphical User interface, the upper layer in this hierarchy, embodies everything of tangible relevance to the user working with the application. The interplay with Proc-Layer, the middle layer below the UI, is organised along the distinction between two realms of equal importance: on one side, there is the immediate //mechanics of the interface,// which is implemented directly within the ~UI-Layer, based on the Graphical User Interface Toolkit. And, on the other side, there are those //core concerns of working with media,// which are cast into the HighLevelModel at the heart of the middle layer.
-
+
//A topological addressing scheme to designate structural locations within the UI.//
 Contrary to conventional screen pixel coordinates, here we aim at a topological description of the UI structure. Such a framework of structural reference allows us                                                                     
 * to refer to some "place" or "space" within the interface                                    
@@ -9877,7 +9878,7 @@ The first distinction to draw is the ''anchor point'' of a given coordinate spec
 !UI coordinate path evaluation
 As indicated above, evaluation of UI coordinates requires a ''resolver'', to perform a search and matching operation and to hold the evaluation state. Evaluation is accomplished by first constituting an anchoring, followed by traversal of the coordinate spec and matching against a navigation path within the actual UI window configuration. This process might involve interpretation of some meta-symbols and interpolation of wildcards.
 
-Internally the coordinate resolver in turn relies on a context query interface, to find out about existing windows, panels, views and tabs and to navigate the real UI structure. The actual implementation of this context query interface is backed by the [[Navigator]] component exposed through the InteractionDirector.
+Internally the coordinate resolver in turn relies on a context query interface, to find out about existing windows, panels, views and tabs and to navigate the real UI structure. The actual implementation of this context query interface is backed by the [[Navigator]] component exposed through the InteractionDirector. In practice, the Navigator relies on another service for the [[low level access to UI components|UILowLevelAccess]]
 !!!Query operations
 In addition to the //locally decidable properties// of a coordinate spec, which are the explicitness and the presence of some component, several contextual predications may be queried 
 ;anchorage
@@ -9911,6 +9912,16 @@ 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 "elements" 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.
+
+
//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.
+
+A service to translate some generic address scheme into actual entities builds the foundation of designating a "place withih the UI" 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.
+
+
For any kind of playback to happen, timeline elements (or similar model objects) need to be attached to a Viewer element through a special kind of [[binding|BindingMO]], called a ''view connection''. In the most general case, this creates an additional OutputMapping (and in the typical standard case, this boils down to a 1:1 association, sending the master bus of each media kind to the standard OutputDesignation for that kind).
 
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index dc8c20acf..f7cc821a4 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -3565,7 +3565,8 @@
 
 
 
-
+
+
 
 
 
@@ -9312,8 +9313,9 @@
 
 
 
-
+
 
+
 
 
 
@@ -10038,8 +10040,7 @@
       ein LocationSolver
     

   
-
-
+
 
 
 
@@ -10052,8 +10053,7 @@
       LocationQuery qua Navigator
     

   
-
-
+
 
 
 
@@ -10081,8 +10081,7 @@
       sehen ViewLocator-API
     

   
-
-
+
 
 
 
@@ -11963,28 +11962,29 @@
 
 
 
-
+
+
 
-
+
 
-
-
+
+
 
-
+
 
-
-
-
+
+
+
 
 
 
-
+
 
-
-
-
+
+
+
 
-
+
 
 
 
@@ -12577,6 +12577,76 @@
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+  
+    
+  
+  
+    

+      Schicht unter dem ViewLocator
+    

+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
@@ -14912,6 +14982,190 @@
   
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+  
+    
+  
+  
+    

+      (GlobalCtx)->InteractionDirector (=Model Root)
+    

+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+    
+  
+  
+    

+      (GlobalCtx)->InteractionDirector->Navigator
+    

+  
+
+
+
+
+
+
+
+  
+    
+  
+  
+    

+      (GlobalCtx)->WindowLocator->UIComponentAccessor
+    

+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+    
+  
+  
+    

+      (GlobalCtx)->InteractionDirector->ViewLocator
+    

+  
+
+
+
+
+
+
+
+  
+    
+  
+  
+    

+      (GlobalCtx)->WindowLocator->UIComponentAccessor
+    

+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+    
+  
+  
+    

+      man muß die Implementierungs-Details jeder einzelnen Komponente kennen,
+    

+    

+      um damit überhaupt etwas anfangen zu können. Es gibt hier keine schematische Ordnung.
+    

+    

+      Selbst die Frage, ob es sich um ein Blatt handelt, oder um einen inneren Knoten,
+    

+    

+      erfordert bereits Kenntnis der Innereien
+    

+  
+
+
+
+
+
+
+
+
+  
+    
+  
+  
+    

+      (GlobalCtx)->WindowLocator
+    

+  
+
+
+
+
+
+
+
+  
+    
+  
+  
+    

+      (GlobalCtx)->WindowLocator->PanelLocator
+    

+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+