after reading some related code, I am leaning towards a design
to mirror the way command messages are sent over the UI-Bus.
Unfortunately this pretty much abandons the possibility to
invoke these operations from a client written in C or any
other hand made language binding. Which pretty much confirms
my initial reservation towards such an excessively open
and generic interface system.
...the sheer amount of mechanical replacements scattered all over these
files might be a vivid indication, that the design of the interface system
is subobptimal ;-)
this was introduced into namespace mobject and spread from there.
Since the habit is to use more specific typedefs like PClip,
it is preferrable to spell out the full namespace
In Lumiera, "Tracks" are not what you'd expect from
conventional video editing software. They are a mere
grouping devide, and are also used to implement the
"media bins" and tool palettes.
But having "folders" on the timeline would be likewise
confusing, as would be to have a "branch" or "tree".
To get out of that dilemma, we chose an understandable
but deliberately somewhat strange name: "Fork"
It was common understanding on the Mailinglist that we
should handle this renaming in a tuned-down and discrete
way: The UI will continue to show "Tracks" for a familiar
sight and "Bins" in the Asset section. But Lumiera developers
will be nudged to accomodate by renaming the entity in
source code accordingly
- upgrade the configuration to a current version
- provide a frontpage with cross-links to other documentation
- define a set of modules; relevant classes and files can be
added to these, to create a exploration path for new readers
- fix a lot of errors in documentation comments
- use a custom configuration for the documentation pages
- tweak the navigation, the sections and further arrangements
to make them stand out more prominently, some entity comments
where started with a line of starts. Unfortunately, doxygen
(and javadoc) only recogise comments which are started exactly
with /**
This caused quite some comments to be ignored by doxygen.
Credits to Hendrik Boom for spotting this problem!
A workaround is to end the line of stars with *//**
Clang doesn't allow to declare a private nested class as friend.
This is unfortunate, but likely correct to the letter of the standard.
As a workaround, now we're creating the instances within a static
function of DependencyFactory -- in the end this improves readability
A second issue fixed with this changeset is the scope of the
marker function. Clang is right, this isn't ADL, thus an inline
friend definition is simply not visible outside the class.
lib::Depend<TY> works as drop-in replacement for lib::Singleton<TY>
This changeset removes the convoluted special cases like
SingletonSub and MockInjector.
this draft fills in the structure how to get from an invocation
of the engine service to the starting of actual CalcStream instances.
Basically the EngineService implementation is repsonsile to
instruct the Segmentation to provide a suitable Dispatcher.
the buildsystem will now pick up and link
all test cases according to the layer, e.g.
backend tests will automatically be linked
against the backend + library solely.
now this library doesn't refer to any symbols from
Proc-Layer anymore. Resolving these problems
highlighted IMHO a serious shortcomming of our
interface system, which hinders the building
of abstractions at interface level
there is now a mechanism to allow sprcialised queries
to generate this syntactic representation only on demand
The actual concrete representation e.g. for scope queries
still remains TODO, but this won't really change
until we target the integration of a real resoloution engine
connect config-facade with the new BasicSetup implementation
to fetch values from setup.ini, instead of the (not implemented)
Config-system. Hook this new lookup mechanism into the
plugin loader to retrieve the search path from there
DisplayService is intended to implement the Display facade and additionally
manage N display output sinks (DisplayerSlot). Now the playback-controller
contains just the bare controller logic, all services like tick generation
or signal dispatching have been factored out... makes me feel better :-)
this allows the C++ version to provide automatic lifecycle management for
the play process, while both versions of the API (C and C++) impose only
one level of indirection.
I grepped out all flags which are actually defined/used in lumiera and
refactored them into one big tree here. There are some annotations and
issues which shall be finally resolved. Please check if the intended
hierarchy looks OK this way and add more flags when you think some are
missing. I chosen to make a quite verbose hierarchy, this doesnt cost much
in nobug and adds some flexibility. The Documentation at the head needs to
be reviewed. Many flags which are collected here need to be brought back
into the subsystems which use them, this is only to get a big picture for
now.
