ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

ViewSpec: singleton factory to organise the actual ViewSpec DSL tokens

Browse source 
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
This commit is contained in:
Fischlurch 2018-05-06 01:45:38 +02:00
parent 852a3521db
commit f1ea503cfa
4 changed files with 30 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
src/gui/id-scheme.hpp
View file

@ -87,14 +87,6 @@ namespace gui {
using ErrorLogView = widget::ErrorLogWidget;
/** Generic Component View descriptors */
template<class V>
struct Descriptor
{
static_assert (not sizeof(V), "unknown generic view type");
};
/**
* Descriptor for the Timeline UI
*/

3
src/gui/interact/view-locator.hpp
View file

@ -119,8 +119,7 @@ namespace interact {
inline V&
ViewLocator::get()
{
using ViewSpec = idi::Descriptor<V>;
ViewSpec viewSpec; /////////////////////////////////////////////////////////TICKET #1129 : can't create instances all the time. Need some kind of Factory
auto& viewSpec = idi::viewSpec<V>();
Symbol viewID{lib::idi::typeSymbol<V>()};
UICoord targetLocation = viewSpec.locate(viewID);

26
src/gui/interact/view-spec-dsl.hpp
View file

@ -261,5 +261,31 @@ namespace idi {
extern AllocSpec<uint> limitAllocation;
/** Generic Component View descriptors */
template<class V>
struct Descriptor
{
static_assert (not sizeof(V), "unknown generic view type");
};
// for the actual specialisations: see id-scheme.hpp
/**
* Access point: Factory for "view specs".
* These are (singleton) instances of idi::Descriptor<V>, and assumed to expose
* - a member `viewSpec.locate`, which solves for the actual view location within UI topology
* - a member `viewSpec.alloc`, which actually claims / allocates an existing or new view instance
* @see gui::ctrl::ViewLocator::get
*/
template<class VIEW>
inline Descriptor<VIEW>&
viewSpec()
{
static Descriptor<VIEW> dslInstance;
return dslInstance;
}
}}// namespace gui::idi
#endif /*GUI_INTERACT_VIEW_SPEC_DSL_H*/

6
src/gui/model/element-access.hpp
View file

@ -29,7 +29,7 @@
** is even outright impossible for Lumiera, since the core is able to run standalone and
** the UI is loaded as plug-in, which places us into the situation to connect a self
** contained core with a self contained UI. This is a binding, which, as a sideline, also
** generates a control structure of its own. An another kind of generic access happens
** generates a control structure of its own. And another kind of generic access happens
** when we _navigate_ the topological UI structure for focus management.
**
** This interface defines an abstract service to translate a generic element designation
@ -131,7 +131,7 @@ namespace model {
* public API functions are templated to the _result type as expected by the invoking clinent_
* and thus we get a matrix of possible cases; when the expected result type is _reachable by
* dynamic downcast_ from the actual base interface type returned by the internal access function,
* we can perform this dynamic_cast. Otherwise the returned result proxy object is marked as empty.
* we can perform this `dynamic_cast`. Otherwise the returned result proxy object is marked as empty.
* @remark technically this solution relies on the lib::Variant::Visitor to provide a NOP default
* implementation. The TypeConverter template is instantiated with the desired target type
* and thus only overwrites _the first case where an conversion is possible._ In all other
@ -146,7 +146,7 @@ namespace model {
template<typename X> // note the "backward" use. We pick that base interface
using canUpcast = std::is_convertible<TAR*, X>; // into which our desired result type can be upcast, because
// we know then the following dynamic_cast (downcast) can succeed
// we know the then following dynamic_cast (downcast) can succeed
using Base = typename RawResult::FirstMatching<canUpcast>::Type;
virtual void