From f1ea503cfa098a8306440ff7968a7e75a4df35b4 Mon Sep 17 00:00:00 2001
From: Ichthyostega <prg@ichthyostega.de>
Date: Sun, 6 May 2018 01:45:38 +0200
Subject: [PATCH] ViewSpec: singleton factory to organise the actual ViewSpec
 DSL tokens

it seems apropriate to move the base definition of gui::idi::Descriptor<VIEW>
into view-spec-dsl.hpp and only retain the actual DSL definitions in id-scheme.hpp
---
 src/gui/id-scheme.hpp              |  8 --------
 src/gui/interact/view-locator.hpp  |  3 +--
 src/gui/interact/view-spec-dsl.hpp | 26 ++++++++++++++++++++++++++
 src/gui/model/element-access.hpp   |  6 +++---
 4 files changed, 30 insertions(+), 13 deletions(-)

diff --git a/src/gui/id-scheme.hpp b/src/gui/id-scheme.hpp
index a22bc9a97..94bb0ca48 100644
--- a/src/gui/id-scheme.hpp
+++ b/src/gui/id-scheme.hpp
@@ -87,14 +87,6 @@ namespace gui {
     using ErrorLogView = widget::ErrorLogWidget;
     
     
-    /** Generic Component View descriptors */
-    template<class V>
-    struct Descriptor
-      {
-        static_assert (not sizeof(V), "unknown generic view type");
-      };
-    
-    
     /**
      * Descriptor for the Timeline UI
      */
diff --git a/src/gui/interact/view-locator.hpp b/src/gui/interact/view-locator.hpp
index 44d47e56e..eb023a66c 100644
--- a/src/gui/interact/view-locator.hpp
+++ b/src/gui/interact/view-locator.hpp
@@ -119,8 +119,7 @@ namespace interact {
   inline V&
   ViewLocator::get()
   {
-    using ViewSpec = idi::Descriptor<V>;
-    ViewSpec viewSpec;                              /////////////////////////////////////////////////////////TICKET #1129 : can't create instances all the time. Need some kind of Factory
+    auto& viewSpec = idi::viewSpec<V>();
     Symbol viewID{lib::idi::typeSymbol<V>()};
     
     UICoord targetLocation = viewSpec.locate(viewID);
diff --git a/src/gui/interact/view-spec-dsl.hpp b/src/gui/interact/view-spec-dsl.hpp
index d5bac7fa1..473838ae7 100644
--- a/src/gui/interact/view-spec-dsl.hpp
+++ b/src/gui/interact/view-spec-dsl.hpp
@@ -261,5 +261,31 @@ namespace idi {
   
   extern AllocSpec<uint> limitAllocation;
   
+  
+  /** Generic Component View descriptors */
+  template<class V>
+  struct Descriptor
+    {
+      static_assert (not sizeof(V), "unknown generic view type");
+    };
+   // for the actual specialisations: see id-scheme.hpp
+  
+  
+  /**
+   * Access point: Factory for "view specs".
+   * These are (singleton) instances of idi::Descriptor<V>, and assumed to expose
+   * - a member `viewSpec.locate`, which solves for the actual view location within UI topology
+   * - a member `viewSpec.alloc`, which actually claims / allocates an existing or new view instance
+   * @see gui::ctrl::ViewLocator::get
+   */
+  template<class VIEW>
+  inline Descriptor<VIEW>&
+  viewSpec()
+  {
+    static Descriptor<VIEW> dslInstance;
+    return dslInstance;
+  }
+  
+  
 }}// namespace gui::idi
 #endif /*GUI_INTERACT_VIEW_SPEC_DSL_H*/
diff --git a/src/gui/model/element-access.hpp b/src/gui/model/element-access.hpp
index 174f3fb5d..d74e0cd20 100644
--- a/src/gui/model/element-access.hpp
+++ b/src/gui/model/element-access.hpp
@@ -29,7 +29,7 @@
  ** 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
+ ** generates a control structure of its own. And another kind of generic access happens
  ** when we _navigate_ the topological UI structure for focus management.
  ** 
  ** This interface defines an abstract service to translate a generic element designation
@@ -131,7 +131,7 @@ namespace model {
    * public API functions are templated to the _result type as expected by the invoking clinent_
    * and thus we get a matrix of possible cases; when the expected result type is _reachable by
    * dynamic downcast_ from the actual base interface type returned by the internal access function,
-   * we can perform this dynamic_cast. Otherwise the returned result proxy object is marked as empty.
+   * we can perform this `dynamic_cast`. Otherwise the returned result proxy object is marked as empty.
    * @remark technically this solution relies on the lib::Variant::Visitor to provide a NOP default
    *         implementation. The TypeConverter template is instantiated with the desired target type
    *         and thus only overwrites _the first case where an conversion is possible._ In all other
@@ -146,7 +146,7 @@ namespace model {
       
       template<typename X>                             // note the "backward" use. We pick that base interface
       using canUpcast = std::is_convertible<TAR*, X>; //  into which our desired result type can be upcast, because
-                                                     //   we know then the following dynamic_cast (downcast) can succeed  
+                                                     //   we know the then following dynamic_cast (downcast) can succeed
       using Base = typename RawResult::FirstMatching<canUpcast>::Type;
       
       virtual void