This finishes the first round of design drafts in this area.
Right now it seems difficult to get any further, since most of
the actual view creation and management in the UI is not yet coded.
looks like I'm trapped with the choice between a convoluted API design
and an braindead and inefficient implementation. I am leaning towards the latter
looks like we're hitting a design mismatch here....
...and unfortunately I have to abandon this task now and concentrate
on preparation of my talk at LAC.2018 in June
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
The original goal for #1129 (ViewSpecDSL_test) is impossible to accomplish,
at least within our existing test framework. Thus I'll limit myself to coding
a clean-room integration test with purely synthetic DSL definitions and mock widgets
My understanding is that in the standard use case, we precisely know what to expect
and just go ahead and perform the conversion. Thus it is pointless to introduce
fine grained distinctions. When the access fails, this always indicates some broken
application logic, and just raises an error.
With this solution, somewhere deep down within the implementation
the knowledge about the actual result type would be encoded into
the embedded VTable within a lib::variant. At interface level,
ther will be a double dispatch based on that result type
and the desired result type, leading either to a successful
access or an error response.
Problem is, we can not even compile the conversion in the "other branch".
Thus we need to find some way to pick the suitable branch at compile time.
Quite similar to the solution found for binding Rec<GenNode> onto a typed Tuple
...reduce immediate coupling, since we do not really now what actions ElementAccess
will actually perform, and this is likely to remain this way for some time.
So just let it sit there are an on-demand dependency.
Moreover, create an (empty placeholder) implementation within WindowLocator.
So everything is set now for the actual implementation to be filled in
Attempt to find my way back to the point
where the digression regarding dependency-injection started.
As it turns out, this was a valuable digression, since we can rid ourselves
from lots of ad-hoc functionality, which basically does in a shitty way
what DependencyFactory now provides as standard solution
FIRST STEP is to expose the Navigator as generic "LocationQuery" service
through lib::Depend<LocationQuery>
from now on, we'll have dedicated individual translation units (*cpp)
for each distinct interface proxy. All of these will include the
interfaceproxy.hpp, which now holds the boilerplate part of the code
and *must not be included* in anything else than interfac proxy
translation units. The reason is, we now *definie* (with external linkage)
implementations of the facade::Link ctor and dtor for each distinct
type of interface proxy. This allows to decouple the proxy definition code
from the service implementation code (which is crucial for plug-ins
like the GUI)
The recently rewritten lib::Depend front-end for service dependencies,
together with the configuration as lib::DependInject::ServiceInstance
provides all the necessary features and is even threadsafe.
Beyond that, the expectation is that also the instantiation of the
interface proxies can be simplified. The proxies themselves however
need to be hand-written as before
SingletonRef was only invented because lib::Depend (or lib::Singleton at that time)
offered only on-demand initialisation, but could not attach to an external service.
But this is required for calling out at the implementation side of a
Lumiera Interface into the actual service implementation.
The recently created DependInject::ServiceInstance now fulfils this task way better
and is seamlessly integrated into the lib::Depend front-end
we'll use a typedef to represent the default case
and provide the level within the UI-Tree as template parameter for the generic case
This avoids wrapping each definition into a builder function, which will be
the same function for 99% of the cases, and it looks rather compact and natural
for the default case, while still retaining genericity.
Another alternative would have been to inject the Tree-level at the invocation;
but doing so feels more like magic for me.
decided to add a very specific preprocessing here, to make the DSL notation more natural.
My guess is that most people won't spot the presence of this tiny bit of magic,
and it would be way more surprising to have rules like
UICoord::currentWindow().panel("viewer").create()
fail in most cases, simply because there is a wildcard on the perspective
and the panel viewer does not (yet) exist. In such a case, we now turn the
perspective into a "existential quantified" wildcard, which is treated as if
the actually existing element was written explicitly into the pattern.
util::contains used to pick the overload for strings,
i.e. it first converted the UI-Coordinates to diagnostic output format
and then searched that string for '*' to determine if the pattern is explicit
works as expected, but not what you'd intend....
...and breaks spectacularly once you search for something as innocuous as '.'
when used in a pattern for matching against the UI tree,
an element marked as UIC_ELIDED = "." is treated as existentially quantified.
This means, we assume / verify there *is* an element at that level,
but we do not care about what this element actually is. Within the
implementation, the handling is similar to a wildcard, yet such a
spec is not classified as a wildcard (it *is* an explicit element,
just not explicitly named).
The relevant consequence is that such an element matches at a leaf
position, while match on wildcards on leaf positions is prohibited,
to prevent arbitrary and nonsensical wildcard matches against
open ended patterns. Especially we need such an existential pattern
to express a rule to create elements from scratch, but within a
specific window with arbitrary (but existing) perspective.
