Lumiera  0.pre.03
»edit your freedom«
Todo List
File abstract-tangible-test.cpp

WIP ///////////////////////TICKET #959 : GUI Model / Bus

WIP ///////////////////////TICKET #956 : model diff representation

WIP ///////////////////////TICKET #961 : tests to pass...

Class AbstractMO
seems that we don't need this intermediate class...
File abstractmo.cpp
result of the very first code generation from UML in 2008.
File abstractmo.hpp
result of the very first code generation from UML in 2008.
File access-casted-o.hpp
This is the obsoleted old version: It was excessively permissive, which I've learned to view as a danger, since it encourages a sloppy programming style.
File actions.hpp
the old Gtk::Action and Gtk::ActionGroup are planned to be deprecated. Recommendation is to rely on Gtk::Builder and Gtk::SimpleAction instead. As of 5/2017, it is not clear to what extent this might force us into additional "desktop integration" we do not need nor want (like automatically connecting to D-Bus). For that reason, we'll postpone this transition for the time being /////////////////////TICKET #1068
Member Actions::populateShowPanelActions (Gtk::UIManager &uiManager)
4/2017 this can only be a preliminary solution. What we actually want is perspectives, and we want a specific UI to be anchored somewhere in UI space, so we'll be rather be navigating towards it, instead of "showing it here".
Member Actions::updateActionState (workspace::WorkspaceWindow &currentWindow)
as of 2017, the relation of panels to top level windows is unclear and likely needs to be replaced by a focus + perspective concept (–> see topic "Interaction Control")
File advice.cpp

This approach is closely related to the decision to use a single global index table for managing all advice collaborations. An alternative would be to use either a separate table for each type, or to store an additional type descriptor with this memory management information into each "bucket", which can be assumed to manage entries dealing with the same kind of advice data, because each binding automatically includes a type guard. If we ever happen to get a significant amount of advice data, but only a small number of different advice types, we should reconsider this optimisation.

rewrite the allocation to use Lumiera's MPool instead of heap allocations //////TICKET #609

File advice.hpp

allow variables in binding patterns

use the lumiera MPool instead of heap allocations

consider to provide variations of the basic behaviour by policy classes

the implementation is generic/defensive, and could be improved and optimised

Class AdviceBindingPattern_test
partially unimplemented and thus commented out ////////////////////TICKET #605
Member AdviceBindingPattern_test::verifyDynamicMatch ()
this is a future extension and its not clear if we need it and what the exact semantics could be ///////////////////////////////TICKET #615
Class AdviceConfiguration_test
partially unimplemented and thus commented out ////////////////////TICKET #605
Class AdviceMultiplicity_test
advanced topic, deferred for now (4/10) ////////////////////TICKET #610
Class AdviceSituations_test
yet more use cases to come.... ////////////////////////////////////////////////////////TICKET #335
Member AdviceSystem::allocateBuffer (size_t siz)
rewrite to use Lumiera's block allocator / memory pool /////////////////////////////////TICKET #609
File allocation.cpp
result of the very first code generation from UML in 2008.
File allocation.hpp
result of the very first code generation from UML in 2008.
Member Allocation::intersect (LocatingSolution &) const
probably a placeholder and to be pushed down....
Class AllocationCluster

implement a facility to control the oder in which the object families are to be discarded. Currently they are just purged in reverse order defined by the first request for allocating a certain type.

should we use an per-instance lock? We can't avoid the class-wide lock, unless also the type-ID registration is done on a per-instance base. AllocationCluster is intended to be used within the builder, which executes in a dedicated thread. Thus I doubt lock contention could be a problem and we can avoid using a mutex per instance. Re-evaluate this!

currently all AllocationCluster instances share the same type-IDs. When used within different usage contexts this leads to some slots remaining empty, because not every situation uses any type encountered. wouldn't it be desirable to have multiple distinct contexts, each with its own set of Type-IDs and maybe also separate locking? Is this issue worth the hassle? //////////////////////////////TICKET #169

Class AllocationCluster::MemoryManager
this is a preliminary or pseudo-implementation based on a vector of raw pointers, i.e. actually the objects are heap allocated. What actually should happen is for the MemoryManager to allocate raw memory chunk wise, sub partition it and place the objects into this private memory buffer. Further, possibly we could maintain a pool of raw memory chunks used by all MemoryManager instances. I am skipping those details for now (10/2008) because they should be based on real-world measurements, not guessing.
File allocator-handle.hpp
6/2023 this specification describes a Concept, not an actual interface type. After the migration to C++20, it will thus be possible to mark some arbitrary custom allocator / front-end with such a concept, thereby documenting proper API usage.
Class AllocatorHandle< TY >
shall be replaced by an AllocationCluster eventually
File alsa.h
for now this header defines some functions used for experimentation with ALSA
Member anonymous_namespace{time.cpp}::calculate_drop_frame_number (gavl_time_t time)
I doubt this works correct for negative times!!
File argument-tuple-accept.hpp
switch to variadic templates. Requires a rework of Types<...> /////////////////////////////////////TICKET #967
File assembler.cpp
initially generated code of unclear relevance
File assembler.hpp
initially generated code of unclear relevance
File asset-controller.cpp
WIP 2/2017 early draft / foundations of "interaction control"
File asset-controller.hpp
WIP 2/2017 early draft / a new UI backbone
File asset/effect.cpp
still unimplemented and stalled work as of 2016
Class AssetController
initial draft as of 2/2017 – actual implementation has to be filled in
File assetmanager.hpp

10/10 meanwhile I'm unhappy with some aspects of this implementation //////////////TICKET #691

12/12 and meanwhile I'm way more unhappy with the whole design. Looks like I wasn't proficient enough with OO design in C++ when writing that original design. Especially, this design couples the object creation, the memory management and the registration way too tightly. Having a registration magic in the asset baseclass ctor is just too clever and a half. Rather, there should be a responsibility chain, using completely passive Asset objects: Factory -> AssetManaager -> Asset object

Member AssetManager::clear ()
verify this actually works, especially with session shutdown ////////////////////////////TICKET #154
File auto.cpp
result of the very first code generation from UML in 2008.
File auto.hpp
result of the very first code generation from UML in 2008.
Class AutoExpander< SRC >
as of 12/2017, this is more like a proof-of concept and can be seen as indication, that there might be several flavours of child expansion. Unfortunately, most of these conceivable extensions would require a flexibilisation of Expander's internals and thus increase the complexity of the code. Thus, if we ever encounter the need of anything beyond the basic expansion pattern, we should rework the design of Expander and introduce building blocks to define the evaluation strategy.
File bin-widget.cpp
WIP-WIP-WIP as of 12/2016
File bin-widget.hpp
WIP-WIP-WIP as of 12/2016 we have only very vague preliminary plans regarding the asset management section; also the asset management within the session subsystem will be rewritten to fit our increased understanding of the editing process. So for now, this widget is a mere placeholder in a largely preliminary UI (need more weasel words?)
Class BinWidget
WIP-WIP as of 12/2016
File body-canvas-widget.cpp
as of 3/2023 the foundation of this rewritten, highly flexible drawing code established, and the layout seemingly behaves reasonably stable and visually as expected, yet with some minor glitches. Any kind of dynamic adjustment in response to expanding/collapsing or the content representation of clips is not yet implemented
Member BodyCanvasWidget::establishLayout (DisplayEvaluation &) override
2/2020 WIP
Class BufferProvider

as of 6/2011 buffer management within the engine is still a bit vague

as of 11/11 thread safety within the engine remains to be clarified ///////////////////////////TICKET #854

Class BuffTable

this whole design is a first attempt and rather clumsy. It should be reworked to use a single contiguous memory area and just layer the object structure on top (by using placement new). Yet the idea of an stack-like organisation should be retained

this whole design is a first attempt and rather clumsy. It should be reworked to use a single contiguous memory area and just layer the object structure on top (by using placement new). Yet the idea of an stack-like organisation should be retained

Member Builder< ErrorLog >::Builder (string name)
what is "the default log"??
Member Builder< ErrorLog >::commit ()
currently (8/2018) this is a mere placeholder, we just need an EntryID<ErrorLog>. ///////////////TICKET #1157
Member Builder< TimeGrid >::commit ()
currently (12/2010) the AssetManager is unable to detect duplicate assets. Later on the intention is that in such cases, instead of creating a new grid we'll silently return the already registered existing and equivalent grid.
Member Builder< TimeGrid >::predecessor
currently not supported (as of 12/2010)
File builderfacade.hpp
as of 2016 the builder, as the most crucial component within the architecture, still remains to be addressed. While we'd hoped to get ahead faster, it is considered a good idea not to decide upon the implementation based on assumptions. We will start building the builder "when it is ready"
Class BuildID< PLA >
this is a rather half-baked solution //////////TICKET #523
File bus-mo.cpp

stalled effort towards a session implementation from 2010

2016 likely to stay, but expect some extensive rework

File bus-mo.hpp

stalled effort towards a session implementation from 2010

2016 likely to stay, but expect some extensive rework

Class CairoUtil
this is not a real entity; consider to turn this into a set of free functions!
File calc-stream.hpp

this draft was created in 2013 just to the point of defining the skeleton of the engine.

as of 2016, this is considered the way to go and will be completed eventually

Class CalcStream_test
WIP-WIP-WIP
File call-queue.hpp
simplistic braindead implementation with locking and heap based storage based on std::function; should use a lock-fee queue and should have an eye on the impact of managing argument storage
Class Category
could be far more elaborate. could be a singleton like centralised tree, while just holding references to Category nodes in the individual Asset. At the moment, we just use the most simplistic implementation and handle Category objects using value semantics.
Member Category::operator string () const
to be localized.
File channel-descriptor.hpp
as it stands (11/2011) this file is obsoleted and needs to be refactored, alongside with adapting the node invocation to the new BufferProvider interface.
Class ChildExpandableSource< VAL >
expandChildren() should not return the value pointer. This is just a workaround to cope with the design mismatch in IterSource; the fact that latter just passes around a pointer into the implementation is ugly, dangerous and plain silly. ////////////////////////////////////////////////////////////TICKET #1125 Incidentally, this is also the sole reason why this interface is templated with VAL
Class Clip
define how to denote Time positions /lengths. This is tricky, because it depends on the actual media type, and we want to encapsulate all these details as much as possible.
File clip-presenter.hpp

WIP-WIP-WIP as of 12/2016

as of 10/2018 timeline display in the UI is rebuilt to match the architecture

File clip-widget.cpp
WIP-WIP-WIP as of 1/2021
File clip-widget.hpp
WIP-WIP as of 1/2021
Member Clip::mediaDef_
using a mere ref here is against the scheme and only done as temporal solution, until we work out how to handle multichannel clips.
Class ClipDelegate
WIP-WIP as of 2/2021
Class ClipPresenter
WIP-WIP as of 12/2016
Member ClipPresenter::ClipPresenter (ID identity, ctrl::BusTerm &nexus, WidgetHook &view, optional< TimeSpan > const &timing)
2022 should provide a way to specify a media type immediately at construction //////////////TICKET #1251 : how to specify media type for the Clip
File cmd-context-test.cpp
created 3/2017 as a marker for planned concepts, postponed for now...
File cmd-context.cpp
as of 3/2021 the first prototype for a dragging gesture is shaped The scheme for addressing gestures and scopes is nothing but guesswork currently, since we mostly lack any real-world implementation and haven't done any detailed analysis regarding the actual gestures to be implemented. Only the concept is clear.
File cmd-context.hpp

as of 3/2017 this is a early design draft and WIP-WIP-WIP

after initial design draft, postponed as of 10/2017

File cmd.hpp
WIP 3/2017 early draft
Class CmdContext
write type comment...
Class CmdContext::Resolver
4/2021 this was part of a design draft in 2017, not clear yet if we need it
Member CmdContext::Resolver::operator LuidH ()
4/21 this was an idea from the initial draft in 2017 – undecided yet
File command-impl-clone-builder.hpp
Ticket #301 : it may well be that the need for such a facility is a symptom of misaligned design, but I rather doubt so – because both the memento holder and the command closure need a specifically typed context, and there is no reason for combining them into a single facility.
File command-queue.hpp
as of 12/2016 this is fully functional, but we may want to add some further management functions like purging of expired commands
Member CommandArgument_test::serialiseArgTuples (ArgTuples &tup)
unimplemented, waiting on Serialiser
Class CommandBinding_test
add more test cases...
Class CommandUse2_test
this test is still on hold, as the non-trivial patterns aren't implemented as of 10/09 ////////////////TICKET #211
Class CommandUse3_test

planned but not implemented as of 7/09

as of 12/2016 I doubt we'll get asynchronous invocation but command sequence bundles still seem a reasonable future idea

File common/advice/binding.hpp
for now, only the case of a completely constant (ground) pattern is implemented. Later we may consider to extend the binding patterns to allow variables, which, on match could be fed as parameters to the bound advice. But this extension requires to extend the simple hash-based match check to an actual unification of the patterns. ///TICKET #615
File config-facade.h
there ought to be an external Interface for the Config subsystem. But the full-blown Config system isn't implemented yet anyway
File config-interface.c
as of 2016 this code is unused and likely to be replaced by a different approach.
File config-interface.h
as of 2016, the code is still there in same unfinished shape and basically unused
File config-lookup.c
as of 2016 this code is unused and likely to be replaced by a different approach.
File config-lookup.h
as of 2016, the code is still there but remains mostly unused
File config-resolver.cpp
draft from the early design phase of the Lumiera application. As of 2016, nothing was done on behalf of rules-based configuration, other then preparing the whole architecture for this capability. So this remains one of the most relevant goals of the Project.
File config-resolver.hpp
clarify the relation of config query and query-for-defaults ///////////////TICKET #705
File config-rules.cpp
placeholder and mostly not implemented as of 11/2016
File config-rules.hpp

right now (12/2012) the above paragraph is a lie. ConfigQuery is way older than QueryResolver and will be retrofitted step by step. Not much of a problem, since the currently utilised mock implementation isn't able to deal with a real query anyway.

as of 11/2016 the situation is basically the same: this is placeholder code and just implemented enough to keep us going without violating the architecture vision

clarify the relation of config query and query-for-defaults ///////////////TICKET #705

File config-typed.c
as of 2016 this code is unused and likely to be replaced by a different approach.
File config-wordlist.c
as of 2016 this code is unused and likely to be replaced by a different approach.
File config.c
as of 2016 this code is not used and never was
File config.h
as of 2016, this code is not in any meaningful use
File configentry.c
as of 2016 this code is unused and likely to be replaced by a different approach.
File configentry.h
as of 2016 this code is unused and likely to be replaced by a different approach.
File configfacade.cpp
as of 2016, this seems not to be used much, if at all. The GTK-UI, which in itself is very preliminary, retrieves some values from configuration, most notably the name of the GTK stylesheet (lumiera.css is the default)
File configitem.c
as of 2016 this code is unused and likely to be replaced by a different approach.
File configitem.h
as of 2016 this code is unused and likely to be replaced by a different approach.
Class ConfigSelector< Factory, FUNC, PAR >
as the factories live only within the enclosed table (map) we could allocate them in-place. Unfortunately this is non-trivial, because the STL containers employ value semantics and thus do a copy even on insert. Thus, for now we use a shared_ptr to hold the factory heap allocated. —> see Ticket #248
File conmanager.cpp
initially generated code of unclear relevance
File conmanager.hpp
initially generated code of unclear relevance
Member ConManager::getConnection ()

just a design sketch from 2008, work out signatures etc...

TODO IT!!!!!!!!!!!!!!!!!!

File constraint.cpp
result of the very first code generation from UML in 2008.
File constraint.hpp
result of the very first code generation from UML in 2008.
File control-policy.hpp
6/2011 include all the special cases for QuTimeSpan ////////////////////TICKET #760
File control.hpp
include support for QuTimeSpan values ////////////////////TICKET #760
Class Controller
write type comment...
Class Controller
needs to be reshaped for communication with Steam-Layer ////////////////TICKET #959
File controller.hpp

as of 1/2015 this is complete WIP-WIP-WIP

as of 8/2018 we should consider to distill a common default implementation usable for most controllers. especially, there might be a default (NOP) implementation of the diff mutator builder

Member Controller::doMark (GenNode const &mark) override
is there any default implementation for special messages, which might be eligible as a base class implementation??
File controllerfacade.hpp
as of 2016 it very much looks like there wont'be any such thing...
Class DataSpan< D >
replace by const std::span
Class DefsRegistry
as of 3/2008 the real query implementation is missing, and the exact behaviour has to be defined.
Class DeleteClip_test
////////////////////////////////////////////////TICKET #499
File diagnostic-buffer-provider.cpp
WIP from 2013, half finished, stalled
Class DiagnosticBufferProvider
write type comment
Member DiagnosticContext< VAL >::extractStack ()
benchmark and improve the data structure used for the snapshot. Vector is not an optimal choice here.
Member die_no_mem (enum lumiera_resource which, enum lumiera_resource_try *iteration, void *context)
10/2023 in the early stages of the Lumiera project a centralised resource pooling was considered. On resource shortage, the (planned) resource-collector would attempt to reclaim excess resources. This would allow to use resources (e.g. memory) wastefully as trade-off for performance gains. This concept was never developed beyond an interface draft; most notably it was never clarified how excess resources could have been identified on-demand while in-flight. Today I view this concept as an immature plan and remove the remaining draft code.
Class DigxelConfigurations_test
cover any newly added Digxel configurations.
File dispatch-table.cpp

draft from 2011, stalled, relevance not yet clear

6/2023 still unimplemented, as is the Fixture, which needs to back the Dispatcher

File dispatch-table.hpp
6/2023 »PlaybackVerticalSlice« : completing and integrating the core engine step by step
Class Dispatcher
6/23 API is remoulded from ground up (»Playback Vertical Slice« integration effort)
File dispatcher.cpp
2023 do we actually need a separate translation unit for this?
File dispatcher.hpp
as of 4/2023 a complete rework of the Dispatcher is underway //////////////////////////////////////TICKET #1275
Member Dispatcher::PipelineBuilder< SRC >::feedTo (play::DataSink &sink)
6/2023 more akin to a place holder, since it is not clear what must be done with the sink handle(s). Moreover, a Transformer returning a reference to the JobPlanning (deeper down in the pipeline) causes yet another unnecessary indirection; if the Transformer wasn't there, the resulting iterator would directly expose the result of the expander, which is the actual JobPlanning (but then we'd need another way how to wire in the DataSink...)
Class DispatchTable
6/2023 gradually building up the core engine components...
File display-evaluation.cpp
WIP-WIP-WIP as of 3/2020
File display-evaluation.hpp
WIP-WIP-WIP as of 3/2020
File display-manager.cpp

as of 10/2018 timeline display in the UI is rebuilt to match the architecture

3/2020 do we actually need this global translation unit?

File display-manager.hpp

as of 10/2018 timeline display in the UI is rebuilt to match the architecture

WIP-WIP-WIP - drafting the DisplayEvaluation as of 3/2020

WIP as of 1/2021 about to build a first preliminary Clip representation

Class DisplayEvaluation
WIP-WIP as of 3/2020
Class DisplayManager
WIP-WIP as of 12/2019
File dock-area.cpp
will be transformed into a Dock entity as of 6/2018 /////////////////////////////////////////////TICKET #1144 refactor dock handling
File dock-area.hpp

2017 need to clarify the intended behaviour of panels ///////////////////////////////////////////////////////////////////////////TICKET #1097 clarify the role and behaviour of Panels

will be transformed into a Dock entity as of 6/2018 /////////////////////////////////////////////TICKET #1144 refactor dock handling

as of 8/2018 this is a copy of the (still actively used) PanelManager; the intention was to do a clean rewrite and then throw away the old messy PanelManager implementation. Meanwhile I was forced to add yet more cruft to PanelManager, just to keep it going. Beware!

Class DockArea
this code is smelly and needs some clean-up ///////////////////////////////TICKET #1026
File dot-gen.hpp
11/2023 this is an initial draft, shaped by the immediate need to visualise random generated computation patterns for Scheduler load testing. The abstraction level of this DSL is low and structures closely match some clauses of the DOT language; this approach may not yet be adequate to generate more complex graph structures and was extracted as a starting point for further refinements.
File drag-relocate-controller.hpp
WIP and prototypical implementation as of 3/2021
Class DragRelocateController

write type comment...

WIP-WIP as of /3/2021 ///////////////////////////////////TODO do we need a translation unit interaction-state.cpp (otherwise delete it!)

File dummy-builder-context.hpp

5/2023 add more elements as needed for test driven integration of Player and engine

this was invented in 2012 – but development of the player subsystem stalled thereafter.

File dummy-image-generator.cpp
obsolete since 2010, can be removed once we have a real player in the UI
File dummy-image-generator.hpp
obsolete since 2010, can be removed once we have a real player in the UI
File dummy-play-connection.hpp
this was invented in 2012 – but development of the player subsystem stalled thereafter. As of 2016, I still consider this design valid and intend to pick up development when able to address this topic again. At the moment, the UI-Session connection is more urgent.
File dummy-session-connection.cpp
WIP as of 10/2018 ///////////////////////TICKET #1042
File dummy-session-connection.hpp
WIP as of 10/2018 //////////////////////////////////////////////////////////////////////TICKET #1042
Class DummyPlayConnection< DEF >

not-yet-implemented as of 2016 – but the design can be considered valid.

6/23 still largely unimplemented, but used as generator for mock ModelPort

Class DummySessionConnection
as of 2018, the most pressing problem is to establish the interplay between Stage-Layer and Steam-Layer, so the software gains some tangible functionality...
Member DummySessionConnection::applyCopy (MutationMessage const &)
build an internal "shadow data structure" and apply all diffs there as well...
File elem-access-dir.hpp
WIP-WIP-WIP need to learn more about the concrete UI implementation ///////////////////////TICKET #1134
Class ElemAccessDir
mostly not yet implemented as of 4/2018 – need to learn more about aforementioned internals.
File element-access.hpp
WIP ///////////////////////TICKET #1134
File element-box-widget.cpp

as of 9/2022 we just hide the label text completely to comply with the constraints; it is conceivable to use a more elaborate approach and to shorten the label text to fit.

WIP-WIP as of 09/2022 ///////////////////////////////////////////////////////////////////////TICKET #1185

File element-box-widget.hpp

WIP-WIP-WIP as of 11/2018 ///////////////////////////////////////////////////////////////////////TICKET #1185

WIP-WIP-WIP as of 9/2022 ///////////////////////////////////////////////////////////////////////TICKET #1219

File element-query.hpp

WIP implementation of session core from 2010

as of 2016, this effort is considered stalled but basically valid

Class ElementAccess_test
4/2018 in the course of establishing an UI backbone, it is sufficient just to have that abstraction interface; so the test focuses merely on the invocation, and documents how the mock be used. Which is a prerequisite to get the ViewSpecDSL_test finished. The intention is to elaborate the mock in a second step later and use it to build a draft of the implementation mechanics, but based on Rec<GenNode> rather than on the real UI topology.
Class ElementBoxWidget
consider policy based design, //////////////////////////////////////////////////////////////////TICKET #1239 : re-evaluate Design, maybe use Policy Based Design but need more exposure and real world usage as of 9/22
File engine-config.cpp
6/2023 not clear if this is placeholder code or something substantial; however, it seems not plausible; rather I'd expect some data collection and information service to be connected with the RenderEnvironmentClosure
File engine-config.hpp
6/2023 not clear if this is placeholder code or something substantial; however, it seems not plausible; rather I'd expect some data collection and information service to be connected with the RenderEnvironmentClosure
File engine-observer.hpp

WIP-WIP-WIP 10/2023 »Playback Vertical Slice« created as a stub

design and implement the EngineObserver as publisher-subscriber... ////////////////////////////////TICKET #1347 : design EngineObserver

File engine-service-mock.cpp
draft from 2012, and, while stalled, still relevant as of 2016
File engine-service-mock.hpp
1/2012 until the real render engine is usable, this mock implementation will stand-in, allowing us to develop the other parts of the play/render subsystem.
File engine-service.hpp
draft from 2013, stalled, but still relevant and to be continued eventually
Class EngineConfig

WIP-WIP as of 1/2013

anything regarding configuration and session storage

find out about the degree of locking required. Right now (1/13), there is no locking and all values are hard coded. It is conceivable to implement the access in a lock-free manner (by loosening any guarantee regarding the actual time point when a changed setting becomes visible)

Member EngineConfig::currentEngineLatency () const
hard wired value as of 1/2013
File enginefacade.cpp
placeholder/draft as of 1/2017
Class EngineObserver
WIP-WIP 10/2023 - stub as placeholder for later development ////////////////////////////////////TICKET #1347 : design EngineObserver
File entry-id.hpp
as of 11/2018 the basic design seems adequate, but the actual solution looks fishy. Even more so, since we now use subclasses of BareEntryID
  • as identity tag within lib::diff::GenNode
  • as identity tag for all tangible UI elements There are various quirks and hacks to make all of this happen, and especially the hashed-in type information feels gratuitous at places, when all we actually need is a distinct identity plus a human readable symbol.
Class EntryID< TY >

currently storing the symbolic-ID as string. It should be a lib::Symbol, but this isn't possible unless we use a symbol table. //////TICKET #158

As a temporary workaround, we hash the symbolic ID twice, but we should look into using a better hash function ////////////TICKET #865

File error-log-display.hpp

WIP-WIP-WIP as of 9/2017 this is a first draft of a widget to be used as receiver by the GuiNotificationService.

WIP-WIP and in 9/2018 this draft gradually shifts towards a prototype how to deal with custom configured widget behaviour, and how to integrate with our GUI framework (#1099)

File error-log.hpp
8/2018 created as mere placeholder; for now we just need an EntryID<ErrorLog> in order to mark the corresponding receiver widget in the UI. The idea is eventually to persist relevant messages, filtering them out as time passes. Such an incident log would be part of the session model, thus replicating its contents into the corresponding stage::widget::ErrorLogView – which displays notifications without blocking the UI.
Class ErrorLog
8/2018 mere placeholder type for now, to allow defining an EntyID<ErrorLog>. We conceptually need "the" ErrorLog entity as correspondence to the ErrorLogView in the GUI.
Class ExecResult
couldn't that be replaced by a lib::Result<void> instance??
File exit-node.hpp
6/2023 WIP-WIP used as placeholder; relation to ProcNode not yet determined /////////////TICKET #1306
Class ExitNode
6/2023 for the »Playback Vertical Slice« we need somehow to represent "the nodes", while the final solution how to hook up ProcNode and how to represent prerequisites remains still to be settled. So this is a placeholder to support mock testing for now.
Class Facade

this is a dummy placeholder as of 1/2009. Currently, there is only implementation-level code within the Steam-Layer and the interfaces need to be worked out.

at least the Play/Output subsystem slowly turns into something real, as of 6/2011

and as of 1/2017, the Session subsystem is basically implemented and it became clear that there won't be a "Builder subsystem". So this interface might now be considered roughly complete...

File fake-configrules.hpp
to be removed in Alpha, when integrating a real resolution engine /////////////////TICKET #710
File file.cpp
3/24 consider to establish some central location to define basic literals.
File file.hpp
3/2024 should be part of generic utilities
Class FixedLocation
use a subclass to represent the LocatingSolution? would solve the construction of a ExplicitPlacement much more natural. //////////TICKET #100
File fixedlocation.cpp

stalled effort towards a session implementation from 2008

2016 likely to stay, but expect some extensive rework

File fixedlocation.hpp

stalled effort towards a session implementation from 2008

2016 likely to stay, but expect some extensive rework

Class Fixture
1/2012 Just a Placeholder.
File fixture-change-detector.hpp
WIP-WIP-WIP as of 12/2010
File fixture.cpp

WIP implementation of session core from 2010

as of 2016, this effort is considered stalled but basically valid

File fixture.hpp

WIP implementation of session core from 2010

as of 2016, this effort is considered stalled but basically valid

Member Fixture::getAutomation ()
: just a placeholder at the moment!!!
Member Fixture::isValid () const
self-verification of the fixture? necessary?
Class FixtureChangeDetector_test
just a placeholder, nothing done here thus far (2016)
File focus-tracker.cpp
WIP 2/2017 early draft / foundations of "interaction control"
File focus-tracker.hpp
WIP 2/2017 early draft / foundations of "interaction control"
Class FocusTracker
initial draft as of 2/2017 – actual implementation has to be filled in
File fork.cpp

WIP implementation of session core from 2010

as of 2016, this effort is considered stalled but basically valid

File fork.hpp

WIP implementation of session core from 2010

as of 2016, this effort is considered stalled but basically valid

File format-obj.hpp
is it possible to stash away the boost::lexical_cast behind a custom facade, the way we did it for boost::format? This would reduce inclusion cost...
Class FrameID
currently (7/08) this is a dummy implementation to find out what interface the Steam layer needs. Probably the vault layer will later on define what is actually needed; this header should then be replaced by a combined C/C++ header
File frameid.hpp
2016 the intention was to use this as cache key, and to include some information regarding the processing chain which led up to the calculation of this frame, to allow for intelligent caching and to avoid throwing away most of the frames on each and every tweak of the edit. This marker was added as a preview in 2010 but we didn't get to the point of actually putting that idea into practical use. Yet the basic idea remains desirable...
File function-closure.hpp

the implementation is able to handle partial application with N arguments, but currently we need just one argument, thus only this case was wrapped up into a convenient functions func::applyFirst and func::applyLast

11/23 these functor-utils were written at a time when support for handling generic functions in C++ was woefully inadequate; at that time, we neither had Lambda-support in the language, nor the ability to use variadic arguments. Providing a one-shot function-style interface for this kind of manipulations is still considered beneficial, and thus we should gradually modernise the tools we want to retain...

File function.hpp
get rid of the repetitive specialisations and use variadic templates to represent the arguments /////////////////////////////////TICKET #994
Class GdkDisplayer
the GdkDisplayer class is not supported anymore in Gtk3. This is due to Gtk3 only supporting drawing with Cairo /////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #950 : new solution for video display
File gen-node-location-query.hpp
WIP 10/2017 started in the effort of shaping the LoactionQuery interface, and used to support writing unit tests, to verify the UiCoordResolver. It remains to be seen if this implementation can be used beyond this limited purpose
File generator-mo.cpp

WIP implementation of player subsystem from 2011

as of 2016, this effort is considered stalled but basically valid

File generator-mo.hpp

WIP implementation of player subsystem from 2011

as of 2016, this effort is considered stalled but basically valid

Member GeneratorMO::GeneratorMO ()
using a mere ref here is against the scheme and only done as temporal solution, until we work out how to handle multichannel clips.
File genfunc.hpp

better unit test coverage

improve implementation of typeFullID

File gesture-state.cpp
do we really need a segregated translation unit for the InteractionState implementations? The alternative would be to emit all the related code from interaction-director.cpp; and in this alternative solution, we'd also allocate all the interaction state right within GestureState, without PImpl. The benefit would to avoid yet another indirection, while the downside would be to include all those implementations unnecessarily also into cmd-context.cpp, with the danger that someone later on starts to "short circuit" directly into some implementation, by switching on type.
File gesture-state.hpp
WIP-WIP as of 3/2021 about to create a prototype implementation for dragging clips...
Class GestureState

write type comment...

WIP-WIP as of 3/2021

as of 3/2021 the whole scheme for addressing gestures and actual state implementations is rather just guesswork ///////////////////////////////////TODO do we need a translation unit interaction-state.cpp (otherwise delete it!)

Member GestureState::getStateFor (Action action, Scope qualifier)
as of 4/2021, interactions and UI state handling can be considered an early draft; since the UI needs to be fleshed out in more detail in order to decide on a proper organisation and possibly flexible configuration.
File gnuplot-gen.cpp
WIP 4/2024 first usage as part of Scheduler stress testing.
File gnuplot-gen.hpp
3/2024 this is an initial draft, shaped by the immediate need to visualise measurement data collected while testing the new Scheduler implementation.
Class Grid

WIP-WIP-WIP

maybe abstract this from Time altogether?

File handling-pattern.hpp

it is not clear what's the difference between "throw" and "no-throw" pattern

any integration with the (yet undefined as of 9/09) SteamDispatcher is missing.

Class HandlingPatternStandardImpl_test
define and code those handling patterns; Ticket #210
File hash-standard.hpp
4/2014 doesn't work as expected. My suspicion is that in the actual use case (PlacementIndex), the type providing the hasher is mixed in through inheritance, and the template specialisation for this base type is not considered on lookup. ///////TICKET #722
File header-pane-widget.hpp
WIP-WIP-WIP as of 12/2016
Class HeaderPaneWidget
WIP-WIP as of 12/2016
Class HelloBug_test
come up with some more bugs
Member Holder< TYPES >::access (Buffer &buf)
shouldn't this rather be located within the Holder::Storage created by clients??
File id-scheme.hpp
as of 2017 .. 2021, this is a half-finished draft and postponed in favour of building the actually visible timeline display first
Class ID< KIND >
it would be desirable to use EntryID instead ///////////////////////////////////////////TICKET #739 : make identification schemes compatible
Member IdentityOfAssets_test::createDuplicate ()
this test is expected to break when the detection of duplicate registrations is implemented.
Member IDLabel::adaptSize (int, int)
as of 10/22, a planned full implementation will eventually shorten the caption text and possibly also combine both Icons into a single button when necessary... ///////////////////TICKET #1242 : adjust size of the ID caption
Class ImplFacadeGAVL
2016 evaluate if libGAVL is still active and maintained
File infobox-panel.hpp
as of 10/2017 this is used as space to host the information and error log
Member InfoBoxPanel::InfoBoxPanel (workspace::PanelManager &, Gdl::DockItem &)
just used as place for the error log as of 10/2017. More to come...
Class InPlaceAnyHolder< siz, AccessPolicy >
add support for moving of rvalue refs
Class Instant
7/2023 this decision should be revised //////////////////////////////////////////////////////////TICKET #1261 : reconsider (im)mutability of time entities
Class Instantiation< _CandidateTemplate_ >

1/2016 is there no better way to achieve this, based on new language features /////////////TICKET #986 Basically we want a SFINAE helper not only to check if a specific instantiation can be formed (which would be trivial), but rather, if a specific instantiation has already been defined. An automated solution for this problem seems questionable by theoretic reasons; such would endanger the "One Definition Rule", since the state of definedness of any type may change during the course of a translation unit from "unknown" to "declared", "partially defined" to "fully defined". To hinge the existence of another type on this transitory state would introduce a dangerous statefulness into the meta-language, which is assumed to be stateless.

what could be done though is to detect if a given template can be default constructed, which, by logical weakening, implies it has be defined at all. Would that satisfy our purpose here?

1/2016 also I'm not happy with the name "Instantiation". It should be something like is_XYZ

File interaction-state.cpp
do we really need a separate implementation unit for this??
File interaction-state.hpp

as of 11/2015 this is complete WIP-WIP-WIP

and as of 3/2021 this is at least just WIP-WIP

Future Plan: in the general case, detecting and handling of complex UI interactions and gestures translates itself into a state machine, maybe even a hierarchical compound of state machines, where the subordinate state machines will detect and handle elementary gestures. The role of InteractionState will then be to provide the building blocks and interfaces for assembling such complex state tracking engines.

Member InteractionDirector::editSetup ()
4/2017 not yet implemented, delegate to the AssetControler, which represents all global aspects of the application, session and project
Member InteractionDirector::newSequence ()
4/2017 using the session-root (=this) as anchor for the moment, but should actually figure out the current context dynamically... //////////////////////////////TICKET #1082 : actually access the interaction state to get "current scope"
Member InteractionDirector::newTrack ()

as of 3/2017 this is an initial draft: It is not clear yet, if this lookup of context will always be treated implicitly, or if it is better to have a public content discovery operation on InteractionDirector and pass the current element explicitly as argument

4/2017 using the session-root (=this) as anchor for the moment, but should actually figure out the current context dynamically... //////////////////////////////TICKET #1082 : actually access the interaction state to get "current scope"

Member InteractionDirector::render ()
4/2017 not yet implemented, and it is not clear how to access the functionality. Do we send a command? Or do we access the Play-Out subsystem directly, to create some kind of dedicated player instance?
Class InteractionState

write type comment...

WIP-WIP as of /3/2021 ///////////////////////////////////TODO do we need a translation unit interaction-state.cpp (otherwise delete it!)

File interfaceproxy.hpp
2018 as it stands (since 2008), the Interface/Plug-in system fulfils the basic task it was created for, but is rather cumbersome to use in practice. We should investigate to use SWIG or something similar to generate the bindings and the low-level interfaces.
Class Inventory
WIP-WIP unimplemented
File inventory.hpp
implementation draft from 2010, stalled as of 2016, but likely to be of relevance eventually...
Class InvocationInstanceID
4/2023 for the time being, this is a mere marker for test code; for the real engine it is planned to generate a unique reproducible hash key for each invocation, which can be used for caching; obviously this hash need to be built from the JobTicket, based on ProcNode structure and the nominal Time. ///////////////////////////////////TICKET #1293
Class InvokeAsync

clarify what "async" means and if we need it....

unimplemented... //////////////////////////////////////////////////////////TICKET #210

describe this pattern in more detail....

Class InvokeSyncNoThrow

describe this pattern in more detail....

unimplemented... //////////////////////////////////////////////////////////TICKET #210

Class InvokeSyncThrow

is throwing here helpful, and how to integrate it into ExecResult...?

describe this pattern in more detail....

unimplemented... //////////////////////////////////////////////////////////TICKET #210

File iter-source.hpp
the design used for the "iteration control API" is misaligned with the purpose of this adapter. Rather, it should be shaped similar to IterStateWrapper with three control functions //////////////////////////////////////TICKET #1125
Class IterAdapterSTL_test
this test just pulls all the values from the iterator and the testsuite verifies the retrieved values. But for the hash-map, the order of the results is not guaranteed, and implementation dependent.
Class IterExplorer< SRC >
if this turns out as a problem on the long run, we'll need to block the iterator operations on the builder (by inheriting protected) and provide an explicit build()-function, which removes the builder API and unleashes or slices down to the iterator instead.
Class IterSource_test
the output order of the values produced by this test is implementation dependent in for the hashmap case
Class IterTools_test
implement more iterator tools.... see Ticket #347
File jack-output.cpp
empty placeholder: yes we will support Jack Audio!
File jack-output.hpp
empty placeholder to underpin the claim: yes we will support Jack Audio!
File job-ticket.cpp
WIP-WIP-WIP 3/2012
Class JobFunctor
refactoring 4/23 – will replace JobClosure
Class JobTicket
6/23 WIP rework and integration for »PlaybackVerticalSlice«
Member JobTicket::getExpectedRuntime ()
6/2023 placeholder implementation with hard wired values in ExitNode
Class Label

Placeholder code for now.

planning to provide some kind of dynamic properties (map)

File label.cpp
result of the very first code generation from UML in 2008.
File label.hpp

result of the very first code generation from UML in 2008.

this is expected to become a very important facility eventually, so expec a lot of rework here...

Member Label::isValid () const
real validity self-check for Label MObject
Class LayoutElement
WIP-WIP as of 3/2020
File lazy-init.hpp
11/2023 at the moment I am just desperately trying to get a bye-product of my main effort into usable shape and salvage an design idea that sounded clever on first thought. I am fully aware that »lazy initialisation« is something much more generic, but I am also aware of the potential of the solution coded here. Thus I'll claim that generic component name, assuming that time will tell if we need a more generic framework to serve this purpose eventually....
Member lib::anonymous_namespace{random.cpp}::eternalNucleus
this one should somehow be configurable
Member lib::diff::mutateInPlace (Record< VAL > &record_to_mutate)
do we have a design mismatch here?? /////////////////////////////////////////TICKET #970
Member lib::explore (IT &&srcSeq)
this framework should be retrofitted to fit in with C++20 pipelines
Member lib::failsafeInvoke (std::exception_ptr &capturedFailure, FUN &&callable, ARGS &&...args) noexcept
with C++20 the body of the implementation can be replaced by std::invoke_r //////////////////////TICKET #1245
Member lib::idi::anonymous_namespace{entry-id.hpp}::buildHash (string const &sym, HashVal seed=0)
several unsolved design problems. How to deal with std hash values in conjunction with LUID. How to create a LuidH instance, if not generating a new random value. How to make EntryID and asset::Ident interchangeable, /////////TICKET #739 which would require both to yield the same hash values....
Member lib::idi::generateSymbolicID ()
consequently the generated IDs might clash for two distinct types, which generate the same namePrefix(). Is this a problem?
Member lib::query::removeTerm (Symbol sym, string &queryString)
as it seems we're not using the extracted term anymore, we could save the effort of rebuilding that term.
Member lib::test::randStr (size_t len)
probably this can be done in a more clever way.
Member lib::time::__framerate_approximation (double fps)
imposing a quite coarse limitation. If this turns out to be a problem: we can do better, use lib::reQuant (rational.hpp)
Member lib::time::getDefaultGridFallback ()
placeholder for accessing a current or default session grid.
File libgavl.cpp
2016 evaluate if libGAVL is still active and maintained
File libgavl.hpp
a draft and placeholder code from 2008, at which time the intention was to rely on libGAVL for processing of raw media data.
Member LibGavl::getImplFacade (TypeTag &)

fill in the actual GAVL frame type

how to distinguish the audio and the video case?

File load-controller.hpp
WIP-WIP 11/2023 »Playback Vertical Slice«
Class LoadController
WIP-WIP 10/2023 gradually filling in functionality as needed
File locatingpin.cpp

stalled effort towards a session implementation from 2008

2016 likely to stay, but expect some extensive rework

File locatingpin.hpp
this can be considered a preliminary sketch without being backed by actual functionality. Just enough to be able to drive the design of other parts ahead. See esp. TICKET #100, which contains an idea for a refactoring.
Class LocatingPin::LocatingSolution

we can't sensibly reason about tracks, because at the moment (10/07) we lack a track implementation...

shouldn't we use a range-restriction LocatingPin (subclass) to represent the to-be-found solution? (ichthyo: see Trac #100)

Member LocatingPin::resolve () const

this could/should be replaced by a full-blown constraint solver at some point in the future

we are packing and unpacking the information (time,track) several times. Ichthyo considers a more elegant solution.

Class LocationClause
maybe add a flag to require the current query goal to exist in tree //////////////////////////////TICKET #1130
File logging.h
logging to files?
Member Looper::wakeTimeout_ms ()
find a way how to retrieve this value from application config! ////////////////////TICKET #1052 : access application configuration
Member lumiera::error::default_usermsg (Error *) noexcept

to be localised

develop a framework to set more specific yet friendly messages

Member lumiera::WrapperPtr
really need to switch to the new lib::Variant and util::AccessCasted implementation ////////////////TICKET #450
Member lumiera_rational_to_time (FSecs const &fractionalSeconds)
this utility function could be factored out into a FSecs or RSec class ///////////////////////TICKET #1262
Member lumiera_resource
10/2023 this is a left-over of the »resource-collector« plan
Member lumiera_resource_try
10/2023 this is a left-over of the »resource-collector« plan Resource collection works iteratively freeing more and more resources.
File marker-widget.cpp

WIP-WIP-WIP as of 12/2016

as of 10/2018 timeline display in the UI is rebuilt to match the architecture

File marker-widget.hpp

WIP-WIP-WIP as of 12/2016

as of 10/2018 timeline display in the UI is rebuilt to match the architecture

Class MarkerWidget

WIP-WIP as of 12/2016

9/2022 baseclass sigc::trackable is ambiguous, we inherit it from two chains (diamond of death)

File mask.hpp
this file is there since the very first code generation steps at start of the Lumiera project. It never became clear if a mask generator would need to be a dedicated ProcNode subclass; but in fact the project did not reach the point of implementing anything regarding that topic.
File media-access-facade.cpp
this was added as a draft and mock implementation in 2008 and is only used sporadic for unit tests.
File media-access-facade.hpp
this was added as a draft and mock implementation in 2008 and is only used sporadic for unit tests.
File media-access-mock-test.cpp
this test must be linked against the Core (including Steam), yet conceptually it belongs into the Vault, indicating a design mismatch. The test support facility drafted here was not used much since then.
File media-access-mock.cpp
this facility was occasionally used until 2011, yet never really completed
File media-access-mock.hpp

this facility was occasionally used until 2011, yet never really completed

the implementation is linked against steam-layer to use a constant definition from 'steam/mobject/session/testclip.hpp' — which highlights an conceptual ambiguity underlying this whole concept; at inception time, there was no clear notion pertaining the kind of structures related to the vault.

Member MediaAccessFacade::queryChannel (MediaDesc &, uint chanNo) const
throw or return NULL-ChanDesc if Filehandle is invalid?
File menu-button.hpp
leftover from the old GTK-2 Lumiera UI as of 3/23, but should be retained and integrated into the reworked GTK-3 UI
Class Meta
do we need this abstract baseclass?
Class Meta
just a stub, still have to figure out the distinctive properties of asset::Meta //////////////////////////////////TICKET #1156 : do we need the distinction between STRUCT and META?
File meta-cmd.cpp
WIP 8/2018 early draft
File mini-button.hpp
leftover from the old GTK-2 Lumiera UI as of 3/23, but should be retained and integrated into the reworked GTK-3 UI
File mixer-widget.cpp
WIP-WIP-WIP as of 12/2016
File mixer-widget.hpp
WIP-WIP-WIP as of 12/2016
Class MixerWidget
WIP-WIP as of 12/2016
File mobject.hpp
as of 2016, this core part of the model still needs to be actually implemented. Most of the code in this hierarchy is preliminary or placeholder code, since we prefer to build the system from ground up, not top-down. It is very likely, that MObject will be just a data tuple in the end.
File mobject/session/clip.cpp

stalled effort towards a session implementation from 2008

2016 likely to stay, but expect some extensive rework

File mobject/session/clip.hpp

stalled effort towards a session implementation from 2008

2016 likely to stay, but expect some extensive rework

File mobject/session/effect.cpp
result of the very first code generation from UML in 2008.
File mobject/session/effect.hpp
result of the very first code generation from UML in 2008.
File mobject/session/meta.cpp

stalled effort towards a session implementation from 2008

2016 not sure if we really need a separate translation unit for this?

File mobject/session/meta.hpp

stalled effort towards a session implementation from 2008

2016 likely to stay, but expect some extensive rework

File mobjectfactory.cpp

stalled effort towards a session implementation from 2008

2016 likely to stay, but expect some extensive rework

File mobjectfactory.hpp

stalled effort towards a session implementation from 2008

2016 likely to stay, but expect some extensive rework. In fact I am quite unhappy with the shape of this code

Member MObjectFactory::operator() (asset::Clip const &, vector< asset::Media const *>)
work out the details of multichannel handling
Class MockElm
some usage details
File model-port.hpp
they might bulk allocated in a similar manner than the ProcNode and WiringDescriptor objects are.
Member MORef< MO >::operator _Id const & () const
not sure if that leads to unexpected conversions, because the underlying implementation can be converted to size_t
File mould.hpp
plan and draft from 2008 – still considered relevant as of 2016
File name-chooser.cpp
this widget is not currently used, as of 3/23; it is a leftover from the old GTK-2 GUI of Lumiera, but was retained since it might be useful in future...
File name-chooser.hpp
this widget is not currently used, as of 3/23; it is a leftover from the old GTK-2 GUI of Lumiera, but was retained since it might be useful in future...
Class Navigator
initial draft as of 2/2017 – actual implementation has to be filled in
File navigator-widget.cpp
WIP-WIP-WIP as of 12/2016
File navigator-widget.hpp
WIP-WIP-WIP as of 12/2016
File navigator.cpp

WIP 2/2017 early draft / foundations of "interaction control"

WIP 1/2018 integrating the concept of UI-Coordinate navigation and resolution. Still WIP-WIP-WIP...

File navigator.hpp
WIP 2/2017 early draft / foundations of "interaction control"
Class NavigatorWidget
WIP-WIP as of 12/2016
Class NetNodeFacade
define the services provided by such a node.
File netnodefacade.cpp
this just documents a vague plan. We won't be able to implement anything of that kind for the foreseeable future as of 1/2017
File netnodefacade.hpp
this just documents a vague plan. We won't be able to implement anything of that kind for the foreseeable future as of 1/2017
Class Nexus
write type comment
File nexus.hpp
initial draft and WIP-WIP-WIP as of 11/2015
File node-graph-attachment.hpp
2023 WIP-WIP-WIP »Playback Vertical Slice« need at least a drafted model
File nodecreatortool.cpp
stalled design draft from 2008 – basically still considered relevant as of 2016
File nodecreatortool.hpp
stalled design draft from 2008 – basically still considered relevant as of 2016
File nodefactory.cpp
draft from the early days of the Lumiera project, reworked in 2009 Development activity in that area as stalled ever since.
File nodefactory.hpp
draft from the early days of the Lumiera project, reworked in 2009 Development activity in that area as stalled ever since.
Member NodeFactory::operator() (mobject::session::PEffect const &, WiringSituation &)
as of 2016 this is the only (placeholder) implementation to indicate how building and wiring of nodes was meant to happen
Class NodeGraphAttachment
WIP-WIP as of 4/2023 – starting with a fake implementation /////////////////////TICKET #1306 : create an actual link to the low-level Model
Class NodeID
currently (10/08) this is a dummy implementation. We'll find out what is needed once the outline of the render engine is complete.
File nodeinvocation.hpp
relies still on an obsoleted implementation draft
File nodewiring.cpp
unfinished draft from 2009 regarding the render process
File nodewiring.hpp
unfinished draft from 2009 regarding the render process
File nop-job-functor.hpp
WIP draft for the »Playback Vertical Slice« 4/2023
File notification-hub.hpp
8/2018 for now we just use and possibly create a hard wired display within the first (primary) application window. Moreover, we do so directly, instead of consulting the (not yet fully implemented) ViewSpec mechanism. (via ViewLocator).
File null-value.hpp
initialisation could be extended to use a free function to fabricate the NIL value object, so to support the special case of an NIL object not being default constructible
Class OpaqueHolder_test
this test doesn't cover automatic conversions and conversions using RTTI from the target objects, while OpaqueHolder.template get() would allow for such conversions. This is similar to Ticket #141, and actually based on the same code as variant.hpp (access-casted.hpp)
File operationpoint.cpp
stalled design draft from 2008 – basically still considered relevant as of 2016
File operationpoint.hpp
stalled design draft from 2008 – basically still considered relevant as of 2016
Member Option::Option (lib::Cmdline &cmdline)
describe the actual options
Class OutputDesignation
couldn't the inline buffer be "downgraded" to InPlaceBuffer or PolymorphicValue?? Seemingly we never-ever need to re-discover the erased type of the embedded spec. Thus for this to work, we'd just need to add an "empty" spec ///////////////////TICKET #723
Class OutputDirector
write Type comment
Member OutputDirector::isOperational () const
WIP-WIP-WIP 6/2011
Class OutputManager

need a concrete implementation

need a unit-test

write Type comment

File panel-locator.hpp

8/2018 refactoring of docking panel handling is underway ///////////////////////////////////////TICKET # 1144 The PanelLocator is planned to become the one central coordinating manager, while the existing panel managers in each window will be demoted to a mere DockArea, corresponding to a gdl::Dock

8/2018 there is some overlap with the (not yet fully functional) ViewLocator in the InteractionDirector. Right now, PanelLocator fills some gaps here and offers preliminary solutions for some lookup and allocation tasks ultimately to be performed on a more abstract level through the ViewSpec-DSL. This corresponds to the observation, that PanelLocator and WindowLocator are somewhat tangled currently. The goal is to turn them into access services, and shift the allocation logic to the aforementioned higher level.

File panel-manager.hpp
2017 need to clarify the intended behaviour of panels ///////////////////////////////////////////////////////////////////////////TICKET #1097 clarify the role and behaviour of Panels
Member PanelLocator::preliminary_impl_PanelLookup (int typeID)
8/2018 the actual implementation shall eventually be provided by the ViewLocator on a higher abstraction level, and configurable through the ViewSpec-DSL. For now we use a braindead iterate-through-all-windows approach.
Class PanelManager
this code is smelly and needs some clean-up ///////////////////////////////TICKET #1026
Class PApply< SIG, VAL >
11/2023 started with modernising these functor utils. The most relevant bindFirst() / bindLast() operations do no longer rely on the PApply template. There is however the more general case of binding multiple arguments, which is still used at a few places. Possibly PApply should be rewritten from scratch, using modern tooling.
File parameter.cpp
as of 2016, we still need to work out our parameter/automation concept.
File parameter.hpp
as of 2016, we still need to work out our parameter/automation concept.
File paramprovider.cpp
as of 2016, we still need to work out our parameter/automation concept.
File paramprovider.hpp
as of 2016, we still need to work out our parameter/automation concept.
File patchbay-widget.cpp
WIP-WIP-WIP as of 12/2016
File patchbay-widget.hpp
WIP-WIP-WIP as of 10/2018
Class PatchbayWidget
WIP-WIP as of 4/2019
File path-array.hpp
when UICoord is in widespread use, collect performance statistics and revisit this design.
File pathmanager.cpp
placeholder as of 2014, development in this area is stalled
File pathmanager.hpp
this is a design draft and just defines a placeholder to indicate our plans.
Member PAUSED_JOB
do we need this special state?
File pipe-widget.cpp
WIP-WIP-WIP as of 12/2016
File pipe-widget.hpp
WIP-WIP-WIP as of 12/2016
Class PipeWidget
WIP-WIP as of 12/2016
Class PixSpan
quick-n-dirty hack.
File placement-index-query-resolver.cpp

WIP implementation of session core from 2010

as of 2016, this effort is considered stalled but basically valid

File placement-ref.hpp
better solution for the ID to type connection ///////////////////////TICKET #523
Member PlacementIndex::insert (PLA const &, ID)

this solution is half-baked ///////////////////////////////////TICKET #523

is this API used in application code? or just used in tests?

Class PlacementIndexQuery_test
change that to use a more realistic test session, based on the actual model types //////////////// TICKET #532
Class PlacementObjectIdentity_test
WIP-WIP to be written... TICKET #517
Class Play

WIP-WIP-WIP 6/2011

there should be an accompanying CL Interface defined for the Lumiera interface system, so the player can be accessed from external clients. This was left out for now, as we don't have either plugins, nor any script running capabilities yet. (5/2011)

File play-facade.hpp
in theory this could be an external interface mapped via Lumiera's interface system.
File play-service.cpp
as of 4/2023 Render-Engine integration work is underway ///////////////////////////////////////////TICKET #1233
File play-service.hpp

started as draft in 11/2011

as of 2016 development in this area is stalled, but the design done thus far valid

File playback-controller.hpp
create a durable PlaybacController design //////////////////////////////////////////////////////TICKET #1072
File player-widget.cpp
WIP-WIP-WIP as of 12/2016
File player-widget.hpp
WIP-WIP-WIP as of 12/2016 – the initial version of our UI implemented these controls directly within the timeline pane's button bar. We need to extract this common setup, since it is consensus that there is no consensus regarding the "best" position of such a control within the UI. So we need to offer the option to have "a player" either in the timeline, in the viewer(s) or as a standalone UI element.
Class PlayerWidget
WIP-WIP as of 12/2016
Member PlayOutSubsysDescriptor::shouldStart (Option &) override
actually define cmdline options and parse/decide here!
Class PlayTestFrames_Strategy
placeholder as of 6/23
File plug.cpp
result of the very first code generation from UML in 2008.
File plug.hpp
result of the very first code generation from UML in 2008.
File polymorphic-value.hpp
the actual implementation for copy support basically achieves this goal, but it is somewhat confusing and muddled, and not entirely correct in some corner cases (esp. when the target type does not collaborate but also does only support copy construction, but no assignment. In fact, part of the solution implemented here is known as "virtual copy support"; meanwhile we use a generic version of that pattern in our Variant container. Thus, at some point, we should rework this aspect of the solution to make it more orthogonal, clearer to understand and more correct. /////////////////////////////////////////////TICKET #1197
File preferences-dialog.hpp
as of 2016, this is more of a place-holder, since we also do not have decided on the implementation approach for application preferences in general.
Class Proc

just a stub, have to figure out what a asset::Proc is

Member ProcFactory::operator() (Asset::Ident &key)
actually define
Class ProcNode
it's not clear as of 9/09 if ProcNode shall be an ABC/Interface It might be used as ABC (as was the original intention) when implementing several query/information functions. In that case, the ctor will become protected. The alternative would be to push down these information-retrieval part into a configurable element within WiringDescriptor, in which case we even might drop ProcNode as a frontend entirely.
Member ProcPatt::ProcPatt (const Asset::Ident &idi)
preliminary implementation, storing the capabilities in the asset name field. We can do better, when it's clear what capabilities we need
File query-focus-stack.hpp

WIP implementation of session core from 2010

as of 2016, this effort is considered stalled but basically valid

File query-focus.cpp

WIP implementation of session core from 2010

as of 2016, this effort is considered stalled but basically valid

File query-focus.hpp

WIP implementation of session core from 2010

as of 2016, this effort is considered stalled but basically valid

File query-text.hpp
actually build the term representation /////////////////////////////TICKET #899
Member Query< RES >::extractID (Symbol predicate) const
used extensively for the mock implementation of query resolution. For real resolution queries, such a function is quite nonsensical. To be revisited and (likely) to be removed on the long run
Class QueryHandler< TY >
retrofit this to install and use a QueryResolver
Class QueryText
this is placeholder code and just embeds a string with the raw query definition, instead of parsing the definition and transforming it into an AST
Member QueryText::degree_of_constriction () const
using a rather deaf placeholder implementation based just on counting the top level predicates.
Member QueryText::normalise (string const &rawDefinition)
when integrating a real resolution engine, we need to parse and verify the given string.
Class QueryText_test
this is placeholder code. The actual query representation needs to be written /////////////////////////////TICKET #899
File random-draw.hpp
11/2023 This is a first draft and was extracted from an actual usage scenario. It remains to be seen if the scheme as defined is of any further use henceforth.
File random.cpp
3/2024 work out how some executions or performances are configured reproducibly.
Member Rational_test::verify_intLog2 ()
this test (and the implementation) belongs into some basic util header.
File real-clock.hpp
this might be a good candidate also to provide some kind of translation service, i.e. a grid to anchor a logical time value with actual running wall clock time.
File rectangle.cpp
3/23 this is leftover code from the old GKT-2 Lumiera GUI.
File rectangle.hpp
3/23 this is leftover code from the old GKT-2 Lumiera GUI.
File ref-array.hpp
as of 2016, this concept seems very questionable: do we really want to abstract over random access, or do we actually want for-iteration??
Class RefArray< T >
ouch – a collection that isn't iterable... ///////////////////////TICKET #1040
Class RelativeCanvasHook< WID >
investigate real-live performance ////////////////////////////////////////////////////////////////TICKET #1254 : investigate impact of indirection
Class RelativeLocation
just a design sketch, nothing finished yet.
File relativelocation.cpp

stalled effort towards a session implementation from 2008

2016 likely to stay, but expect some extensive rework

File relativelocation.hpp

stalled effort towards a session implementation from 2008

2016 likely to stay, but expect some extensive rework

File render-drive.cpp
4/2023 »Playback Vertical Slice« – effort towards first integration of render process ////////////TICKET #1221
File render-drive.hpp
4/2023 »Playback Vertical Slice« – effort towards first integration of render process ////////////TICKET #1221
File render-invocation.cpp
unfinished draft from 2009 regarding the render process
File render-invocation.hpp
unfinished draft from 2009 regarding the render process
File render.cpp
this widget is not currently used, as of 3/23; it is a leftover from the old GTK-2 GUI of Lumiera, but was retained since it might be useful in future...
File render.hpp
this widget is not currently used, as of 3/23; it is a leftover from the old GTK-2 GUI of Lumiera, but was retained since it might be useful in future...
Member RenderConfigurator::buildCalculationStreams (ModelPort, OutputSlot &)=0
get rid of the multiple channel connections /////////////////////////////////////////TICKET #1297 : retract differentiation into channels here (instead use ModelPorts in the Segment)
Class RenderDrive
4/23 early DRAFT – find out what this does and write type comment
Member RenderDrive::RenderDrive (RenderEnvironment &renderEnvironment, ModelPort port, uint chan)
Class RenderEngine
this was planned to become the frontend to the render node network, which can be considered at the lower end of the middle layer; the actual render operations are mostly implemented by the vault layer ////////TODO WIP as of 12/2010
Class RenderGraph
likely to be reworked into the engine backbone /////////////TODO WIP as of 12/2010
Class RenderInvocation
write type comment
Member RenderInvocation::operator[] (size_t channel)
for real use within the engine, the pull()-call should be dispatched through the scheduler; of course then the call semantics would be completely different. Maybe this invocation will be test only?
Class RenderState
probably the state management will work different (6/08)
Member ReplaceableItem_test::verifyOnlyMoveConstructible ()
conceptually, the whole point of this container is the ability to snapshot elements which allow nothing but move construction.
File result.hpp
an option-style interface could be provided for the »right value« (i.e. the exception caught), in case this turns out to be of any use; this kind of API design however is anything than trivial, given that any value can be thrown as exception in C++
Class Root
WIP-WIP.. Serialisation is postponed, the rules implementation is preliminary, the active link to the AssetManager is missing. Thus, as of 12/09 this is an empty placeholder and just serves as root scope.
File root.cpp

WIP implementation of session core from 2010

as of 2016, this effort is considered stalled but basically valid

File root.hpp

WIP implementation of session core from 2010

as of 2016, this effort is considered stalled but basically valid

Member Root::isValid () const
validity self-check of the model root should do substantial checks; the idea is to perform a complete sanity check by delegating to the parts.
File ruler-track.cpp

WIP-WIP-WIP as of 6/2019

this is more or less preliminary/placeholder code as of 4/2019

File ruler-track.hpp
WIP-WIP-WIP as of 6/2019
File ruler-widget.cpp
WIP-WIP-WIP as of 12/2016
File ruler-widget.hpp
WIP-WIP-WIP as of 12/2016
Member RulerScale::calcHeight ()
this is more or less braindead placeholder code as of 4/2019
Class RulerTrack
this is more or less preliminary/placeholder code as of 4/2019 ////////////////////////TICKET #1194 : proper handling of ruler tracks
Member RulerTrack::calcHeight ()
this is more or less braindead placeholder code as of 4/2019
Member RulerTrack::getGapHeight ()
this is more or less braindead placeholder code as of 4/2019
Class RulerWidget
WIP-WIP as of 12/2016
Class Scheduler
WIP 11/2023
File scheduler-frontend.hpp
WIP unfinished since 9/2013
File scheduler.hpp
WIP 11/2023 »Playback Vertical Slice«
Member Scheduler::triggerEmergency ()
as of 4/2024 it is not clear what Scheduler-Emergency actually entails; thus it can not be determined at which level of the component the handler must reside, and how it can be reached. Notably there exists a situation in SchedulerCommutatior::findWork(), where emergency can happen, yet in its current configuration, the Layer-2 has no access to the top-level Scheduler component. /////////////////////////////////////////////////TICKET #1362 : where to handle Scheduler-Emergency
Class SchedulerFrontend

this is planned to become the frontend to the render node network, which can be considered at the lower end of the middle layer; the actual render operations are mostly implemented by the vault layer

define the low-level scheduler interface and hook in the necessary calls to implement this frontend. ////////TODO WIP as of 9/2013

Member SchedulerLoadControl_test::simpleUsage ()
WIP 10/23 🔁 define ⟶ 🔁 implement
File scope-cmd.cpp
WIP 3/2017 early draft
File scope-locator.hpp

WIP implementation of session core from 2010

as of 2016, this effort is considered stalled but basically valid

File scope-path.cpp

WIP implementation of session core from 2010

as of 2016, this effort is considered stalled but basically valid

File scope.hpp

WIP implementation of session core from 2010

as of 2016, this effort is considered stalled but basically valid

File scoped-holder-transfer.hpp
expunge this!
Member ScopedPtrVect< T >::detach (void *objAddress)
TICKET #856 better return a Maybe<T&> instead of a pointer?
Member ScopeQuery< MO >::buildSyntacticRepresentation () const
we need a readable and sensible representation as generic query ///////////////////TICKET #901
Class ScopeQuery_test
change that to use a more realistic test session, based on the actual model types //////////////// TICKET #532
Class ScriptRunnerFacade
build the (LUA,C)-script runner.
File scriptrunnerfacade.cpp
this just documents a vague plan. We won't be able to implement anything of that kind for the foreseeable future as of 1/2017
File scriptrunnerfacade.hpp
this just documents a vague plan. We won't be able to implement anything of that kind for the foreseeable future as of 1/2017
Class Segment
WIP-WIP as of 6/2023 – about to establish the engine backbone
File segment.cpp

stalled effort towards a session implementation from 2008

2016 likely to stay, but expect some extensive rework

File segment.hpp

WIP 6/2023 now actually in implementation due to »Playback Vertical Slice«

Datastructure as such is settled; memory allocation and remoulding of an existing Segmentation remains future work as of 6/2023

Class Segmentation

1/2012 Just a Placeholder. The real thing is not yet implemented.

4/2023 now about to bootstrap into the implementation structure step by step (WIP)

File segmentation-tool.cpp
stalled design draft from 2008 – basically still considered relevant as of 2016
File segmentation-tool.hpp
stalled design draft from 2008 – basically still considered relevant as of 2016
File segmentation.cpp
2023 WIP-WIP-WIP »Playback Vertical Slice«
File segmentation.hpp
5/2023 now actually started with the implementation for the »Playback Vertical Slice«
Class SegmentationIntegration_test
2010 ⁐ 2023 a sketch for a test setup, which was meanwhile elaborated into the DummyPlayConnection; indeed such a component integration test is still required to document and cover the fixture data structure....
File sequence-cmd.cpp
WIP 4/2017 early draft
File sequence.hpp
this is a very crucial part of the emerging design of the session model. Unfortunately, development on that frontier has stalled since 2010, since we focused efforts towards the player, the engine and the GUI lately (as of 2016)
File sess-manager-impl.cpp
as of 2016 this is an implementation draft, awaiting integration with several other facilities //////////////////TICKET #704
File sess-manager-impl.hpp
as of 2016, this effort is considered stalled but basically valid
File session-cmd.cpp
WIP 3/2017 early draft
File session-impl.cpp

WIP implementation of session core from 2010

as of 2016, this effort is considered stalled but basically valid

File session-service-defaults.hpp
rework the existing DefsManager to fit into this scheme. TICKET #404
File session-services.cpp

WIP implementation of session core from 2010

as of 2016, this effort is considered stalled but basically valid

Member Session::initFlag
really solve the basic init of session manager TICKET #518
Class SessionCommand
as of 2/2021 only the trigger operation is used; if no case for an elaborated command cycle with binding step and deferred invocation shows up, we may consider dropping the other operations
Class SessionManager_test

load a Mock session

create a session and save (serialise) it

load a real test session

Member SessionManager_test::clearSession ()
implement all session content, implement mobject and asset deletion operations.
Member SessionManager_test::loadMockSession ()
implement rebuilding session, implement mock session serialiser
Member SessionManager_test::loadSession (const string &src)
implement real session serialiser
Member SessionManager_test::resetSession ()
define the "global session config", implement session default ctor
Member SessionManager_test::saveSession (string &dest)
implement real session serialiser
Class SessionModifyParts_test

check more kinds of modifications, especially moving parts

define criteria to be checked more precisely

verify the actually dispatched commands

Class SessionStructure_test

define further criteria to be checked

implement Sequence, Fixture, Session::rebuildFixture, handling of EntryID<Fork>

Member SessManager::save (string snapshotID)=0
2017 how actually to serialise, parameters, return value?
Member SessManagerImpl::clear () override
clarify relation to command processing/undo /////////// TICKET #697
Member SessManagerImpl::close () override

avoid blocking when aborting render processes ///////////// TICKET #201

well defined transactional behaviour ///////////////////// TICKET #698

Member SessManagerImpl::reset () override

error handling, how to deal with a partially configured session?

for reset() to work, we need to change the implementation of AssetManager so support this kind of transactional switch!

Class SimpleAllocator< TYPES, COUNTER >
currently (as of 8/09) the low-level pooled allocator isn't implemented; instead we do just heap allocations. ////////////////////////////////////////////////////////////////////////////////////////////Ticket #835
Class SimpleAllocator_test
as of 9/11 we do heap allocation, but we should use mpool – see also Ticket #835
Member Smpte::applyRangeLimitStrategy (SmpteTC &)
If necessary, this extension point should be converted into a configurable strategy. Possible variations
  • clip values beyond the boundaries
  • throw an exception on illegal values
  • wrap around from 23:59:59:## to 0:0:0:0
  • just make the hour negative, but continue with the same orientation (0:0:0:0 - 1sec = -1:59:59:0)
Member Smpte::getFramerate (QuantR, TimeValue const &)
this design just doesn't feel quite right...
Class SmpteTC
the range extension scheme could be a configurable strategy
File source.hpp
this file is there since the very first code generation steps at start of the Lumiera project. It is not yet clear if those source reading nodes will indeed be ProcNode subclasses, or rather specifically configured processing nodes...
File special-job-fun.hpp
WIP 12/2023 invented to help with Scheduler load testing as part of the »Playback Vertical Slice« — this idea however might be generally useful to handle one-time adjustments from within a play- or planning process.
Member SpecialJobFun_test::simpleUsage ()
WIP 12/23 🔁 define ⟶ ✔ implement
Member SpecialJobFun_test::verifyLifecycle ()
WIP 12/23 ✔ define ⟶ ✔ implement
File specific-contents-query.hpp

WIP implementation of session core from 2010

as of 2016, this effort is considered stalled but basically valid

Class SpecificContentsQuery< MO >
develop a system of sub-indices and specialised queries
File spot-locator.cpp
WIP 2/2017 early draft / foundations of "interaction control"
File spot-locator.hpp
WIP 2/2017 early draft / foundations of "interaction control"
Class SpotLocator
initial draft as of 2/2017 – actual implementation has to be filled in
Namespace stage::model

: as of 1/2011 this connection between the GUI proxy model and the Steam-Layer model needs to be set up. Currently, the GUI model entities are just created standalone and thus dysfunctional.

: as of 11/2015 this connection between UI and Steam-Layer is actually in the works, and it is clear by now that we won't use proxy objects, but rather a generic bus-like connection and symbolic IDs to designate the model elements

: and as of 2/2017 the new structure is basically set, but we need actually to implement a new timeline display in accordance to this reworked design. After this is done, most of the model elements in this packare are obsolete.

Member stage::model::anonymous_namespace{zoom-window.hpp}::_FSecs (TimeValue const &timeVal)
preliminary helper to enter into fractional integer calculations
  • FSecs (maybe better called RSec) should be a light-weight wrapper on top of util::Rat = boost::rational<int64_t>
  • a conversion function like in TimeVar should be in the base type
  • however, cross conversion from raw int64_t should be prohibited to avoid ill-guided automatic conversions from µ-tick to seconds
Member stage::model::anonymous_namespace{zoom-window.hpp}::isMicroGridAligned (FSecs duration)
should likewise be member of a FSecs wrapper type...
Member stage::model::anonymous_namespace{zoom-window.hpp}::operator+ (Time const &tval, TimeVar const &tvar)
we need these only because the blurry distinction between lib::time::TimeValue and lib::time::Time, which in turn is caused by a lack of clarity in the fundamental conception (see #1261)
Member stage::timeline::anonymous_namespace{stave-bracket-widget.cpp}::connect (CairoC cox, Gdk::RGBA colour, double leftX, double upperY, double lowerY, double width, double scale, std::vector< uint > connectors)
simplistic implementation as of 3/23; could be made expandable /collapsable
Member stage::widget::anonymous_namespace{element-box-widget.cpp}::reduce (Gtk::Label &label, int goal)
10/22 also attempt to shorten the label... ///////////////////TICKET #1242 : adjust size of the ID caption
Member stage::widget::anonymous_namespace{error-log-display.hpp}::populateStandardTextTags (Glib::RefPtr< TextBuffer::TagTable > tagTable)
9/2018 dummy placeholder code, later to be transformed into a framework /////////////////////TICKET #1168 : find a way to manage style of custom extended UI elements
File state-manager.hpp
as of 2/2016 this is still preliminary. In the end, we want to capture and restore presentation state in dependency to the current perspective and work site
File state-recorder.hpp
as of 2/2016 noting but a simple data retrieval happens here. Actually, on the long run, we want "intelligent" handling of presentation state, we want to capture and restore state with sensitivity to perspective and work site. Probably this means to layer a second level of aggregation on top.
Class StateMapGroupingStorage
reinvestigate with GCC-5 //////////////////////////////////TICKET #991
Member StateMapGroupingStorage::getState (Record const &entry, string propertyKey)

seemingly GCC-4.9 doesn't yet support the "transparent search" feature of C++14, where std::set would support an additional overload of the find() function, templated to accept a value convertible to some key equivalent, which needs to be understood by the comparator of the set. To trigger using this overload, the comparator has to define a suitable operator() and in addition a marker type is_transparent. See transparent-cmp and the [reference][cind-cpp14] for explanation. //////////////////////////////////TICKET #991

File stateproxy.cpp
unfinished draft from 2009 regarding the render process
File stateproxy.hpp
unfinished draft from 2009 regarding the render process
File steam/mobject/builder/common.hpp
initially generated code of unclear relevance
File steam/mobject/session/binding.cpp

stalled effort towards a session implementation from 2010

2016 likely to stay, but expect some extensive rework

File steam/mobject/session/binding.hpp

stalled effort towards a session implementation from 2010

2016 likely to stay, but expect some extensive rework

Also consider timeline-slave, a topic postponed as of 10/2018 /////////////////////////////////TICKET #1083

Member steam::anonymous_namespace{config-resolver.cpp}::configure_ConfigResolver ()
PLANNED: use an embedded Prolog-System or similar rules engine. For the time being (as of 2008-2018), we use preconfigured fake answers for some common Config-Queries
Member steam::asset::anonymous_namespace{clip.cpp}::createClipIdent (const Media &mediaref)
getting this one correct is important for handling creation of multiple clip instances from one media. Means we have still to figure out a sensible concept...
Member steam::asset::anonymous_namespace{preview.cpp}::createProxyIdent (const Asset::Ident &mediaref)
getting this one right is important for the handling of "proxy editing"....
Member steam::asset::DUMMY_TIME (FSecs(5))
solve config management
Member steam::asset::meta::theErrorLog_ID
8/2018 for now this is a mere placeholder, but someone need to build a singleton asset to incorporate this eventually ///////////////////////////////////TICKET #1157
Member steam::cmd::COMMAND_DEFINITION (test_meta_markError)
this is a demo mock setup to further development of the Steam-Stage integration //////////////TICKET #1140 : prototypical Steam-Stage communication
Member steam::cmd::COMMAND_DEFINITION (test_fake_blubb)
use this to enact a complex layout structure in the Timeline-UI //////////////////TICKET #1042 : further the DummySessionConnection
Member steam::cmd::COMMAND_DEFINITION (test_fake_injectSequence_1)
use this to establish basic Timeline display in the UI //////////////////TICKET #1014 : produce Dummy content to populate timeline
Member steam::cmd::COMMAND_DEFINITION (scope_moveRelocateClip)
WIP-WIP 3/2021 – working on a prototype for dragging clips...
Member steam::cmd::COMMAND_DEFINITION (test_meta_activateContentDiff)
used for preliminary integration testing ///////////////////////////////////////////TICKET #211 prefix test_ bypasses logging and immediately executes for now (2018)
Member steam::cmd::COMMAND_DEFINITION (test_meta_displayInfo)
this is a demo mock setup to further development of the Steam-Stage integration //////////////TICKET #1140 : prototypical Steam-Stage communication
Member steam::cmd::COMMAND_DEFINITION (test_meta_markAction)
this is a demo mock setup to further development of the Steam-Stage integration //////////////TICKET #1140 : prototypical Steam-Stage communication
Member steam::cmd::COMMAND_DEFINITION (test_fake_injectSequence_2)
use this to enact a complex layout structure in the Timeline-UI //////////////////TICKET #1014 : produce Dummy content to populate timeline
Member steam::cmd::COMMAND_DEFINITION (test_meta_markNote)
this is a demo mock setup to further development of the Steam-Stage integration //////////////TICKET #1140 : prototypical Steam-Stage communication
Member steam::control::anonymous_namespace{looper.hpp}::STEAM_DISPATCHER_BUILDER_DELAY_ms
this value should be retrieved from configuration ////////////////////////////////TICKET #1052 : access application configuration
Member steam::control::anonymous_namespace{looper.hpp}::STEAM_DISPATCHER_BUSY_SLOWDOWN_FACTOR
this value should be retrieved from configuration ////////////////////////////////TICKET #1052 : access application configuration
Member steam::control::test::anonymous_namespace{dispatcher-looper-test.cpp}::EXPECTED_BUILDER_DELAY_ms
this value should be retrieved from configuration ////////////////////////////////TICKET #1052 : access application configuration
Namespace steam::mobject
is this interface or implementation ??
Member steam::mobject::ON_SESSION_END
specify how this is related to "saving". Is there a way for subsystems to add specific/internal information into the persisted state, besides actually attaching data to objects within the session?
Member steam::mobject::PlacementMO
cleanup uses of ref-to-placement.
Class StreamType
this is just a draft to show the general idea....
Class Struct
the actual meaning of a "structural asset" needs to be sharpened and evolved. The idea is to have a generic mechanism for attaching properties and relations. This will become relevant once we build the real query subsystem. Right now (as of 1/2015), asset::Struct is just an ID provider. //////////////////////////////////TICKET #1156 : do we need the distinction between STRUCT and META?
File struct.cpp
while most code here is a very preliminary draft (let's call it a hack), as of 2016 we acknowledge that this design is here to stay and represents one of the most distinctive features of Lumiera
Member StructFactory::newInstance (Symbol nameID="")
using the AssetManager this way for picking up the previously stored asset is a code smell ////////////////////////////TICKET #691
Member StructFactory::operator() (Query< STRU > const &query)

work out the struct asset naming scheme! /////////////////////////////////TICKET #565

for now we're using a faked config query, just pulling preconfigured hardwired answers from a table. Should be replaced by a real resolution engine.

Class StructFactoryImpl

better use a general struct traits class, esp.for creating the Ident

shouldn't some of the generic factory logic be moved over into the struct baseclass? ////////////////TICKET #565

Member StructFactoryImpl::fabricate (Query< STRU > const &caps)
a real implementation using a resolution engine.
File style-scheme.hpp
as or 10/2018 this is mere placeholder code. The StyleManager needs rework
File stypemanager.hpp
very crucial part of the design, unfortunately development in this area is stalled since 2012
Member STypeManager::getImpl (Symbol libID, StreamType::Prototype const &protoType)
find out if this one is really necessary, because it is especially tricky
Class STypeManager::Registry
as of 3/2008 the real query implementation is missing, and the exact behaviour has to be defined.
File sub-id.hpp
1/2016 this idea seems very reasonable, and we should just make it robust and usable, along the lines pointed out by that draft
  • use std::tuple as storage
  • remove the format-util dependency (!) ////////////////////////////////TICKET #985
  • provide a hash implementation for real
  • extend to arbitrary number of sub-dimensions (variadic)
  • implement comparisons as you'd do for any algebraic type
  • provide a metaprogramming facility to get an id tuple
File subsystem-runner.hpp
as of 2018, a design rework seems indicated eventually /////////////////////////TICKET #1177
Class SubsystemRunner
2018 this component works well but could be (re)written in a cleaner way ////////////////////////TICKET #1177
File suite.hpp
as of 9/09, the implementation seems OKish but a bit clumsy. See Ticket #289
File switchboard-widget.cpp
WIP-WIP-WIP as of 12/2016
File switchboard-widget.hpp
WIP-WIP-WIP as of 12/2016 this is a plan (yes, we most definitively want that!), but we do not even remotely know how to implement such a feature. It is only clear by now that we'll build a output processing graph on top of the core render nodes network, and this output processing will care e.g. for scaling the output to fit into the viewer window. Activating the switchboard needs to extend this output processing graph.
Class SwitchboardWidget
WIP-WIP as of 12/2016
Member SYMBOL
intention is to integrate with lib::Symbol
File symbol-impl.cpp
currently as of 9/09 this is more of a placeholder. And maybe a location for collecting small bits of implementation, which could be usable later for real Symbol and Literal datatypes.
File symbol-table.hpp
as of this writing (4/2017), it is neither clear if we really need such a facility, nor do we know enough to judge the implementation approach taken here. It might well turn out that a mere hash over the symbol string would be sufficient. Just the general vision for Lumiera indicates that we're going to rely heavily on some kind of symbolic or meta processing, involving a rules based query system, and in the light of such future developments, introducing a distinct lib::Symbol datatype seemed like a good idea. When we started to generate command IDs systematically, just literal c-string constants weren't sufficient anymore, leading to this very preliminary table based implementation.
File symbol.hpp
9/2017 consider this mostly as settled, but might require some finishing touches
  • maybe improve interoperation of Symbol and std::string
  • investigate performance of the automatic symbol table
  • improve Lifecycle in startup and shutdown phase
  • maybe some metaprogramming magic to build distinct types based on symbols.
Class Symbol_test
2023 this test is very much in preliminary shape, as the implementation of a real symbol table remains was lacking. At some point, a simplistic implementation of »interned strings« was added (TICKET #157) — yet still the actual relevance of unique Symbols remains nebulous
File sync-barrier.hpp
as of 9/2023 it remains to be seen if this facility is just a pre-C++20 workaround; otherwise it may present distinct performance characteristics than std::latch, possibly also a slightly more abstracted (and thus clearer) usage API.
File tangible.hpp
Some actions are very common and can be represented by a shorthand. An example would be to tweak some property, which means to mutate the attribute of a model element known beforehand. Such tweaks are often caused by direct interaction, and thus have the tendency to appear in flushes, which we want to batch in order to remove some load from the lower layers.
Class TCode
as of 2016 this is basically finished since years, but still not in any widespread practical use (not by bad intention, simply by lack of opportunities). So this core interface still needs some feedback from practice in order to be finalised.
File test-control.hpp

as of 9/2018, this is a first rough draft, relevant for #1099 ////////////////////////////TICKET #1140 gradually augment the self-diagnostics controls in the UI

this header also features a design draft how to simplify building notebook widgets. Which could be polished and moved into a separate utility header eventually.

File test-dummy-mobject.hpp
needed to move this temporarily into the core session tree. ////////////TICKET #532
File test-element-access.hpp
right now this test is braindead; the idea is to extend it similar to the GenNodeLocationQuery eventually, so to mimic the way an actual implementation would drill down into the UI topology. Yet at the moment (4/2018) we are still far from implementing anything in this regard; we just need the interface... ///////////////////////////////TICKET #1134
File test-mutation-target.hpp
WIP 2/2016
Class TestClip
maybe use this as Mock object to record invoked operations?
File testsession1.hpp
this is an idea from the early stages of the project and was never really implemented.
File timecode-widget.hpp
needs extensive rework to get smooth integration with Lumiera's timecode handling functions
File timecode.cpp
a started implementation exists since 2010, yet crucial parts still need to be filled in as of 2016
Member TimeGrid::TimeGrid (GridID const &)
drafted in 2010 – usage of the builder feels unsatisfactory as of 2018
Class Timeline

this new Timeline API was invented about 2010 and remained in half finished state ever since.

we need some actual interface, beyond just creating timelines!

2016 can confirm that we still want to go that route

File timeline-controller.cpp
as of 10/2018 timeline display in the UI is rebuilt to match the architecture
File timeline-controller.hpp
as of 10/2018 timeline display in the UI is rebuilt to match the architecture
File timeline-panel.cpp

as of 10/2016 this is WIP-WIP-WIP : canvas widgets experiment

as of 10/2018 we start to build a new timeline widget, connected to the UI-Bus

File timeline-panel.hpp

as of 10/2016 this is WIP-WIP-WIP : canvas widgets experiment

as of 10/2018 we start to build a new timeline widget, connected to the UI-Bus

File timeline-widget.cpp
as of 10/2018 a complete rework of the timeline display is underway
File timeline-widget.hpp
as of 10/2018 a complete rework of the timeline display is underway
File timeline-zoom-scale.cpp
this was the »zoom slider« implementation from the old GTK-2 GUI of Lumiera. Since 2016, this was deactivated and since 3/23 it is no longer included anywhere, just left in tree to be re-integrated into the reworked GKT-3 Timeline UI
File timeline-zoom-scale.hpp
this was the »zoom slider« implementation from the old GTK-2 GUI of Lumiera. Since 2016, this was deactivated and since 3/23 it is no longer included anywhere, just left in tree to be re-integrated into the reworked GKT-3 Timeline UI ///////////////////////////////////////////////////////////////////////////TICKET #74 : Zoom Slider ///////////////////////////////////////////////////////////////////////////TICKET #1196 : draft zoom handling
File timeline.hpp

around 2010, the concept of Timeline and Session binding was defined, together with a rough preliminary implementation. Up to 2017, there was no opportunity to set this system really into motion; this is not necessarily a bad thing, since meanwhile we understand way better in which way the Session will actually be accessed...

looks like we'll represent a secondary, attached slave display of the same Timeline rather by materialising it into a TimelineClone within the session. This topic has been postponed as of 10/2018 //////////////////////////////////////TICKET #1083

Member Timeline::Timeline (Ident const &, RBinding const &)
anything significant to do here???
Member TimelineCanvas::on_draw (CairoC) override
according to the documentation for signal_draw(), the framework passes the actually visible area as clipping region. In theory, this information could be used to reduce the load of canvas painting and repainting, which becomes crucial for responsiveness on large sessions ////////////////////////////////////TICKET #1191
Class TimelineController
WIP-WIP-rewrite as of 12/2016
Class TimelinePanel
WIP 10/2018 the actual re-implementation of Lumiera's Timeline display
Class TimelineSequenceHandling_test

specify how deletion is handled

specify how to move objects by placement

Member TimelineState::playbackPoint_
very likely to be handled differently when actually integrated with the Player
Member TimelineState::setPlaybackPoint (Time newPos)

do we ever get the situation that we don't have such a position?

very likely to be handled differently, once the GUI is really connected to the Player

Class TimelineWidget
WIP-WIP-rewrite as of 12/2016
Class TimelineWidgetEmpty
This widget could offer a list of last sessions to pick from etc...
Member TimelineZoomScale::TimelineZoomScale ()

The initial adjustment value needs to match what the TimelineViewWindow's actual timeScale Value is.

actually there is a more involved problem. The TimelineWidget maintains a TimelineState, which in turn owns the TimelineViewWindow. Now, the problem is: when we switch to another Sequence (View), then this TimelineState gets switched too, causing also a entirely different TimelineViewWindow to become effective. Thus

  • how can we managed to be notified from that switch?
  • problem is: TimelineZoomScale widget is owned by the TimelinePannel. Likewise, TimelineWidget is owned by the TimelinePannel. But the state handling/switching logic is embedded within TimelineWidget
  • and finally: how can we translate the actual scale (in time units), as maintained within TimelineViewWindow, back into the adjustment used here (which uses a relative scale 0...1.0 ) S
Class TimeSpan
define these mutations
Class Timings
write type comment /////////////////////////////////////////////////////////////////TODO: WIP seems to become some kind of abstracted Grid representation!
File timings.hpp
WIP-WIP-WIP 8/2011
Member Timings::constantFrameTimingsInterval (TimeValue startPoint) const
implement real support for variable frame rates
File toolfactory.cpp
stalled design draft from 2008 – basically still considered relevant as of 2016
File toolfactory.hpp
stalled design draft from 2008 – basically still considered relevant as of 2016
Member ToolFactory::getProduct ()
unclear what to do and to return here
File track-body.hpp
as of 3/2023 the reworked Timeline-UI is basically complete
File track-head-widget.cpp
as of 1/2023, the basic structure was (finally) settled and the painting of vertical space allocation looks correct up to ± 1px, when testing with various margin, border and padding settings in the CSS.
File track-head-widget.hpp
as of 3/2023 the reworked Timeline-UI is basically complete
File track-presenter.hpp

as of 10/2018 timeline display in the UI is rebuilt to match the architecture

as of 3/2023, the basic structure is settled and the design validated

File track-profile.hpp
WIP-WIP-WIP as of 6/2019
Class TrackBody
WIP-WIP as of 6/2019
Class TrackHeadWidget
WIP-WIP as of 12/2016
Class TrackPresenter
WIP-WIP as of 12/2016
Member TrackPresenter::relinkContents ()
2/2021 WIP-WIP initial draft; many aspects still unclear
Class TrackProfile

WIP-WIP as of 4/2019

the number of pinned elements should be a member field, instead of sneaking it into the prelude element...

Class Trait< TY, YES >
this whole decision logic works but is confusingly written ///////////////////////TICKET #1197 : improve design of copy support
File transition-widget.cpp
WIP-WIP-WIP as of 12/2016
File transition-widget.hpp
WIP-WIP-WIP as of 12/2016
Class TransitionWidget
WIP-WIP as of 12/2016
File tuple-helper.hpp
transition lib::meta::Types to variadic parameters /////////////////////////////////TICKET #987
File typed-allocation-manager.hpp

WIP WIP.

using a quick-n-dirty heap allocation implementation for now (8/09), but should write a custom allocator based on cehteh's mpool!

File typed-counter.hpp
2010 ... this is the first, preliminary version of a facility, which is expected to get quite important for custom allocation management.
File typed-id.hpp
and as of 2016, we acknowledge the importance of this approach, just the topic is deferred for now and will be picked up later...
File typed-lookup.cpp
this is placeholder code for an important facility, required once we engage into predicate rules based configuration.
Class TypedAllocationManager
currently (as of 8/09) the low-level pooled allocator isn't implemented; instead we do just heap allocations. see Ticket 231
Class TypedAllocationManager_test
as of 9/09 we do heap allocation, but we should use mpool – see also Ticket #219
Class TypedID::Link< TY >
unfinished design; especially: have to care for correct copying ////////////////////TICKET #593
Class TypedID_test
draft from 2010 – partially unimplemented and thus commented out //////////////////////////////////////////STICKET #599
Class TypeHandler< TY >
6/2010 unify this with the TypeHandler in typed-id.hpp
Class TypeHandlerXX< TY >
design draft as of 4/2010. This interface should eventually be merged with the TypeHandler defined in configrules.hpp
File typelist.hpp
transition lib::meta::Types to variadic parameters /////////////////////////////////TICKET #987
File typeseq-util.hpp
transition lib::meta::Types to variadic parameters /////////////////////////////////TICKET #987
File ui-bus.hpp
as of 1/2015, this header needs to be reshaped ////////////////////TICKET #959
File ui-coord.hpp
WIP 9/2017 first draft ////////////////////////////////////////////////////////////////////////////TICKET #1106 generic UI coordinate system
File ui-location-solver.hpp
as of 2017 .. 2021, this is a half-finished draft and postponed in favour of building the actually visible timeline display first
Member UICoord::isExtendedBelow (UICoord const &parent) const
10/2017 have to verify suitability of this definition
Member UiManager::updateWindowFocusRelatedActions ()
find a solution how to enable/disable menu entries according to focus /////////////////////////////////////////////////TICKET #1076 find out how to handle this properly
Class UiState
initial draft as of 2/2017 – actual implementation has to be filled in
Class UnimplementedConnection
5/2023 quick-n-dirty placeholder to be able to fabricate fake DataSink handles (Handle<Connection>)
Class Unknown
maybe do special handling of the media length, allowing it to support existing clips even if the media length is not known?
Member util::almostEqual (double d1, double d2, unsigned int ulp=2)
3/2024 seems we have solved this problem several times meanwhile /////////////////////////////////TICKET #1360 sort out floating-point rounding and precision
Member util::for_each (Container const &coll, FUN doIt)
reconsider if using rvalue references covers the "inline iteration" use case sufficiently, so that we can get rid of the unwrapping and thus get back to strict const correctness.
Member util::ilog2 (I num)
C++20 will provide std::bit_width(i) — run a microbenchmark!
File variadic-helper.hpp
transition lib::meta::Types to variadic parameters /////////////////////////////////TICKET #987
File variant-o.hpp

the instance handling for the accessor seems somewhat clumsy: we're creating a static accessor instance for each type of access functor, and each of these accessors holds a trampoline table. Why are we building a table, while we're using a templated access functor anyway? This table inhibits inlining, and there seems to be no runtime benefit. This whole design indeed was a hastily made (prompted by actual need) first attempt. It should be rewritten from scratch (HIV 4/2015)

///////////////////////////////////////TICKET #738 should be rewritten from scratch

///////////////////////////////////////TICKET #141 write an unit test for variant

Class Variant< TYPES >
we need to define all copy operations explicitly, due to the templated one-arg ctor to wrap the actual values. There might be a generic solution for that ////////////////////////TICKET #963 Forwarding shadows copy operations – generic solution?? But – Beware of unverifiable generic solutions!
Class VideoDisplayWidget
the first UI draft included a video displayer widget library implementation, Unfortunately, this became defunct with the switch to GTK-3.
File view-locator.cpp
WIP 9/2017 early draft ////////////////////////////////////////////////////////////TICKET #1104
File view-locator.hpp
WIP 6/2018 half finished draft ////////////////////////////////////////////////////////////TICKET #1104
File view-spec-dsl.hpp
as of 9/2017, we confirm the intention to open this configuration DSL for some kind of user provided flexible configuration of screen layouts eventually; yet right now, only the foundation for this flexible configuration is provided while the defaults are to be compiled into the UI as hard wired constants.
File viewer.cpp
half finished draft, topic was postponed as of 2014, but will become relevant again
File viewer.hpp
WIP-WIP-WIP as of 5/11
Member Viewer::Viewer (Ident const &)
anything significant to do here???
Class ViewLocator
initial draft as of 9/2017 – actual implementation need to be filled in
Class Widget
write type comment...
File widget.hpp
as of 1/2015 this is complete WIP-WIP-WIP
Class WiringDescriptor
the design of this part is messy in several respects. Basically, its left-over from a first prototypical implementation from 2008 As of 1/2012, we're re-shaping that engine interface and invocation with a top-down approach, starting from the player. Anyhow, you can expect the basic setup to remain as-is: there will be a ProcNode and a WiringDescriptor, telling how it's connected to its predecessors, and defining how the Node is supposed to operate
File wiringrequest.hpp
stalled design draft from 2008 – basically still considered relevant as of 2016
File wish.cpp
result of the very first code generation from UML in 2008.
File wish.hpp
result of the very first code generation from UML in 2008.
Class Wizard
initial draft as of 2/2017 – actual implementation has to be filled in
File wizard.cpp
WIP 3/2017 early draft of the UI top-level controllers
File wizard.hpp

The infrastructure for context sensitive help needs to be defined

WIP 3/2017 early draft of the UI top-level controllers

File work-force.cpp
WIP-WIP 11/2023 »Playback Vertical Slice«
File work-site-trail.cpp
WIP 2/2017 early draft / foundations of "interaction control"
File work-site-trail.hpp
WIP 2/2017 early draft / foundations of "interaction control"
File work-site.cpp
WIP 2/2017 early draft / foundations of "interaction control"
File work-site.hpp
WIP 2/2017 early draft / foundations of "interaction control"
Class WorkSite
initial draft as of 2/2017 – actual implementation has to be filled in
Class WorkSiteTrail
initial draft as of 2/2017 – actual implementation has to be filled in
File wrapper.hpp
2017 consider to split off the FunctionResult into a dedicated header to reduce includes
File zoom-window.cpp
do we need this dedicated translation unit? As of 11/2022, the ZoomWindow component was developed header-only... However the amount of code is significant and the details are complex, and there is indeed a major implementation-only block with private functions.
File zoom-window.hpp

as of 12/2022 it rather seems the more general navigation should be abstracted at a higher level, leaving ZoomWindow mostly focused on time scale handling.

WIP-WIP as of 10/2022 the usage is just emerging, while the actual meaning of this interface still remains somewhat nebulous...

Member ZoomWindow::addSafe (FSecs t1, FSecs t2)
this utility function could be factored out into a FSecs or RSec class //////////////////TICKET #1262
Member ZoomWindow::anchorPoint () const
10/2022 we use a numerical rule currently, but that could be contextual state, like e.g. the current position of the play head or edit cursor or mouse.
Member ZoomWindow::detox (Rat poison)
this utility function could be factored out into a FSecs or RSec class //////////////////TICKET #1262
Member ZoomWindow::scaleSafe (FSecs duration, Rat factor)
this utility function could be factored out into a FSecs or RSec class //////////////////TICKET #1262