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