diff --git a/tests/gui/interact/ui-location-solver-test.cpp b/tests/gui/interact/ui-location-solver-test.cpp index e4cb5e395..f74c33dba 100644 --- a/tests/gui/interact/ui-location-solver-test.cpp +++ b/tests/gui/interact/ui-location-solver-test.cpp @@ -373,9 +373,8 @@ namespace test { LocationRule location{UICoord().persp("edit").panel("viewer")}; location.append (UICoord::currentWindow().panel("viewer")); location.append (UICoord().panel("viewer")); - location.append (UICoord().tab("type(Asset)")); +// location.append (UICoord().tab("assetType()")); //////////////////////TICKET #1130 : do we want to support match based on invocation context (here: the type of the asset to be displayed) location.append (UICoord().persp("asset").view("asset")); - location.append (UICoord().view("asset").tab("type(Asset)").create()); location.append (UICoord::currentWindow().panel("viewer").create()); location.append (UICoord::window("meta").persp("config").panel("infobox").view("inspect").create()); @@ -431,16 +430,32 @@ namespace test { )); CHECK ("UI:woe[asset]-panel.asset" == string{solver.solve (location, UIC_VIEW, "video")}); //Note: the 4th Rule matches on existing view "asset", // in spite of our query demanding a view "video" - - /* === wildcard match on panel and view appended === */ - ///////////////////////////////////////////////////////////////////////////////////////////////////TODO not yet possible. How to match on type(Asset)??? + /* === wildcard match based on the type of entity to be displaced === */ +#if false ///////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1130 : not yet possible. Match based on placeholder substitutet from context +// uiTree = MakeRec() +// .set("win" +// , MakeRec() +// .type("shady") +// .set ("special" +// , MakeRec() +// .set ("asset", +// MakeRec() +// .set ("specialAsset", MakeRec()) +// ) +// )) +// .set("woe" +// , MakeRec() +// .type("asset") +// .set ("panel" +// , MakeRec() +// .set ("asset", MakeRec()) +// )); +// CHECK ("UI:win[shady]-special.asset.specialAsset" == string{solver.solve (location, UIC_TAB, "specialAsset")}); +// //Note: the next rule would match on the general asset panel +// // but this special rule allows to re-use a tab dedicated to specialAsset +#endif ///////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1130 : not yet possible. Match based on placeholder substitutet from context - /* === successful create clause with wildcard === */ - ///////////////////////////////////////////////////////////////////////////////////////////////////TODO not yet possible. How to match on type(Asset)??? - - /* === unsatisfied create clause with wildcard === */ - ///////////////////////////////////////////////////////////////////////////////////////////////////TODO not yet possible. How to match on type(Asset)??? /* === match on create clause with generic window spec and panel === */ uiTree = MakeRec() diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 19d1282b1..258ede273 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
@@ -2945,7 +2945,7 @@ locate = currentWindow().panel(infobox)
 : currentWindow
 : perspective(id)
 : panel(id)
-: assetType() {{red{WIP 9/17 not clear if possible}}}
+: assetType() {{red{WIP 2/18 not clear if necessary}}}
 : create()
 ;alloc
 : unlimited
@@ -2959,6 +2959,14 @@ The coordinate specs as written within the DSL are slightly abridged, as the fin
 
 However, the semantics of UI coordinate resolution and matching are applied against the coordinate specs //as given in the DSL.// Since, by default, what is given is required to exist, it makes quite a difference as to what kind of element is used as terminal element of a given spec. Since our UI coordinate system establishes a distinct depth for each kind of element, we can and even must reject any spec which does not yield a definite location for at least the parent element; we do not interpolate or even invent arbitrary elements, we only ever match against existing ones. Thus any DSL definition must encompass a sane default, a final alternative clause which always succeeds -- and the DSL is considered broken if it doesn't.
 
+!!!!The problem with {{{assetType()}}}
+There is a very special use case, where we'd might want to express some fine points regarding placement of a new sub-tab within the view requested. This need arises when the system requires to show some sub-element through a dedicated view. Such might be the case for a special kind of asset, or when a virtual clip or media is to be opened from a context //other than editing the timeline.// In such a situation, a preferable action would be to use or re-use an existing tab of a view of similar kind. Only if this fails, we'd want a new view to be created at a generic location (e.g. a window dedicated to asset management), and only as fall-back we'd want a completely new asset section to show up within the current window.
+
+Unfortunately such surpasses the ability of the solution mechanism backing this location DSL, which basically relies on pattern matching without further expression evaluation or unification. To express the aforementioned special treatment, we'd need a placeholder within the rules, indicated above as {{{assetType()}}}, which has to be replaced by the actual typeID used in the concrete location query. Since our system does not support unification, either the matching mechanism has to be manipulated based on the context, or the specific rule must be preprocessed for token replacement.
+It is not clear yet {{red{as of 2/2018}}}, if those additional complexities are justified...
+→ Ticket #1130
+
+
 !!!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.
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index bba9655e3..3ffd294be 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -3796,8 +3796,8 @@ - - + + @@ -8402,7 +8402,7 @@ - + @@ -9784,7 +9784,7 @@ - + @@ -9931,7 +9931,7 @@ - + @@ -9946,24 +9946,94 @@ - + + - - - + + + - + + + + + + + + + + +

+ Man möchte, daß für spezielle Sub-Elemente, +

+

+ die aus einem fremden Kontext heraus geöffnet werden, +

+

+ zunächst versucht wird, einen irgendwo im UI schon bestehenden TAB +

+

+ für speziell diesen Element-Typ wiederzuverwenden; das erlaubt dem User, +

+

+ sich einen Platz für sehr spezielle Sachen beiseite zu setzen. +

+

+ +

+

+ z.B. sehr spezielle Assets oder ein virtueller Clip. +

+

+ +

+

+ Erst wenn so ein Ort nicht gefunden wird, möchte man auf einen +

+

+ generischen Ort zurückfallen, und erst als letzte default-Lösung +

+

+ im aktuellen Fenster einen völlig neuen UI-Elementkontext schaffen. +

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

+ ...statt die gesamte Matching-Engine mit einer Art +

+

+ halbgaren Unifikation aufzubrezln +

+ + + + + + + + - + + @@ -9983,6 +10053,35 @@ + + + + + + + +

+ bleibt dem Charakter nach imperativ +

+ + + + + + + + + + + + + + + + + + + @@ -10057,10 +10156,11 @@ - + + - + @@ -10090,6 +10190,10 @@ + + + + @@ -10534,14 +10638,14 @@ - - + + - - + + @@ -11105,9 +11209,9 @@ - + - + @@ -20329,8 +20433,8 @@ - - + +