From 78cbf0f57e9d42d5c1817cee7091f84b56ecb7af Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sat, 23 Sep 2017 17:55:40 +0200 Subject: [PATCH] UI-Coordinates: define basic design --- tests/gui/interact/ui-coord-test.cpp | 66 ++++++- wiki/renderengine.html | 53 ++++- wiki/thinkPad.ichthyo.mm | 280 ++++++++++++++++++++++++++- 3 files changed, 386 insertions(+), 13 deletions(-) diff --git a/tests/gui/interact/ui-coord-test.cpp b/tests/gui/interact/ui-coord-test.cpp index f0935f7bb..d107eb9e2 100644 --- a/tests/gui/interact/ui-coord-test.cpp +++ b/tests/gui/interact/ui-coord-test.cpp @@ -67,22 +67,78 @@ namespace test { virtual void run (Arg) { - verify_basicProperties(); - verify_queryFunctions(); + verify_basics(); + verify_builder(); + verify_comparisons(); + verify_queryAnchor(); + verify_queryCoverage(); + verify_mutateAnchor(); + verify_mutateCover(); + verify_mutateExtend(); + verify_mutateCreate(); } void - verify_basicProperties() + verify_basics() { UNIMPLEMENTED ("define basic properties of UI coordinates"); } void - verify_queryFunctions() + verify_builder() { - UNIMPLEMENTED ("query components and parts of the path"); + UNIMPLEMENTED ("verify the UI coordinate builder DSL"); + } + + + void + verify_comparisons() + { + UNIMPLEMENTED ("verify comparison of UI coordinates"); + } + + + void + verify_queryAnchor() + { + UNIMPLEMENTED ("query anchorage of given UI coordinates"); + } + + + void + verify_queryCoverage() + { + UNIMPLEMENTED ("query coverage of given UI coordinates with respect to actual UI"); + } + + + void + verify_mutateAnchor() + { + UNIMPLEMENTED ("mutate given UI coordinates by anchoring them"); + } + + + void + verify_mutateCover() + { + UNIMPLEMENTED ("mutate given UI coordinates by reducing to covered part"); + } + + + void + verify_mutateExtend() + { + UNIMPLEMENTED ("mutate given UI coordinates by uncovered extension"); + } + + + void + verify_mutateCreate() + { + UNIMPLEMENTED ("mutate given UI coordinates by creating new components"); } }; diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 6190c5be5..460408f4b 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -9615,7 +9615,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                                    
@@ -9629,6 +9629,57 @@ As starting point for the design of such a framework, we'll pick the notion of a
 * the panel within this window
 * a view group within the panel
 * plus a locally defined access path further down to the actual UI element
+
+!Properties
+UI coordinates are a symbolic specification, and as such, their representation is immutable value-like. Essentially, a coordinate specification designates a pathway, and thus is comprised of a sequence of symbols. The individual path component symbol can be addressed by its depth index, starting with the top level window as rooting point. The meaning of first steps of each path is thus always fixed (window, perspective, panel, view), followed by an essentially open sequence of local component names. Yet a given index position need not necessarily be actually defined. A coordinate spec can be indeterminate (nil), but in all other cases a minimal consecutive sequence of symbols is guaranteed to exist.
+
+!!!flavours of meaning
+A given coordinate spec needs to be //interpreted// with the help of a resolver, which supplies additional knowledge regarding the actual window and UI configuration backing those interpretations. Such an interpretation allows to query for some typical predications, and it allows for //mutating operations,// which actually build a new coordinate spec from the given one.
+The general assumption is for all those coordinate interpretations to happen not within an excessively performance critical zone, where a little bit of iteration and repeated recomputation is deemed less costly than extended caching of evaluation state.
+
+The first distinction to draw is the ''anchor point'' of a given coordinate spec. After anchoring, the designated path is explicitly rooted within a top level window. Obviously, the act of anchoring can be obvious(trivial), it can be //covered by wildcard,// or it can be a free interpolation or match against the existing environment. Starting from the anchor, the next predication to consider is the ''coverage'': the extent to which a given coordinate spec is actually covered by real UI structures. The test for coverage starts at the anchor point and descends following the coordinate spec in question. Backed by this evaluation process of interpretation and matching, we may judge a coordinate spec with respect to several predications
+* the coordinate spec may be totally ''explicit'' -- or it might contain wildcards
+* one specific path component of the coordinate spec may be known(present) or unknown
+* regarding the coverage, we may distinguish
+** a totally covered coordinate spec
+** a partially covered coordinate spec
+** a coordinate spec impossible to cover
+
+!UI coordinate path evaluation
+As indicated above, evaluation of UI coordinates requires a resolver, and this evaluation process is //stateless.// Evaluation state is confined within the individual query or mutation call. 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.
+!!!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
+:the way the given coordinate spec is or can be anchored
+:* it is already //explicitly anchored// and this anchorage can be covered and backed by the currently existing UI configuration
+:* it //can be a anchored// by interpolation of some wildcards
+:* it is //incomplete// and need to be extended to allow anchoring
+:* it is //impossible to anchor// in the current UI configuration
+;coverage
+:the extent to which a given coordinate spec is backed by the actual UI configuration
+:please note: to determine the coverage, the spec need to anchored (either explicitly, or by interpolation, or by extension of an incomplete spec)
+:* it is //completely covered//
+:* it is //partially covered// with an remaining, uncovered extension part
+:* it is //possible to cover completely//
+:* it is //impossible to cover//
+!!!Mutations
+In addition to querying the interpretation of a given coordinate spec with respect to the current UI environment, it is also possible to rewrite or extend the spec based on this environment
+;anchoring
+:in correspondence to the possible states of anchorage, we may derived an explicitly anchored spec
+:*by interpolating the given spec
+:*by interpolation and extension of the given spec
+;covering
+:we may construct the covered part of a given spec, including automatic anchoring.
+;navigating
+:we may rewrite a given spec by navigating within the existing UI environment
+:as starting point, the coordinate spec need to be anchored and completely covered
+:from the topological UI position designated thus far, we may
+:*ascend
+:*descend to an existing child by matching name or index
+:*extend the path by an uncovered extension sequence
+:*extend the path by creating suitable child components
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 738e953f9..12bf80091 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -3407,7 +3407,7 @@ - + @@ -3591,7 +3591,8 @@ - + + @@ -3619,6 +3620,270 @@ + + + + + + + + +

+ UI-Koordinaten (UICoord) +

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

+ ...and this anchorage can be covered and backed by the currently existing UI configuration +

+ + + + + + + + + + +

+ ...by interpolation of some wildcards +

+ + + + + + + + + + +

+ ...need to be extended to allow anchoring +

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

+ we may construct the covered part of a given spec, including automatic anchoring. +

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

+ navigate to the real UI component +

+

+ designated by the given coordinate spec +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -3654,9 +3919,10 @@ - + + @@ -12589,7 +12855,7 @@ - + @@ -12601,7 +12867,7 @@ - + @@ -12609,7 +12875,7 @@ - + @@ -13048,7 +13314,7 @@ - +