Lumiera  0.pre.03
»edityourfreedom«
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Modules Pages
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...
Member AbstractTangible_test::markState ()
maybe we'll even provide a default implementation for expand/collapse which then means that, by replaying the mentioned state marks, the doExpand() or doCollapse() should be re-invoked, of course without issuing a further notification
Note
this test does not cover or even emulate the operation of the "state manager", since the goal is to cover the UI element protocol. We'll just listen at the bus and replay messages.
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.
See also
lumiera::WrapperPtr usage example to access a variant record
lib::InPlaceAnyHolder usage example to access a subclass in embedded storage
File actions.hpp
the old Gtk::Action and Gtk::ActionGroup are planned to be deprecated. Recommendation is to rely on Gtk::Builder and Gtk::SimpleAction instead. As of 5/2017, it is not clear to what extent this might force us into additional "desktop integration" we do not need nor want (like automatically connecting to D-Bus). For that reason, we'll postpone this transition for the time being /////////////////////TICKET #1068
Member Actions::populateShowPanelActions (Gtk::UIManager &uiManager)
4/2017 this can only be a preliminary solution. What we actually want is perspectives, and we want a specific UI to be anchored somewhere in UI space, so we'll be rather be navigating towards it, instead of "showing it here".
Member Actions::updateActionState (workspace::WorkspaceWindow &currentWindow)
as of 2017, the relation of panels to top level windows is unclear and likely needs to be replaced by a focus + perspective concept (–> see topic "Interaction Control")
File advice.cpp

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

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

File advice.hpp

allow variables in binding patterns

use the lumiera MPool instead of heap allocations

consider to provide variations of the basic behaviour by policy classes

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

Class AdviceBindingPattern_test
partially unimplemented and thus commented out ////////////////////TICKET #605
Member AdviceBindingPattern_test::verifyDynamicMatch ()
this is a future extension and its not clear if we need it and what the exact semantics could be ///////////////////////////////TICKET #615
Class AdviceConfiguration_test
partially unimplemented and thus commented out ////////////////////TICKET #605
Class AdviceMultiplicity_test
advanced topic, deferred for now (4/10) ////////////////////TICKET #610
Class AdviceSituations_test
partially unimplemented and thus commented out ////////////////////TICKET #335
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....
Class AllocationCluster

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

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

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

Class AllocationCluster::MemoryManager
this is a preliminary or pseudo-implementation based on a vector of raw pointers, i.e. actually the objects are heap allocated. What actually should happen is for the MemoryManager to allocate raw memory chunk wise, sub partition it and place the objects into this private memory buffer. Further, possibly we could maintain a pool of raw memory chunks used by all MemoryManager instances. I am skipping those details for now (10/2008) because they should be based on real-world measurements, not guessing.
File alsa.h
for now this header defines some functions used for experimentation with ALSA
File assembler.cpp
initially generated code of unclear relevance
File assembler.hpp
initially generated code of unclear relevance
File asset-controller.cpp
WIP 2/2017 early draft / foundations of "interaction control"
File asset-controller.hpp
WIP 2/2017 early draft / a new UI backbone
File asset/effect.cpp
still unimplemented and stalled work as of 2016
Class AssetController
initial draft as of 2/2017 – actual implementation has to be filled in
File assetmanager.hpp

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

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

Member AssetManager::clear ()
verify this actually works, especially with session shutdown ////////////////////////////TICKET #154
File auto.cpp
result of the very first code generation from UML in 2008. Relevance not clear yet...
File auto.hpp
result of the very first code generation from UML in 2008. Relevance not clear yet...
File bin-widget.cpp
WIP-WIP-WIP as of 12/2016
File bin-widget.hpp
WIP-WIP-WIP as of 12/2016 we have only very vague preliminary plans regarding the asset management section; also the asset management within the session subsystem will be rewritten to fit our increased understanding of the editing process. So for now, this widget is a mere placeholder in a largely preliminary UI (need more weasel words?)
Class BinWidget
WIP-WIP as of 12/2016
File body-canvas-widget.cpp
WIP-WIP-WIP as of 12/2016
File body-canvas-widget.hpp
WIP-WIP-WIP as of 12/2016
Class BodyCanvasWidget
WIP-WIP as of 12/2016
Class BufferProvider

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

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

Class BuffTable

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

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

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

stalled effort towards a session implementation from 2010

2016 likely to stay, but expect some extensive rework

File bus-mo.hpp

stalled effort towards a session implementation from 2010

2016 likely to stay, but expect some extensive rework

Class CairoUtil
this is not a real entity; consider to turn this into a set of free functions!
File calc-plan-continuation.cpp
a draft created in 2013 and then stalled. This is not obsolete.
File calc-plan-continuation.hpp
a draft created in 2013 and then stalled. This is not obsolete.
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 CalcPlanContinuation
5/13 still WIP – write type comment
Member CalcPlanContinuation::CalcPlanContinuation (play::Timings const &timings, Dispatcher &dispatcher, ModelPort modelPort, uint channel)
Class CalcStream_test
WIP-WIP-WIP
File call-queue.hpp
simplistic braindead implementation with locking and heap based storage based on std::function; should use a lock-fee queue and should have an eye on the impact of managing argument storage
Class Category
could be far more elaborate. could be a singleton like centralised tree, while just holding references to Category nodes in the individual Asset. At the moment, we just use the most simplistic implementation and handle Category objects using value semantics.
Member Category::operator string () const
to be localized.
File channel-descriptor.hpp
as it stands (11/2011) this file is obsoleted and needs to be refactored, alongside with adapting the node invocation to the new BufferProvider interface.
Class 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.cpp
WIP-WIP-WIP as of 12/2016
File clip-presenter.hpp
WIP-WIP-WIP as of 12/2016
File clip-widget.cpp
WIP-WIP-WIP as of 12/2016
File clip-widget.hpp
WIP-WIP-WIP as of 12/2016
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 ClipPresenter
WIP-WIP as of 12/2016
Class ClipWidget
WIP-WIP as of 12/2016
File cmd-context.hpp
as of 3/2017 this is a early design draft and WIP-WIP-WIP
File cmd.hpp
WIP 3/2017 early draft
Class CmdContext
write type comment...
Member CmdContext::~CmdContext ()
do we need a VTable / virtual dtor?
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 Command::get (FuncPtr func)
this is a "nice-to-have"; it would allow to call a function as a command, almost as if it was a normal function. But this function needs to be defined as a command previously, together with a suitable UNDO function. Moreover this would probably require to build an additional index; thus this feature is unimplemented for the time being.
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 config-facade.h
there ought to be an external Interface for the Config subsystem. But the full-blown Config system isn't implemented yet anyway
File config-interface.c
as of 2016 this code is unused and likely to be replaced by a different approach.
File config-interface.h
as of 2016, the code is still there in same unfinished shape and basically unused
File config-lookup.c
as of 2016 this code is unused and likely to be replaced by a different approach.
File config-lookup.h
as of 2016, the code is still there but remains mostly unused
File config-resolver.cpp
draft from the early design phase of the Lumiera application. As of 2016, nothing was done on behalf of rules-based configuration, other then preparing the whole architecture for this capability. So this remains one of the most relevant goals of the Project.
File config-resolver.hpp
clarify the relation of config query and query-for-defaults ///////////////TICKET #705
File config-rules.cpp
placeholder and mostly not implemented as of 11/2016
File config-rules.hpp

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

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

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

File config-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 (gtk-lumiera.css is the default)
File configitem.c
as of 2016 this code is unused and likely to be replaced by a different approach.
File configitem.h
as of 2016 this code is unused and likely to be replaced by a different approach.
Class ConfigSelector< Factory, FUNC, PAR >
as the factories live only within the enclosed table (map) we could allocate them in-place. Unfortunately this is non-trivial, because the STL containers employ value semantics and thus do a copy even on insert. Thus, for now we use a shared_ptr to hold the factory heap allocated. —> see Ticket #248
File conmanager.cpp
initially generated code of unclear relevance
File conmanager.hpp
initially generated code of unclear relevance
Member ConManager::getConnection ()

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

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

File constraint.cpp
result of the very first code generation from UML in 2008. 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...
Class Controller
needs to be reshaped for communication with Proc-Layer /////////////////TICKET #959
File controller.hpp
as of 1/2015 this is complete WIP-WIP-WIP
File controllerfacade.hpp
as of 2016 it very much looks like there wont'be any such thing...
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-gui-roundtrip.cpp
WIP as of 8/20176 ////////////////////////////////////////////////////////////////////////TICKET #1099
Class DemoGuiRoundtrip

be commendable

don't misbehave

Class Depend< SI >
as of 2016, the design could still be improved //////////////////////////////////////////TICKET #1086
Parameters
SIthe class of the Singleton instance
File diagnostic-buffer-provider.cpp
WIP from 2013, half finished, stalled
See also
buffer-provider-protocol-test.cpp
File diagnostic-context.hpp
add the actual diagnostic content
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.
File diff-message.hpp
as of 1/2017 this is placeholder code and we need a concept //////////////////////////////////////////TICKET #1066 : how to pass diff messages
Class DiffMessage
placeholder
Class DigxelConfigurations_test
cover any newly added Digxel configurations.
See also
Digxel_test
File dispatch-table.cpp
draft from 2011, stalled, relevance not yet clear
File dispatch-table.hpp
draft from 2011, stalled, relevance not yet clear
Class Dispatcher
10/12 still WIP, but conceptually settled by now
File dispatcher.cpp
valid draft, unfortunately stalled in 2013
File dispatcher.hpp
valid draft, unfortunately stalled in 2013
Member Dispatcher::JobBuilder::relativeFrameLocation (TimeAnchor &refPoint, FrameCnt frameCountOffset=0)
WIP
Member Dispatcher::onCalcStream (ModelPort modelPort, uint channel)
WIP
Class DispatchTable
11/11 extremely fuzzy at the moment
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
See also
gui::controller::PlaybackController
proc::play::DummyPlayerService
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 12/2016 ///////////////////////TICKET #1042
File dummy-session-connection.hpp
WIP as of 12/2016 //////////////////////////////////////////////////////////////////////TICKET #1042
Class DummyPlayConnection< DEF >
not-yet-implemented as of 2016 – but the design can be considered valid.
File element-query.hpp

WIP implementation of session core from 2010

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

File element.hpp
WIP ///////////////////////TICKET #959
File engine-service-mock.cpp
draft from 2012, and, while stalled, still relevant as of 2016
File engine-service-mock.hpp
1/2012 until the real render engine is usable, this mock implementation will stand-in, allowing us to develop the other parts of the play/render subsystem.
File engine-service.hpp
draft from 2013, stalled, but still relevant and to be continued eventually
See also
EngineInterface_test
CalcStream_test
proc::play::PlayerService
backend::engine::EngineConfig
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
See also
main.cpp
Class EntryID< TY >
currently storing the symbolic-ID as string. It should be a lib::Symbol, but this isn't possible unless we use a symbol table. //////TICKET #158
Warning
there is a weakness in boost::hash applied to strings. EntryID by default generates symbolic IDs from a type prefix plus a running number, which causes collisions already with less than 100000 entries.
As a temporary workaround, we hash the symbolic ID twice, but we should look into using a better hash function ////////////TICKET #865
Class ExecResult
couldn't that be replaced by a lib::Result<void> instance??
Class Facade

this is a dummy placeholder as of 1/2009. Currently, there is only implementation-level code within the Proc-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 filedescriptor.c
development in this area is stalled since 2010
File filedescriptorregistry.c
development in this area is stalled since 2010
File filehandle.c
development in this area is stalled since 2010
File filehandlecache.c
development in this area is stalled since 2010
File fileheader.c
development in this area is stalled since 2010
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.
See also
http://lumiera.org/wiki/renderengine.html#Fixture
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 FrameCoord
1/12 WIP-WIP-WIP defining the invocation sequence and render jobs
Class FrameID
currently (7/08) this is a dummy implementation to find out what interface the Proc layer needs. Probably the backend will later on define what is actually needed; this header should then be replaced by a combined C/C++ header
File frameid.hpp
2016 the intention was to use this as cache key, and to include some information regarding the processing chain which led up to the calculation of this frame, to allow for intelligent caching and to avoid throwing away most of the frames on each and every tweak of the edit. This marker was added as a preview in 2010 but we didn't get to the point of actually putting that idea into practical use. Yet the basic idea remains desirable...
File function-closure.hpp
the implementation is able to handle partial application with N arguments, but currently we need just one argument, thus only this case was wrapped up into a convenient functions func::applyFirst and func::applyLast
File function.hpp
get rid of the repetitive specialisations and use variadic templates to represent the arguments /////////////////////////////////TICKET #994
File functor-util.hpp
combine with meta/function-closure.hpp and reorganise
Class GdkDisplayer
the GdkDisplayer class is not supported anymore in Gtk3. This is due to Gtk3 only supporting drawing with Cairo /////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #950 : new solution for video display
File 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

See also
GenericIdFunction_test
EntryID
Class Grid

WIP-WIP-WIP

maybe abstract this from Time altogether?

File gui/model/diagnostics.hpp
WIP ///////////////////////TICKET #
File gui/model/sequence.hpp
Currently (1/2014) this is a dummy placeholder, intention is to connect GUI-Model entities to the Session model eventually.
Namespace gui::model

: as of 1/2011 this connection between the GUI proxy model and the Proc-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 Proc-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.

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) ProcDispatcher is missing.

Class HandlingPatternStandardImpl_test
define and code those handling patterns; Ticket #210
File hash-standard.hpp
4/2014 doesn't work as expected. My suspicion is that in the actual use case (PlacementIndex), the type providing the hasher is mixed in through inheritance, and the template specialisation for this base type is not considered on lookup. ///////TICKET #722
File header-pane-widget.cpp
WIP-WIP-WIP as of 12/2016
File header-pane-widget.hpp
WIP-WIP-WIP as of 12/2016
Class HeaderPaneWidget
WIP-WIP as of 12/2016
Class HelloBug_test
come up with some more bugs
Member Holder< TYPES >::access (Buffer &buf)
shouldn't this rather be located within the Holder::Storage created by clients??
Member IdentityOfAssets_test::createDuplicate ()
this test is expected to break when the detection of duplicate registrations is implemented.
Class ImplFacadeGAVL
2016 evaluate if libGAVL is still active and maintained
Class InPlaceAnyHolder< siz, AccessPolicy >
add support for moving of rvalue refs
Class Instantiation< _CandidateTemplate_ >

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

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

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

File interaction-state.hpp
as of 11/2015 this is complete WIP-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...
Class Inventory
WIP-WIP unimplemented
File inventory.hpp
implementation draft from 2010, stalled as of 2016, but likely to be of relevance eventually...
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 IterSource_test
the output order of the values produced by this test is implementation dependent in for the hashmap case
File itertools.hpp
some more building blocks are planned, see Ticket #347
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
See also
Job
Member JobFailureReason
find out about the possible kinds of failure
Class JobTicket
1/12 WIP-WIP-WIP defining the invocation sequence and render jobs
Class Label

Placeholder code for now.

planning to provide some kind of dynamic properties (map)

File label-widget.cpp
WIP-WIP-WIP as of 12/2016
File label-widget.hpp
WIP-WIP-WIP as of 12/2016
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 LabelWidget
WIP-WIP as of 12/2016
File layout-manager.cpp
WIP-WIP-WIP as of 12/2016
File layout-manager.hpp
WIP-WIP-WIP as of 12/2016
Class LayoutManager
WIP-WIP as of 12/2016
Member lib::diff::mutateInPlace (Record< VAL > &record_to_mutate)
do we have a design mismatch here?? /////////////////////////////////////////TICKET #970
See also
tree-diff-application.hpp
Member lib::idi::generateSymbolicID ()
consequently the generated IDs might clash for two distinct types, which generate the same namePrefix(). Is this a problem?
Warning
this operation is not exactly cheap; it acquires a lock for the counter and, after increasing and dropping the lock, it builds and uses a boost::format instance.
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::getDefaultGridFallback ()
placeholder for accessing a current or default session grid. To be implemented later.
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
Member LibGavl::getImplFacade (TypeTag &)

fill in the actual GAVL frame type

how to distinguish the audio and the video case?

File locatingpin.cpp

stalled effort towards a session implementation from 2008

2016 likely to stay, but expect some extensive rework

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

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

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

Member LocatingPin::resolve () const

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

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

File logging.h
logging to files? `NOBUG_LOG='progress:INFO
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 *exception_obj)
to be localised
Member lumiera::WrapperPtr
really need to switch to the new lib::Variant and util::AccessCasted implementation ////////////////TICKET #450
Member lumiera_filedescriptorregistry_init (void)
proper backend/subsystem failure
Member lumiera_job_failure (LumieraJobDefinition, JobFailureReason)
decide what and how to communicate details of the failure
Remarks
the purpose of this function is to allow for reliable checkpoints within the network of dependent job invocations, even after missing deadlines or aborting a sequence of jobs
Member lumiera_job_failure (LumieraJobDefinition, JobFailureReason)
decide what and how to communicate details of the failure
Remarks
the purpose of this function is to allow for reliable checkpoints within the network of dependent job invocations, even after missing deadlines or aborting a sequence of jobs
Member LUMIERA_THREAD_OR_NOT
explain synchronisation issues
File marker-widget.cpp
WIP-WIP-WIP as of 12/2016
File marker-widget.hpp
WIP-WIP-WIP as of 12/2016
Class MarkerWidget
WIP-WIP as of 12/2016
File mask.hpp
this file is there since the very first code generation steps at start of the Lumiera project. It never became clear if a mask generator would need to be a dedicated ProcNode subclass; but in fact the project did not reach the point of implementing anything regarding that topic.
File maybe.hpp
WIP and rather brainstorming as of 2/10
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.hpp
this facility was occasionally used until 2011, yet never really completed
Member MediaAccessFacade::queryChannel (MediaDesc &, uint chanNo) const
throw or return NULL-ChanDesc if Filehandle is invalid?
Class Meta
just a stub, still have to figure out the distinctive properties of asset::Meta
Class Meta
do we need this abstract baseclass?
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 mmap.c
development in this area is stalled since 2010
File mmapcache.c
development in this area is stalled since 2010
File mmapings.c
development in this area is stalled since 2010
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/builder/common.hpp
initially generated code of unclear relevance
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

Class MockElm
some usage details
See also
abstract-tangible-test.cpp
File model-port.hpp
they might bulk allocated in a similar manner than the ProcNode and WiringDescriptor objects are.
Member MORef< MO >::operator _Id const & () const
not sure if that leads to unexpected conversions, because the underlying implementation can be converted to size_t
File mould.hpp
plan and draft from 2008 – still considered relevant as of 2016
File mutation-message.hpp
as of 1/2017 there is an unsolved problem how such messages can be passed from lower layers. A direct symptom is the dependency of this header on model::Tangible, which in turn requires sigc::Trackable. This is a challenging topic, since we need to hand over to the UI-Event Thread /////////////////////////////////#1066 : Concept for passing Diff Messages
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"
File navigator.hpp
WIP 2/2017 early draft / foundations of "interaction control"
Class NavigatorWidget
WIP-WIP as of 12/2016
Class NetNodeFacade
define the services provided by such a node.
File netnodefacade.cpp
this just documents a vague plan. We won't be able to implement anything of that kind for the foreseeable future as of 1/2017
File netnodefacade.hpp
this just documents a vague plan. We won't be able to implement anything of that kind for the foreseeable future as of 1/2017
Class Nexus
write type comment
File nexus.hpp
initial draft and WIP-WIP-WIP as of 11/2015
File nocopy.hpp
2016 this could be organised way better. Also C++11 offers a way more elegant way of expressing the intention. We could get rid of boost::noncopyable The basic idea of using a marker mixin seems very reasonable though. ////////////////////////////TICKET #1084
File nodecreatortool.cpp
stalled design draft from 2008 – basically still considered relevant as of 2016
File nodecreatortool.hpp
stalled design draft from 2008 – basically still considered relevant as of 2016
File nodefactory.cpp
draft from the early days of the Lumiera project, reworked in 2009 Development activity in that area as stalled ever since. In the end, it is highly likely we'll indeed need a node factory though...
File nodefactory.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...
Member NodeFactory::operator() (mobject::session::PEffect const &, WiringSituation &)
as of 2016 this is the only (placeholder) implementation to indicate how building and wiring of nodes was meant to happen
Class NodeID
currently (10/08) this is a dummy implementation. We'll find out what is needed once the outline of the render engine is complete.
File nodeinvocation.hpp
relies still on an obsoleted implementation draft
See also
engine::ProcNode
engine::StateProxy
engine::BuffTable
nodewiring.hpp interface for building/wiring the nodes
File nodewiring.cpp
unfinished draft from 2009 regarding the render process
File nodewiring.hpp
unfinished draft from 2009 regarding the render process
File notification-service.cpp

1/2017 actually forward invocations on the UI-Bus

1/2017 find a solution for passing diff messages /////////////////////////////////////////////////TICKET #1066

File null-value.hpp
initialisation could be extended to use a free function to fabricate the NIL value object, so to support the special case of an NIL object not being default constructible
Class OpaqueHolder_test
this test doesn't cover automatic conversions and conversions using RTTI from the target objects, while OpaqueHolder.template get() would allow for such conversions. This is similar to Ticket #141, and actually based on the same code as variant.hpp (access-casted.hpp)
File operationpoint.cpp
stalled design draft from 2008 – basically still considered relevant as of 2016
File operationpoint.hpp
stalled design draft from 2008 – basically still considered relevant as of 2016
Member Option::Option (lib::Cmdline &cmdline)
describe the actual options
Class OutputDesignation
couldn't the inline buffer be "downgraded" to InPlaceBuffer or PolymorphicValue?? Seemingly we never-ever need to re-discover the erased type of the embedded spec. Thus for this to work, we'd just need to add an "empty" spec ///////////////////TICKET #723
Class OutputDirector
write Type comment
Member OutputDirector::isOperational () const
WIP-WIP-WIP 6/2011
Class OutputManager

need a concrete implementation

need a unit-test

write Type comment

File panel-manager.hpp
2017 need to clarify the intended behaviour of panels ///////////////////////////////////////////////////////////////////////////TICKET #1097 clarify the role and behaviour of Panels
Class PanelManager
this code is smelly and needs some clean-up ///////////////////////////////TICKET #1026
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 12/2016
Class PatchbayWidget
WIP-WIP as of 12/2016
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 placement-index-query-resolver.cpp

WIP implementation of session core from 2010

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

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

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

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

Class PlacementIndexQuery_test
change that to use a more realistic test session, based on the actual model types //////////////// TICKET #532
Class PlacementObjectIdentity_test
WIP-WIP to be written... TICKET #517
Class Play
WIP-WIP-WIP 6/2011
Note
Lumiera is not yet able actually to deliver rendered data.
there should be an accompanying CL Interface defined for the Lumiera interface system, so the player can be accessed from external clients. This was left out for now, as we don't have either plugins, nor any script running capabilities yet. (5/2011)
File play-service.hpp

started as draft in 11/2011

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

File playback-controller.hpp
create a durable PlaybacController design //////////////////////////////////////////////////////TICKET #1072
File player-widget.cpp
WIP-WIP-WIP as of 12/2016
File player-widget.hpp
WIP-WIP-WIP as of 12/2016 – the initial version of our UI implemented these controls directly within the timeline pane's button bar. We need to extract this common setup, since it is consensus that there is no consensus regarding the "best" position of such a control within the UI. So we need to offer the option to have "a player" either in the timeline, in the viewer(s) or as a standalone UI element.
Class PlayerWidget
WIP-WIP as of 12/2016
Member PlayOutSubsysDescriptor::shouldStart (Option &) override
actually define cmdline options and parse/decide here!
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...
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.
File priqueue.h
we might add operations to change the priority of an arbitrary element or remove any but the topmost element. The idea is to let expired elements sink to the top and just detect and remove them on next access.
Class Proc

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

File proc/asset/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 proc/mobject/session/binding.cpp

stalled effort towards a session implementation from 2010

2016 likely to stay, but expect some extensive rework

File proc/mobject/session/clip.cpp

stalled effort towards a session implementation from 2008

2016 likely to stay, but expect some extensive rework

File proc/mobject/session/clip.hpp

stalled effort towards a session implementation from 2008

2016 likely to stay, but expect some extensive rework

Member proc::asset::DUMMY_TIME (FSecs(5))
solve config management
Namespace proc::mobject
is this interface or implementation ??
Member proc::mobject::ON_SESSION_END ("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 proc::mobject::PlacementMO
cleanup uses of ref-to-placement. See Ticket #115
Member ProcFactory::operator() (Asset::Ident &key)
actually define
Returns
an Proc smart ptr linked to the internally registered smart ptr created as a side effect of calling the concrete Proc subclass ctor.
Class ProcNode
it's not clear as of 9/09 if ProcNode shall be an ABC/Interface It might be used as ABC (as was the original intention) when implementing several query/information functions. In that case, the ctor will become protected. The alternative would be to push down these information-retrieval part into a configurable element within WiringDescriptor, in which case we even might drop ProcNode as a frontend entirely.
Member ProcPatt::ProcPatt (const Asset::Ident &idi)
preliminary implementation, storing the capabilities in the asset name field. We can do better, when it's clear what capabilities we need
File project.hpp
this solution was used to build the first outline of the UI. It needs to be reshaped into a connector to Proc-Layer ///////////////TICKET #959
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
See also
Query::Builder::extractID
Class QueryHandler< TY >
retrofit this to install and use a QueryResolver
See also
lumiera::query::LookupPreconfigured
lumiera::query::MockTable
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
See also
QueryText
File real-clock.cpp

just a rough draft as of 2012 / 2017

the idea was that the backend has elaborate knowledge about timings and time progression; upper layers should thus be able to fulfil their timing needs by querying the backend

File real-clock.hpp

WIP-WIP-WIP 3/2012

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.

not clear if this becomes some kind of central service (singleton) or just a bunch of library routines

File ref-array.hpp
as of 2016, this concept seems very questionable: do we really want to abstract over random access, or do we actually want for-iteration??
Class RefArray< T >
ouch – a collection that isn't iterable... ///////////////////////TICKET #1040
Class 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-invocation.cpp
unfinished draft from 2009 regarding the render process
File render-invocation.hpp
unfinished draft from 2009 regarding the render process
Class RenderEngine
this was planned to become the frontend to the render node network, which can be considered at the lower end of the middle layer; the actual render operations are mostly implemented by the backend ////////TODO WIP as of 12/2010
Class RenderGraph
likely to be reworked into the engine backbone /////////////TODO WIP as of 12/2010
Class RenderInvocation
write type comment
Member RenderInvocation::operator[] (size_t channel)
for real use within the engine, the pull()-call should be dispatched through the scheduler; of course then the call semantics would be completely different. Maybe this invocation will be test only?
Class RenderState
probably the state management will work different (6/08)
Member ReplaceableItem_test::verifyOnlyMoveConstructible ()
conceptually, the whole point of this container is the ability to snapshot elements which allow nothing but move construction. Seemingly, GCC-4.9 does not fully implement perfect forwarding ///////////////////////TICKET #1059 : re-visit with never compiler
File resourcecollector.c
this was a plan from 2008 and never got beyond an initial concept stage
File resourcecollector.h
this was a plan from 2008 and never got beyond an initial concept stage
File result.hpp
WIP and rather brainstorming as of 2/10
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.
Note
beware of performance problems here!
File ruler-widget.cpp
WIP-WIP-WIP as of 12/2016
File ruler-widget.hpp
WIP-WIP-WIP as of 12/2016
Class RulerWidget
WIP-WIP as of 12/2016
File scheduler-frontend.hpp
WIP unfinished since 9/2013
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 backend

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

File scope-cmd.cpp
WIP 3/2017 early draft
File scope-locator.hpp

WIP implementation of session core from 2010

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

File scope-path.cpp

WIP implementation of session core from 2010

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

File scope.hpp

WIP implementation of session core from 2010

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

File scoped-holder-transfer.hpp
expunge this!
Member ScopedPtrVect< T >::detach (void *objAddress)
TICKET #856 better return a Maybe<T&> instead of a pointer?
Member ScopeQuery< MO >::buildSyntacticRepresentation () const
we need a readable and sensible representation as generic query ///////////////////TICKET #901
Class ScopeQuery_test
change that to use a more realistic test session, based on the actual model types //////////////// TICKET #532
Class ScriptRunnerFacade
build the (LUA,C)-script runner.
File scriptrunnerfacade.cpp
this just documents a vague plan. We won't be able to implement anything of that kind for the foreseeable future as of 1/2017
File scriptrunnerfacade.hpp
this just documents a vague plan. We won't be able to implement anything of that kind for the foreseeable future as of 1/2017
Class Segment
1/2012 Just a Placeholder. The real thing is not yet implemented.
See also
http://lumiera.org/wiki/renderengine.html#Fixture
File segment.cpp

stalled effort towards a session implementation from 2008

2016 likely to stay, but expect some extensive rework

File segment.hpp

stalled effort towards a session implementation from 2008

2016 likely to stay, but expect some extensive rework

Class Segmentation
1/2012 Just a Placeholder. The real thing is not yet implemented.
See also
http://lumiera.org/wiki/renderengine.html#Fixture
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

stalled effort towards a session implementation from 2008

2016 likely to stay, but expect some extensive rework

File segmentation.hpp

stalled effort towards a session implementation from 2008

2016 likely to stay, but expect some extensive rework

File sequence-cmd.cpp
WIP 4/2017 early draft
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-facade.cpp

THE NAME IS UNFORTUNATE!!!! "SessionFacade" should rather be a facade in Proc!

WIP ///////////////////////TICKET #

File session-facade.hpp
WIP ///////////////////////TICKET #
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

File session-structure-mapping-test.cpp

WIP ///////////////////////TICKET #955

WIP ///////////////////////TICKET #961

Member Session::initFlag
really solve the basic init of session manager TICKET #518
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?
Parameters
snapshotIDmarker to tag the snapshot, like e.g. a timestamp
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

Warning
throws error::Fatal or even deadlocks when called from session thread
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!

Warning
throws error::Fatal or even deadlocks when called from session thread
Class SimpleAllocator< TYPES, COUNTER >
currently (as of 8/09) the low-level pooled allocator isn't implemented; instead we do just heap allocations. ////////////////////////////////////////////////////////////////////////////////////////////Ticket #835
Class SimpleAllocator_test
as of 9/11 we do heap allocation, but we should use mpool – see also Ticket #835
Member Smpte::applyRangeLimitStrategy (SmpteTC &)
If necessary, this extension point should be converted into a configurable strategy. Possible variations
  • clip values beyond the boundaries
  • throw an exception on illegal values
  • wrap around from 23:59:59:## to 0:0:0:0
  • just make the hour negative, but continue with the same orientation (0:0:0:0 - 1sec = -1:59:59:0)
Member Smpte::getFramerate (QuantR, TimeValue const &)
this design just doesn't feel quite right...
Class SmpteTC
the range extension scheme could be a configurable strategy
File source.hpp
this file is there since the very first code generation steps at start of the Lumiera project. It is not yet clear if those source reading nodes will indeed be ProcNode subclasses, or rather specifically configured processing nodes...
File 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
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.
Warning
state mark entries are added, never discarded. Once we start actually persisting this state, this might get us into trouble.
Class StateMapGroupingStorage
reinvestigate with GCC-5 //////////////////////////////////TICKET #991
See also
StateMapGroupingStorage_test
Member StateMapGroupingStorage::getState (Record const &entry, string propertyKey)

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

File stateproxy.cpp
unfinished draft from 2009 regarding the render process
File stateproxy.hpp
unfinished draft from 2009 regarding the render process
Class StreamType
this is just a draft to show the general idea....
Class Struct
the actual meaning of a "structural asset" needs to be sharpened and evolved. The idea is to have a generic mechanism for attaching properties and relations. This will become relevant once we build the real query subsystem. Right now (as of 1/2015), asset::Struct is just an ID provider.
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.

Note
the exact calling sequence implemented here can be considered a compromise, due to having neither a working resolution, nor a generic interface for issuing queries. Thus, directly calling this factory acts as a replacement for both. The intended solution would be to have a dedicated QueryResolver, which is fully integrated into a generic rules driven query subsystem, but has the additional ability to "translate" capabilities directly into the respective properties of of asset::Struct subclasses.
Returns
a Struct smart ptr linked to the internally registered smart ptr created as a side effect of calling the concrete Struct subclass ctor.
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 stypemanager.hpp
very crucial part of the design, unfortunately development in this area is stalled since 2012
Member STypeManager::getImpl (Symbol libID, StreamType::Prototype const &protoType)
find out if this one is really necessary, because it is especially tricky
Class STypeManager::Registry
as of 3/2008 the real query implementation is missing, and the exact behaviour has to be defined.
File sub-id.hpp
1/2016 this idea seems very reasonable, and we should just make it robust and usable, along the lines pointed out by that draft
  • use std::tuple as storage
  • remove the format-util dependency (!) ////////////////////////////////TICKET #985
  • provide a hash implementation for real
  • extend to arbitrary number of sub-dimensions (variadic)
  • implement comparisons as you'd do for any algebraic type
  • provide a metaprogramming facility to get an id tuple
Class SubsystemRunner
maybe use my refArray (see builder) to use Subsys& instead of Subsys* ??
File suite.hpp
as of 9/09, the implementation seems OKish but a bit clumsy. See Ticket #289
File switchboard-widget.cpp
WIP-WIP-WIP as of 12/2016
File switchboard-widget.hpp
WIP-WIP-WIP as of 12/2016 this is a plan (yes, we most definitively want that!), but we do not even remotely know how to implement such a feature. It is only clear by now that we'll build a output processing graph on top of the core render nodes network, and this output processing will care e.g. for scaling the output to fit into the viewer window. Activating the switchboard needs to extend this output processing graph.
Class SwitchboardWidget
WIP-WIP as of 12/2016
Member SYMBOL
intention is to integrate with lib::Symbol
File symbol-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
for the (currently just planned as of 11/08) rules based configuration in the Proc-Layer a explicit Symbol datatype will probably very helpful. For now just a typedef is sufficient. A real Symbol datatype should
  • be definable by string constant
  • integrate smoothly with std::string
  • provide a unique numeric index for each distinct Symbol
  • automatically maintain a symbol table at runtime to support this
  • provide some magic (macros) allowing to build distinct types based on symbols.
Class Symbol_test
this test is very much WIP, as the implementation of a real symbol type and symbol table remains to be done. ///////////////////////////Ticket #157
File tangible-update-test.cpp

WIP ///////////////////////TICKET #959

WIP ///////////////////////TICKET #961

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.
Member Tangible::slotReveal (ID child)
12/2015 not clear yet what needs to be done
Remarks
the intention is to request the given child to be brought into sight. We need to set up some kind of children registration, but better not do this in a completely generic fashion, for danger of overengineering. Moreover, it is not clear yet, who will issue this request and at which element the initial request can/will be targeted.
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-dummy-mobject.hpp
needed to move this temporarily into the core session tree. ////////////TICKET #532
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 thread-local.hpp

care for unit test coverage

WIP-WIP. Maybe add facilities similar to boost::specific_ptr

File threadpool-init.hpp
as of 1/10 it is not clear if this will be the final solution. Alternatively, we may rely on a subsystem "backend" or "threadpool"
File threadpool.c
development in this area is stalled since 2010
File threadpool.h
development in this area is stalled since 2010
File threads.c
development in this area is stalled since 2010
File threads.h
development in this area is stalled since 2010
File time-anchor.hpp

this is part of an implementation draft from 2013, to create a complete outline of player and render job generation.

as of 2016 this effort is stalled, but remains valid

File timecode-widget.hpp
needs extensive rework to get smooth integration with Lumiera's timecode handling functions
File timecode.cpp
a started implementation exists since 2010, yet crucial parts still need to be filled in as of 2016
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 12/2016 a complete rework of the timeline display is underway
See also
TimelineWidget
File timeline-controller.hpp
as of 12/2016 a complete rework of the timeline display is underway
File timeline-layout-helper.cpp
this class should be thoroughly reworked; it seems to be kind of a "god class" ////////TODO 5/2015
File timeline-panel.cpp

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

build a new timeline widget, connected to the UI-Bus

See also
timeline-widget.hpp
File timeline-panel.hpp

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

build a new timeline widget, connected to the UI-Bus

File timeline-track.cpp
as of 2016 this is about to be replaced by a new implementation approach
Warning
as of 2016 the entire timeline display is planned to be reworked
File timeline-track.hpp
as of 2016 this is about to be replaced by a new implementation approach
Warning
as of 2016 the entire timeline display is planned to be reworked
File timeline-widget-empty.cpp
as of 12/2016 a complete rework of the timeline display is underway
File timeline-widget-empty.hpp
as of 12/2016 a complete rework of the timeline display is underway
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...
See also
Session
Sequence
StructFactory
File timeline/timeline-widget.cpp
as of 12/2016 a complete rework of the timeline display is underway
See also
timeline-controller.cpp
File timeline/timeline-widget.hpp
as of 12/2016 a complete rework of the timeline display is underway
Member Timeline::Timeline (Ident const &, RBinding const &)
anything significant to do here???
Member TimelineBody::on_expose_event (GdkEventExpose *event)
looks like this was the main drawing hook, and happens to be discontinued in GTK3. ///////////////////TICKET #937 : custom timeline widget draw function not invoked anymore
Class TimelineController
WIP-WIP-rewrite as of 12/2016
Remarks
a Timeline always has an attached Sequence, which in turn has a single mandatory root track. This in turn might hold further child tracks, thus forming a fork of nested scopes.
Class TimelinePanel
build the actual implementation, after finishing the investigation
Class TimelineSequenceHandling_test

specify how deletion is handled

specify how to move objects by placement

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

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

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

Member TimelineViewWindow::get_time_offset () const
obviously this must be switched to use the relevant time grid from the session / current timeline to be displayed. It doesn't make sense to display raw time values here, as each timeline might turn out to have a different origin; this is the result of resolving a placement, and only the session has the necessary information...
Member TimelineViewWindow::get_time_scale () const
this is private detail that shouldn't be exposed to the outside //////////////////TICKET# 795
Member TimelineViewWindow::set_time_offset (TimeValue const &)
this is private detail that shouldn't be exposed to the outside //////////////////TICKET# 795
Member TimelineViewWindow::x_to_time (int x) const
5/11 this is good for now, but on the long run I'm tinking we rather should treat that like a special frame grid (display coordinate system) and then use the same framework we use for timecodes and frame counts.
Class TimelineWidget
WIP-WIP-rewrite as of 12/2016
Remarks
At top level, this widget is split into a header pane (left) and a scrollable timeline body (right). The layout of both parts is aligned.
Class TimelineWidgetEmpty
WIP-WIP-rewrite as of 12/2016
Remarks
At top level, this widget is split into a header pane (left) and a scrollable timeline body (right). The layout of both parts is aligned.
Member TimelineZoomScale::TimelineZoomScale ()

The initial adjustment value needs to match what the TimelineViewWindow's actual timeScale Value is. TimelineViewWindow::get_time_scale() is currently a public method, but will soon be private. Maybe TimelineViewWindow can have a zoom_adjustment that gets passed to this widget's Constructor?

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

  • how can we managed to be notified from that switch?
  • problem is: TimelineZoomScale widget is owned by the TimelinePannel. Likewise, TimelineWidget is owned by the TimelinePannel. But the state handling/switching logic is embedded within TimelineWidget
  • and finally: how can we translate the actual scale (in time units), as maintained within TimelineViewWindow, back into the adjustment used here (which uses a relative scale 0...1.0 ) S
Class Timeout
integrate with std::chrono //////////////////////////TICKET #1055
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
See also
output-slot.hpp ////TODO
Member Timings::constantFrameTimingsInterval (TimeValue startPoint) const
implement real support for variable frame rates
File toolfactory.cpp
stalled design draft from 2008 – basically still considered relevant as of 2016
File toolfactory.hpp
stalled design draft from 2008 – basically still considered relevant as of 2016
Member ToolFactory::getProduct ()
unclear what to do and to return here
File track-body.cpp
WIP-WIP-WIP as of 12/2016
File track-body.hpp
WIP-WIP-WIP as of 12/2016
File track-head-widget.cpp
WIP-WIP-WIP as of 12/2016
File track-head-widget.hpp
WIP-WIP-WIP as of 12/2016
File track-presenter.cpp
WIP-WIP-WIP as of 12/2016
File track-presenter.hpp
WIP-WIP-WIP as of 12/2016
Class TrackBody
WIP-WIP as of 12/2016
Class TrackHeadWidget
WIP-WIP as of 12/2016
Class TrackPresenter
WIP-WIP as of 12/2016
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 tree.hpp
  • New-style move members are not completely finished yet.
  • It would be good to have an iterator which can iterate over all nodes below a given node. Something similar to the leaf iterator we have right now, but not restricted to the leaves.
  • If a range uses const iter_base& as end iterator, things will inevitably go wrong, because upcast from iter_base to a non-sibling_iter is incorrect. This upcast should be removed (and then all illegal uses as previously in 'equal' will be flagged by the compiler). This requires new copy constructors though.
  • There's a bug in replace(sibling_iterator, ...) when the ranges sit next to each other. Turned up in append_child(iter,iter) but has been avoided now.
  • std::operator< does not work correctly on our iterators, and for some reason a globally defined template operator< did not get picked up. Using a comparison class now, but this should be investigated.
File typed-allocation-manager.hpp

WIP WIP.

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

File typed-counter.hpp
2010 ... this is the first, preliminary version of a facility, which is expected to get quite important for custom allocation management.
File typed-id.hpp
and as of 2016, we acknowledge the importance of this approach, just the topic is deferred for now and will be picked up later...
File typed-lookup.cpp
this is placeholder code for an important facility, required once we engage into predicate rules based configuration. 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
partially unimplemented and thus commented out ////////////////////TICKET #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-bus.hpp
as of 1/2015, this header needs to be reshaped ////////////////////TICKET #959
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 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::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.
Note
this case is the default and kicks in unless we detect a Lumiera iterator. The handling is different for and_all
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

See also
wrapperptr.hpp usage example
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!
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 Widget
write type comment...
File widget.hpp
as of 1/2015 this is complete WIP-WIP-WIP
File widget/timeline-widget.hpp
needs to be reworked from ground as if 5/2015 GTK-3 uses different event handling callbacks, so the existing implementation is defunct. Moreover, this class is designed way to monolithic. It will never be able to scale to the full planned timeline and editing functionality of Lumiera
See also
gui::timeline::TimelineWidget new timeline display
Class WiringDescriptor
the design of this part is messy in several respects. Basically, its left-over from a first prototypical implementation from 2008 As of 1/2012, we're re-shaping that engine interface and invocation with a top-down approach, starting from the player. Anyhow, you can expect the basic setup to remain as-is: there will be a ProcNode and a WiringDescriptor, telling how it's connected to its predecessors, and defining how the Node is supposed to operate
File wiringrequest.hpp
stalled design draft from 2008 – basically still considered relevant as of 2016
File wish.cpp
result of the very first code generation from UML in 2008. 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

The infrastructure for context sensitive help needs to be defined

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

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