diff --git a/src/gui/interact/view-spec-dsl.hpp b/src/gui/interact/view-spec-dsl.hpp index 8fd225877..c5a164b3e 100644 --- a/src/gui/interact/view-spec-dsl.hpp +++ b/src/gui/interact/view-spec-dsl.hpp @@ -121,7 +121,7 @@ namespace interact { * It takes a _viewID_ as argument, which actually is more of a typeID to designate * the kind of view or UI widget, which shall be attached at or retrieved from the * location resolved through the LocationRule. The latter is essentially what is - * embedded within the Locator functor + * embedded within the Locator functor. */ using Locator = std::function; @@ -130,32 +130,41 @@ namespace interact { * A specification to describe the desired location of a component view within the Lumiera UI. * ViewSpec 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. - * - * @todo initial draft as of 9/2017 + * @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. + * 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). */ - class ViewSpec + template + class LocatorSpec + : public Locator { public: - ViewSpec(UICoord coordinates) + LocatorSpec(UICoord coordinates) + : Locator([](Literal componentID) -> UICoord + { + UNIMPLEMENTED ("resolve a view spec to yield explicit UI coordinates"); + }) { UNIMPLEMENTED ("build a view spec from explicitly given UI coordinates"); } /** shortcut to allow initialisation from UI-Coordinate builder expression */ - ViewSpec(UICoord::Builder&& coordinates) - : ViewSpec{UICoord(std::move (coordinates))} + LocatorSpec(UICoord::Builder&& coordinates) + : LocatorSpec{UICoord(std::move (coordinates))} { } - UICoord - operator() (Literal componentID) - { - UNIMPLEMENTED ("resolve a view spec to yield explicit UI coordinates"); - } - private: - }; + /** + * A specification to describe the desired location of a component view within the Lumiera UI. + * ViewSpec 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. + */ + using ViewSpec = LocatorSpec; + /** * Allocator is a functor to resolve a given, desired location of a view within the UI, resulting diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 258ede273..88509ecde 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -2838,7 +2838,7 @@ Command instances are like prototypes -- thus each additional level of different see the description in → 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
@@ -2858,7 +2858,7 @@ Here, //Allocation// means
 The classical example to verify this definition is the //allocation of viewers:// when starting playback of a new media item, we "need a viewer" to show it. But we can not just create yet another viewer window -- rather we're bound to allocate one of the possible "viewer slots". In fact this is a configurable property of the UI layout employed; sometimes some people need the limitation to one single viewer entity (which might even be external, routed to a beamer or monitor), while other ones request the classical editor layout with two viewer windows side by side, while yet different working styles might exploit a limited set of viewers allocated in stack- or round-robin style.
 
 !View access
-The global access point to component views is the {{{ViewLocator}}} within InteractionDirector, which exposes a generic access- and management API to
+The global access point to component views is the ViewLocator within InteractionDirector, which exposes a generic access- and management API to
 * get (possibly create) some view of given type
 * get (possibly create) a view with specific identity
 * destroy a specific view
@@ -3730,7 +3730,7 @@ Especially the focus navigation entails the use of some kind of ubiquitous [[coo
-
+
//the top-level controller within the UI.//
 In Lumiera, the structures of the model within the [[Session]] (the so called HighLevelModel) are mapped onto corresponding [[tangible UI entities|UI-Element]], which serve as a front-end to represent those entities towards the user. Within this model, there is a //conceptual root node// -- which logically corresponds to the session itself. This [[root element in model|ModelRootMO]] links together the actual top-level entities, which are the (multiple) timelines, together with the asset management and defaults and rules configuration within the session.
 
@@ -3752,6 +3752,7 @@ The InteractionDirector is part of the model, and thus we have to distinguish be
 :* the SpotLocator is what is "moved" when the [[Spot]] of current activity moves
 :* the FocusTracker is responsible for //detecting changes in current selection and focus.//
 :* the [[Navigator]] is a special controller to handle moving the SpotLocator within the UI tree topology
+:* the ViewLocator serves for any kind of high-level, abstracted access to [[component views|GuiComponentView]] and location resolution.
 
 !Collaborations
 * several global actions are exposed here, like opening the session and creating a new timeline.<br/>Such operations are typically bound into menu and action buttons, and in turn invoke [[commands|CommandHandling]] into the Session
@@ -4288,7 +4289,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.
 
@@ -4312,6 +4313,10 @@ In the current situation ({{red{10/2017}}}), before engaging into the actual imp
 :* or to get //just some instance// of a view identified by type
 ;WorkSite navication
 :move the Spot to some other place in the UI known by its [[UI-Coordinates|UICoord]]
+!!!{{red{Update 2/2018:}}} changed responsibilities
+Elaboration on the topic of »View Allocation« caused some minor architectural rearrangements.
+* Navigator became a pure information service (read-only), working on an abstracted view of the UI through [[UI coordinates|UICoord]]
+* the ViewLocator became service point for any high-level access to GuiComponentView elements
 
 !!!Requirements clarified
 From these use cases we conclude that the actual requirements for a Navigator component are less than one might expect.
@@ -9846,6 +9851,14 @@ Establishing a ~ViewConnection is prerequisite for creating or attaching an Play
 View connections are part of the model and thus persistent. They can be created explicitly, or just derived by //allocating a viewer.// And a new view connection can push aside (and thus "break") an existing one from another timeline or model element. When a view connection is //broken,// any associated PlayProcess needs to be terminated (this is a blocking operation). Thus, at any time, there can be only one active view connection to a given viewer or output sink; here "active" means, that a PlayController has been hooked up, and the connection is ready for playback or rendering. But on the other hand, nothing prevents a timeline (or similar model object) to maintain multiple view connections -- consequently the actual playback position behaves as if associated with the view connection; it has only meaning with respect to this specific connection. An obvious example is that you may play back, without interfering with an ongoing render.
+
+
//access and location of [[component views|GuiComponentView]] as abstracted from actual UI widgets.//
+The ViewLocator is a close sibling and mutually interdependent with the [[Navigator]] -- the primary difference being the uniform, completely symbolic representation by [[UI-tree topology|UICoord]], as exposed through the latter, which precludes //immediate manipulation.// The ViewLocator likewise presents an abstracted view, but oriented towards individual components, which it allows to locate, allocate and expose by direct reference as UI-Element.
+
+!Rules based handling by kind-of-view
+A small selection of //relevant UI elements// can in fact be located "by-type", relying on a configuration in the form of //locating rules...// &rarr; elaborated in more detail [[here|GuiComponentView]].
+This access mechanism allows to act on "the primary one of that kind", possibly creating a new instance on demand -- such UI elements are not to be confused with the model entities they expose for user interaction; typically they can either be re-linked or re-bound to a specific entity, or they are able to handle multiple model connections in separate tabs within the view (e.g. several [[Timelines|GuiTimelineView]]).
+
A [[structural Asset|StructAsset]] corresponding to a Viewer element in the GUI.
 
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 1eff0e04f..860a6b82b 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -10223,13 +10223,193 @@
 
 
 
-
-
+
+
 
 
 
-
-
+
+
+
+
+
+
+
+  
+    
+  
+  
+    

+      der Level im UI ist noch offen
+    

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

+      fast immer ist das aber UIC_VIEW
+    

+  
+
+
+
+  
+    
+  
+  
+    

+      im Moment fällt mir überhaupt keine Ausnahme ein
+    

+    

+      aber man soll niemals nie sagen;
+    

+    

+      
+    

+    

+      jedenfalls ist der LocationSolver komplett generisch geschrieben,
+    

+    

+      wäre ja auch dämlich, den auf einen Level festzunageln
+    

+  
+
+
+
+
+
+  
+    
+  
+  
+    

+      kann man den Level erschließen?
+    

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

+      es ist nicht klar, ob die pattern bereits das fragliche View-Element mit einschließen,
+    

+    

+      oder ob das View-Element noch angehängt werden soll. Diese Variation ist essentiell,
+    

+    

+      um Regeln auszudrücken, die explizit nur eine schon existierende UI-Komponente greifen
+    

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

+      auto locate = matchView(
+    

+    

+                                panel("blah")
+    

+    

+                                or currentWindow().panel("blubb").create() )
+    

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

+      LocatorSpec<UIC_VIEW> locate = panel("blah")
+    

+    

+                                                           or currentWindow().panel("blubb").create()
+    

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

+      ViewSpec locate = panel("blah")
+    

+    

+                                      or currentWindow().panel("blubb").create()
+    

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