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. Relevance not clear yet...

File abstractmo.hpp

result of the very first code generation from UML in 2008. Relevance not clear yet...

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

5/2025 generally speaking, we use way too much registration relying on matching textual IDs; This is a "boilerplaty" approach, we can do better ///////////////////////TICKET #1405 : all this registration with matching IDs is way too much "boilerplaty"

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

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

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.

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. Relevance not clear yet...

File allocation.hpp

result of the very first code generation from UML in 2008. Relevance not clear yet...

Member Allocation::intersect (LocatingSolution &) const

probably a placeholder and to be pushed down....

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

5/2024 to be reworked and aligned with a prospective C++20 Allocator Concept /////////////////////TICKET #1366

File alsa.h

for now this header defines some functions used for experimentation with ALSA

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. Relevance not clear yet...

File auto.hpp

result of the very first code generation from UML in 2008. Relevance not clear yet...

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 BindToArgument< SIG, X, pos >

6/2025 while this was added later to handle a special case, now after clean-up (see #987) this seems to be the much cleaner implementation approach and can easily be generalised to cover all the general features available through PApply; it would be sufficient to replace the single template parameter X by a type-sequence of the values to bind. All use cases of partial application could be modelled this way... //////////////////////////////////////////////TICKET #1394

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

File buffer-proxy-provider.hpp

BROKEN as of 12/2024 //////////////////////////////////////////////////////////////////////////////TICKET #1387 : can not properly compose BufferProvider

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

Member BufferProvider::lockBuffer (BuffDescr const &)

2/2025 might need to accept a cache key as additional parameter //////////////////////////////////TICKET #1392 : get cache key from computation to the cache backend

Class BufferProxyProvider

WIP-WIP 12/2024 this is a design sketch to explore extension capabilities of BufferProvider

Struct 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

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"

Struct 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

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.

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. It should be a smart pointer of some kind and the unlink() function of the asset should take it into account when breaking circular references.

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...

Struct 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.

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

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

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.

File conmanager.cpp

initially generated code of unclear relevance

File conmanager.hpp

initially generated code of unclear relevance

Member ConManager::getConnection ()

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

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

Class Connectivity

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 Connectivity descriptor, telling how it's connected to its predecessors, and defining how the Node is supposed to operate

WIP-WIP-WIP 2024 Node-Invocation is reworked from ground up for the »Playback Vertical Slice«

File constraint.cpp

result of the very first code generation from UML in 2008. Relevance not clear yet...

File constraint.hpp

result of the very first code generation from UML in 2008. Relevance not clear yet...

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...

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??

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 demo-controller.cpp

5/2025 now used for a research project for XV video display ////////////////////////////////////TICKET #1403 : attempt to upgrade the XV displayer

File demo-controller.hpp

as a temporary solution, 1/2017 the playback controller was moved into the viewer panel. Of course it can not work that way....

5/2025 now used for a research project for XV video display ////////////////////////////////////TICKET #1403 : attempt to upgrade the XV displayer

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

File displayer.cpp

as of 2016 it is not clear, if this code will be evolved into the actual display facility, or be replaced and rewritten, when we're about to create a functional video display connected to the render engine.

5/2025 used in an experiment for video output

Member Displayer::format ()

this feature was seemingly never used... can it be relevant? can we handle different formats?

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 dropframe.hpp

2025 this header provides some calculation functions to implement such a mapping scheme (thereby documenting the know-how). But the project never got to the point of integrating this functionality into an actual timecode implementation. Doing so will be future work. ///////////////////////////////////////////////////TICKET #751

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

revived in 2025 for research of video output techniques; this is test code.

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...

Member Effect::getProcAsset () const

: clarify asset->mobject relation and asset dependencies; /////////////////////////////////////////TICKET #255

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-ctx-facilities.hpp

and we'll have yet to »figure out« what specifically to do for these services and how to start an active render engine for productive use.

WIP-WIP 10/2024 strive at first complete prototypical engine usage ////////////////////////////////////////TICKET #1367

File engine-ctx.hpp

who is responsible for setup of the services for the actual render engine? Might be closely related to brining up façade interfaces.

WIP-WIP 2/2025 provide actual service implementation and find a way how to populate the Facilities with these actual services...

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.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.

Struct 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.

Struct 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. The real thing is not yet implemented.

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...

6/2025 basically everything here is unused or will likely be done in a different way — expect this and rendergraph.cpp to be obsolete

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

2/25 note that there is a bind_front in C++20 and C++23 will provide a bind_back helper, which would provide the implementation fully in accordance with current expectations (including move, constexpr); if we choose to retain a generic function-style front-end, it should be aligned with these standard facilities. We might want to retain a simple generic interface especially for binding some selected argument, which handles the intricacies of storing the functor.

6/25 note however that the full-fledged partial function application is a relevant core feature and is used in the NodeBuilder (see tuple-closure.hpp). Further improvement of the implementation is thus mandated... ////////////////////////////////////TICKET #1394

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. It should be a smart pointer of some kind and the unlink() function of the asset should take it into account when breaking circular references.

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. In the meantime, we use some hard wired mappings to actual InteractionState implementations

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-combine.hpp

2024 the Lumiera project has yet to decide how to approach portability of hash values, and the related performance issues. This code was directly integrated into the code base to ensure a stable implementation and reproducible hash values. ///////////////////////////////////////////////////////////////////////////////////////////////////TICKET #722 uniform uses of hash values

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 hash-value.h

11/2024 : to ensure a strong and reproducible implementation of hash-chaining, the implementation of LibBoost is used directly. This breaks portability. ///////////////////////////////////////////////////////////////////////////////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

File hetero-data.hpp

WIP-WIP this is the draft of a design sketch regarding the render node network, which seems to be still pretty much in flux as of 12/2024

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

File interaction-state.cpp

do we really need a separate implementation unit for this??

File interaction-state.hpp

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.

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

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

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...

Union 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.....

describe this pattern in more detail....

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

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. Relevance not clear yet...

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....

{random.cpp} 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

{entry-id.hpp} 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::meta::apply (FUN &&f, TUP &&tup) noexcept(can_nothrow_invoke_tup< FUN, TUP >)

6/2025 as a first step, this replicates the implementation from C++17; the second step would be to constrain this to a concept tuple_like

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. Anyone...?

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)

{time.cpp} Member lib::time::anonymous_namespace{time.cpp}::build_time_from (FSecs const &fractionalSeconds)

2022 this utility function could be factored out into a FSecs or RSec class /////////////////TICKET #1262

Member lib::time::calculate_ntsc_drop_frame_number (raw_time_64 time)

2011 I doubt this works correct for negative times!!

Member lib::time::getDefaultGridFallback ()

placeholder for accessing a current or default session grid. To be implemented later.

Member lib::time::raw_time_64

2025 a mere type alias is up to debate – very likely we'll use a wrapper soon /////////////////TICKET #1258

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. This seemed like a good idea at that time, but we should re-evaluate if libGAVL is maintained and in actual use, before we start really relying on it.

2025 this code is a kind of architecture placeholder — it is clear that a solution can can not be that simple, but any viable solution will rely onto an approach like outlined here: provide a façade interface, which has to be implemented by any plug-in component to provide access to the processing capabilities of a specific library. The access point functions exposed on the facade however must be shaped by the specific way how the builder and the render engine interacts with and delegates back to the media-handling library. Such an interface can not be based on first principles alone.

2025 I still retain the dependency on lib-GAVL for now, even while we never got into actually using it. Simply because I still consider this library exemplary, and would love to use it for real. Yet it remains to be seen if the project actually gets a chance to do so, simply because FFmpeg roughly covers the same ground. Presumably it turns out to be a basic requirement to ship a plug-in with FFmpeg binding. Furthermore, one especially tricky aspect is how to support displays with extended dynamic range – a requirement which has the potential to blur the notion of »raw video«...

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.

Struct 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.

Struct 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_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. Handlers do not need to obey the request and shall return LUMIERA_RESOURCE_NONE which will then continue with the next handler. This goes through all available handlers until one returns a higher or same value than the current iteration to indicate that it freed enough resources to continue the task. Then control is passed back to the calling loop which retries the resource allocation. LUMIERA_RESOURCE_PANIC is somewhat special since it will always call all registered handlers for all resources, not only the queried one and finally _exit() the application. The exact amounts of resources to be freed for ONE, SOME and MANY in intentionally kept vague the handlers are free to interpret this in some sensible way.

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 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

2023 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. Relevance not clear yet...

File mobject/session/effect.hpp

result of the very first code generation from UML in 2008. Relevance not clear yet...

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 Connectivity 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 multifact.hpp

2025 ...and still not fully convinced this is the way to go; admittedly we did not get to a point yet where fabricating lots of elements poses any kind of challenge — up to now a dedicated factory function within a service was enough to handle this task. Yet this may change, once we have stream types, various kinds of assets (notably effects and processors) and lots of queries.

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

Struct 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-builder.hpp

WIP-WIP 1/2025 Node-Invocation is reworked from ground up – some parts can not be spelled out completely yet, since we have to build this tightly interlocked system of code moving bottom up, and then filling in further details later working top-down.

as of 1/2025, the Layer-3 builder seems to be beyond the current integration scope. //////////////TICKET #1389 : develop a processing builder

File node-factory.cpp

draft from the early days of the Lumiera project, reworked in 2009 Development activity in that area as stalled ever since. In the end, it is highly likely we'll indeed need a node factory though...

WIP-WIP 2024 to be reworked from ground up for the »Playback Vertical Slice«

File node-factory.hpp

draft from the early days of the Lumiera project, reworked in 2009 Development activity in that area as stalled ever since. In the end, it is highly likely we'll indeed need a node factory though...

about to be reworked for the »Playback Vertical Slice« in 2024

File node-graph-attachment.hpp

2023 WIP-WIP-WIP »Playback Vertical Slice« need at least a drafted model

File node-storage-test.cpp

12/2024 this test will focus on the high-level integration, which is future work and possibly addressed in the next »Vertical Slice« when we add processing of a given media clip from disk.

Member NodeBuilder_test::build_connectedNodes ()

12/24 ✔ define ⟶ ✔ implement

Member NodeBuilder_test::build_Node_adaptedParam ()

2/25 ✔ define ⟶ ✔ implement

Member NodeBuilder_test::build_Node_dynamicParam ()

12/24 ✔ define ⟶ ✔ implement

Member NodeBuilder_test::build_Node_fixedParam ()

12/24 ✔ define ⟶ ✔ implement

Member NodeBuilder_test::build_ParamNode ()

12/24 ✔ define ⟶ ✔ implement

Member NodeBuilder_test::build_simpleNode ()

12/24 ✔ define ⟶ ✔ implement

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

Class NodeFeed_test

2/2025 unfinished – add cases to cover media data feeds

Class NodeGraphAttachment

WIP-WIP as of 4/2023 – starting with a fake implementation /////////////////////TICKET #1306 : create an actual link to the low-level Model

Struct 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.

5/2025 meanwhile a new effort to define the processing nodes was successful, but it is still not clear if the »Render Nodes« will expose any runtime logic beyond the mere ability to be invoked. ** This is a placeholder** — we are using ProcID instead

Member NodeLink_test::build_connected_nodes ()

1/25 ✔ define ⟶ ✔ implement

Member NodeLink_test::build_simple_node ()

7/24 ✔ define ⟶ ✔ implement

Member NodeLink_test::trigger_node_port_invocation ()

2/25 ✔ define ⟶ ✔ implement

Class NodeMeta_test

2/2025 hash computation is not yet specified...

Member NodeMeta_test::verify_ID_connectivity ()

2/25 🔁 define ⟶ ✔ implement

Member NodeMeta_test::verify_ID_specification ()

1/25 ✔ define ⟶ ✔ implement

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-displayer.hpp

WIP as of 5/2025 attempt to accommodate to GTK-3 ////////////////////////////////////////////////TICKET #1403

WIP as of 5/2025 attempt to accommodate to GTK-3 ////////////////////////////////////////////////TICKET #1403

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 NullDisplayer

WIP as of 5/2025 attempt to accommodate to GTK-3 /////////////////////////////////////////////////TICKET #1403

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

confirmed 12/2024 : the ideas drafted here are considered relevant, yet it is clear meanwhile that the Build will work on meta-descriptors, and not the actual Render Nodes

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

Class OutputProxyProvider_test

WIP-WIP 12/2024 this turned out to be impossible, due to inconsistencies in the default implementation. /////////////////////////////////////////////TICKET #1387 : need to consolidate BufferProvider default implementation

File panel-bar.hpp

still not completely ported to GTK-3 and not used as of 5/2025 /////////////////////////////////TICKET #937 : complete Port to GTK-3

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 PanelBar::setupPanelButton ()

still not completely ported to GTK-3 and not used as of 5/2025 /////////////////////////////////TICKET #937 : complete Port to GTK-3

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 >

6/2025 while this is the core of this feature, the implementation is still confusing and bears traces from being the first attempt at solving this problem, with a pre-C++11 feature set. Driven by other requirements, over time several variations were added, so that now the main functionality is now implemented twice, in a very similar way in BindToArgument. Actually, the latter seems much clearer, and possibly PApply could be rewritten into a front-end and delegate to BindToArgument... ////////////////////////////////////TICKET #1394

Member PApply< SIG, VAL >::bindFront (SIG const &f, Tuple< ValTypes > arg)

2/2025 However, the LeftReplacedArgs could then possibly moved into the bind function, as could the functor, once we replace the Apply-template by STDLIB features.

5/2025 seems indeed we could perfect-forward everything into the binder object.

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

File pixbuf-displayer.cpp

WIP as of 5/2025 attempt to accommodate to GTK-3 ////////////////////////////////////////////////TICKET #1403

File pixbuf-displayer.hpp

WIP as of 5/2025 attempt to accommodate to GTK-3 ////////////////////////////////////////////////TICKET #1403

Class PixbufDisplayer

WIP as of 5/2025 attempt to accommodate to GTK-3 /////////////////////////////////////////////////TICKET #1403

Struct PixSpan

quick-n-dirty hack. Should consider the Range TS (C++20)

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 Placement< MObject, MObject >::operator= (Placement const &)=default

2025-4 what is the semantics of such an assignment? Shouldn't placement be treated with reference semantics? //////////////////////////////////TICKET #123 : (from 2009) "Find out about the correct meaning when assigning placements...."

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

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)

WIP-WIP-WIP 6/2011

File play-facade.hpp

in theory this could be an external interface mapped via Lumiera's interface system. This would be much work however, and not serve any tangible goal in the current stage of development (2018). I take this as just another confirmation that turning everything into a plug-in does not quality as good architecture: if you want to do it right, it creates a lot of additional cost. And to do it just superficially would be like cheating.

File play-panel.cpp

5/2025 This is an experiment or demo to find out if our XV-Widget is still usable. The actual solution obviously should not use a direct wired connection to the ViewerPanel, but rather communicate with the »Player« subsystem down in Steam-Layer ///////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1403 : try to port XvDisplayer to GTK-3

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 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!

Struct PlayTestFrames_Strategy

placeholder as of 6/23

File plug.cpp

result of the very first code generation from UML in 2008. Relevance not clear yet...

File plug.hpp

result of the very first code generation from UML in 2008. Relevance not clear yet...

Struct PNode

placeholder introduced 12/2024 to abstract from the actual Render Nodes

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

File proc-id.hpp

Can we assume size_t == 64bit; is this enough to prevent collisions? Can we afford using a 128bit hash? What about portability of hash values?

WIP-WIP as of 10/2024 this is a draft created as an aside while working towards the first integration of render engine functionality //////////////////////////////////////////////TICKET #1377 : establish a systematic processing identification

File proc-node.hpp

WIP 2/2025 Node-Invocation is reworked from ground up for the »Playback Vertical Slice«

Struct ProcAttrib

if this grows beyond size_t, it should be deduplicated and stored in a registry, similar to the string spec. Storage matters!

Member ProcFactory::operator() (Asset::Ident &key)

actually define

Class ProcNode

WIP 2025 Node-Invocation is reworked from ground up for the »Playback Vertical Slice«

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.

Class RelativeCanvasHook< WID >

investigate real-live performance ////////////////////////////////////////////////////////////////TICKET #1254 : investigate impact of indirection

Class RelativeLocation

just a design sketch, nothing finished yet. possibly to be reworked or phased out completely. See Trac #100

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

WIP-WIP-WIP 12/2024 about to build a Render Node invocation, combining the old unfinished draft from 2009 with the new Render Engine code

File render-invocation.hpp

WIP-WIP-WIP 2024-12 finally about to connect the unfinished draft from 2009 with the engine structures built bottom-up meanwhile ///////////////////////////////////////////TICKET #905 : Work out what parameters are required to invoke the real code available now....

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 RenderGraph

likely to be reworked into the engine backbone /////////////TODO WIP as of 12/2010

File rendergraph.hpp

5/2025 the »Playback Vertical Slice« was not yet helpful to clarify how the top-level of the low-level-model will be organised. Some considerations were made regarding ExitNode, but nothing implemented yet. Might become relevant for the next »Vertical Slice«, where we want to add a clip and then actually invoke a real Builder implementation. Future work!

Class RenderInvocation

write type comment

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

• largely completed spring 2024
• passes stress testing with good performance
• TODO further integration will require to extract a Scheduler-Interface

File scheduler-frontend.hpp

WIP unfinished since 9/2013

File scheduler.hpp

WIP 11/2024 »Playback Vertical Slice«

• initial version of Scheduler was built and validated by scheduler-stress-test.cpp
• now awaiting integration with Render-Node invocation and Job-Planning
• very likely we'll extract a Scheduler-Interface (and this file then becomes a service-impl)

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

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

Struct ScriptRunnerFacade

build a suitable binding interface and a 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!

File several-builder.hpp

this is a first implementation solution from 6/2025 — and was deemed roughly adequate at that time, yet should be revalidated once more observations pertaining real-world usage are available...

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 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.

{zoom-window.hpp} 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

{zoom-window.hpp} Member stage::model::anonymous_namespace{zoom-window.hpp}::isMicroGridAligned (FSecs duration)

should likewise be member of a FSecs wrapper type...

{zoom-window.hpp} 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)

{stave-bracket-widget.cpp} 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

{element-box-widget.cpp} 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

{error-log-display.hpp} Member stage::widget::anonymous_namespace{error-log-display.hpp}::populateStandardTextTags (Glib::RefPtr< Gtk::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 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

{config-resolver.cpp} 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

{clip.cpp} 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...

{preview.cpp} 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_markNote)

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_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_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_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_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_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_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_meta_activateContentDiff)

used for preliminary integration testing ///////////////////////////////////////////TICKET #211 prefix test_ bypasses logging and immediately executes for now (2018)

{looper.hpp} Member steam::control::anonymous_namespace{looper.hpp}::STEAM_DISPATCHER_BUILDER_DELAY_ms

this value should be retrieved from configuration ////////////////////////////////TICKET #1052 : access application configuration

{looper.hpp} Member steam::control::anonymous_namespace{looper.hpp}::STEAM_DISPATCHER_BUSY_SLOWDOWN_FACTOR

this value should be retrieved from configuration ////////////////////////////////TICKET #1052 : access application configuration

{dispatcher-looper-test.cpp} 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. See Ticket #115

Struct 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 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

Member Suite::describe ()

this function war rarely used and is kind of broken by the fact that Nobug-assertions terminate the program instead of throwing, rendering the feature to integrate output mostly useless.

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-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. But it still seems like a good idea (as of 2016), while likely the implementation will be completely different, based on JSON to be injected via the diff system

File time-quantisation-test.cpp

2024/24 only two of the four timecode formats are implemented /////////////////////////////////////TICKET #736 : HMS and Seconds not implemented

File timecode-widget.cpp

2025 this code is here for later referral, but currently not used; a complete re-engineering is required to bring this code to current standards

• magic constants all over the place
• hard coded wiring instead of using an adapter layer
• way to much pointer usage and pointer magic
• direct handling of low-level keyboard events
• repetitive code with switch-case fan

File timecode-widget.hpp

2016 needs extensive rework to get smooth integration with Lumiera's timecode handling functions

2023 this widget was used in the first GTK-2 based UI. While it still works with GTK-3, there are various fine points which you wouldn't do this way in a modern GTK UI, like directly checking for keyboard modifiers, or processing any kind of formatting directly in a event handler, instead of building a set of error-safe formatting helpers.

2025 ...rather we should invest in generic sub-widgets, and try to build some generic pattern how to work with numeric values with high precision (e.g. interactive nudging and spinning with a gear switch). Bottom line: this code is currently unused and should be re-engineered.

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.

2016 can confirm that we still want to go that route

we need some actual interface, beyond just creating timelines!

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

as of 03/2023 the backbone of the new structure is in place (see #1042)

as of 05/2025 we need actual editing functionality in the core to continue building here.... //////TICKET #305

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

2025 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

2025 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

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 ()

2023 / 2025 the remainder of the old GTK-2 Timeline UI was removed.

2025 much is broken and unclear on a design level here... 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 manage 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 )

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 ()

2025 unclear what to do and to return here ///////////////////////////////////////////////TICKET #1367 : 5/25 left in tree for now; purpose unclear, maybe relevant for the next »Vertical Slice« ?

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...

Struct 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 turnout-system.cpp

unfinished draft from 2009 regarding the render process

File turnout-system.hpp

WIP-WIP-WIP 12/2024 now combining the draft from 2009 / 2012 with recent engine development

File typed-allocation-manager.hpp

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

WIP WIP.

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. For now (as of 2016), efforts towards this important goal have been postponed, because we have to focus on a working engine first

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 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 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. And a fun fact is, even while Lumiera is a video editing application, we did not yet reach the state as to care for video display ourselves. Someone (TM) need to care for this!

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

File weaving-pattern-builder.hpp

WIP-WIP-WIP as of 10/2024 prototyping how to build and invoke render nodes /////////////////////////TICKET #1371

Struct WeavingBuilder< POL, PROT >

2/2025 nothing is implemented yet for specific buffer / type config. All type slots are filled with the default provider from EngineCtx.

Class Widget

write type comment...

File widget.hpp

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

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. Relevance not clear yet...

File wish.hpp

result of the very first code generation from UML in 2008. Relevance not clear yet...

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

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

The infrastructure for context sensitive help needs to be defined

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-function-result.hpp

2025 initially created by direct need, it was used for a while, but became largely obsoleted by the ''transforming'' functionality provided by iter-explorer.hpp (which is implemented by the same basic technique, but without the std::function baseclass).

File xv-displayer.hpp

WIP as of 5/2025 – attempt to port this component to GTK-3 ///////////////////////////////////////TICKET #1403

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