UI-Coordinates: implement string representation
This commit is contained in:
parent
3a8f639a12
commit
ac38f0f963
3 changed files with 77 additions and 6 deletions
|
|
@ -54,6 +54,7 @@
|
|||
#include "lib/error.hpp"
|
||||
#include "lib/symbol.hpp"
|
||||
#include "lib/path-array.hpp"
|
||||
#include "lib/util.hpp"
|
||||
|
||||
//#include <boost/noncopyable.hpp>
|
||||
#include <string>
|
||||
|
|
@ -66,6 +67,9 @@ namespace interact {
|
|||
// using std::unique_ptr;
|
||||
using std::string;
|
||||
using lib::Literal;
|
||||
using util::unConst;
|
||||
using util::isnil;
|
||||
using util::min;
|
||||
|
||||
enum {
|
||||
UIC_INLINE_SIZE = 8
|
||||
|
|
@ -198,19 +202,86 @@ namespace interact {
|
|||
|
||||
operator string() const
|
||||
{
|
||||
UNIMPLEMENTED ("string representation of UI coordinates");
|
||||
if (isnil (*this))
|
||||
return "UI:?";
|
||||
|
||||
string component = getComp();
|
||||
string path = getPath();
|
||||
|
||||
if (isnil (component))
|
||||
return "UI:?/" + path;
|
||||
|
||||
if (isnil (path))
|
||||
return "UI:" + component;
|
||||
else
|
||||
return "UI:" + component + "/" + path;
|
||||
}
|
||||
|
||||
string
|
||||
getComp() const
|
||||
{
|
||||
UNIMPLEMENTED ("string representation of UI coordinates: component section");
|
||||
if (empty()) return "";
|
||||
|
||||
size_t end = min (size(), UIC_PART);
|
||||
size_t pos = indexOf(*begin());
|
||||
|
||||
if (pos >= end)
|
||||
return ""; // empty or path information only
|
||||
|
||||
string buff;
|
||||
buff.reserve(80);
|
||||
|
||||
if (0 < pos) // incomplete UI-Coordinates (not anchored)
|
||||
buff += "?";
|
||||
|
||||
for ( ; pos<end; ++pos)
|
||||
switch (pos) {
|
||||
case UIC_WINDOW:
|
||||
buff += getWindow();
|
||||
break;
|
||||
case UIC_PERSP:
|
||||
buff += "["+getWindow()+"]";
|
||||
break;
|
||||
case UIC_PANEL:
|
||||
buff += "-"+getPanel();
|
||||
break;
|
||||
case UIC_VIEW:
|
||||
buff += "."+getView();
|
||||
break;
|
||||
case UIC_TAB:
|
||||
buff += "."+getTab();
|
||||
break;
|
||||
default:
|
||||
NOTREACHED ("component index numbering broken");
|
||||
}
|
||||
return buff;
|
||||
}
|
||||
|
||||
string
|
||||
getPath() const
|
||||
{
|
||||
UNIMPLEMENTED ("string representation of UI coordinates: path extension");
|
||||
size_t siz = size();
|
||||
if (siz <= UIC_PART)
|
||||
return ""; // no path information
|
||||
|
||||
string buff; // heuristic pre-allocation
|
||||
buff.reserve (10 * (siz - UIC_PART));
|
||||
|
||||
iterator elm{this, unConst(this)->getPosition(UIC_PART)};
|
||||
if (isnil (*elm))
|
||||
{ // irregular case : only a path fragment
|
||||
elm = this->begin();
|
||||
buff += "?/";
|
||||
}
|
||||
|
||||
for ( ; elm; ++elm)
|
||||
buff += *elm + "/";
|
||||
|
||||
// chop off last delimiter
|
||||
size_t len = buff.length();
|
||||
ASSERT (len >= 1);
|
||||
buff.resize(len-1);
|
||||
return buff;
|
||||
}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -419,6 +419,7 @@ namespace lib {
|
|||
return ++lastPos; // at start if empty, else one behind the last
|
||||
}
|
||||
|
||||
protected:
|
||||
/**
|
||||
* @internal access content element by index
|
||||
* @return pointer to storage, `null` if out of bounds
|
||||
|
|
|
|||
|
|
@ -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.</pre>
|
||||
</div>
|
||||
<div title="UICoord" creator="Ichthyostega" modifier="Ichthyostega" created="201709222300" modified="201709231547" tags="def draft spec GuiPattern" changecount="5">
|
||||
<div title="UICoord" creator="Ichthyostega" modifier="Ichthyostega" created="201709222300" modified="201710011858" tags="def draft spec GuiPattern" changecount="6">
|
||||
<pre>//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
|
||||
|
|
@ -9634,8 +9634,7 @@ As starting point for the design of such a framework, we'll pick the notion of a
|
|||
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.
|
||||
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
|
||||
|
|
|
|||
Loading…
Reference in a new issue