| Age | Commit message (Collapse) | Author |
|---|
|
This adds a new "meta" module which registers itself as a
pre-render context on the stream, to render whatever module is
specified as the "module=" setting.
The impetus for this is background music in rkt creations, so one
can avoid enduring the rigamarole of plugging something like a
"playit" instance into every scene.
With this "pre" builtin one can just use something like
"pre,module=playit,itfile=music.it" as a scene, and that will get
the playit module playing music.it hooked into the stream,
without the need to always have it present in every scene's
settings.
There's a TODO item noting the need for taps to control the
active/inactive state of the pre instance this adds. For now,
once you have a "pre", whatever module it contains will be
rendered before the main stream context set
w/til_stream_set_module_context() gets rendered. That's fine for
now, but there will need to be more control especially as more
complex productions happen involving multiple songs.
|
|
Since ref can be used to reference any module type by path,
including ones that don't touch the fragment, it's inappropriate
to integrate via render_fragment() since that will cause an
implicit clear of the fragment.
This is exactly the type of scenario render_proxy was added for,
so use it here.
|
|
Mechanical rename to txt_render_fragment_aligned(), updating all
existing call sites accordingly.
This is a preparatory commit for introducing an offsetted variant
of txt_render_fragment() (txt_render_fragment_offsetted()).
No functional difference, purely naming changes.
|
|
When using the blank builtin for profiling purposes it can be
necessary to ensure it actually incurs the cost of clearing.
|
|
_ref_setup() doesn't have any -EINVAL failure paths in res_setup
baking, but let's get off til_settings_get_and_describe_value()
so it can go away.
|
|
Missed one!
|
|
Sometimes nested modules are optional, in those cases I've
usually been using the "none" module name to indicate this and
the ad-hoc setup stuff can easily bypass module setup on that.
This commit is a step towards having a "none" builtin that
provides a til_module_t.setup() which succeeds but only produces
a NULL res_setup when asked to finalize.
So if callers just handle a successful finalize case that writes
NULL at res_setup equivalent to "disabled", this all Just Works.
Currently that's not an expected thing, but future commits will
bring everything else on the same page.
For callers who want to require the module and not offer "none",
they can just put "none" in the explicit exclusions list passed
to til_module_setup_full().
|
|
Also move builtins to a separate listing while at it
For now this results in the builtins showing up in the modules
list alongside the actual rendering modules. Future work must
refine this UX, maybe by adding some metadata to the spec.values
for categorizing/prioritizing what's shown always vs. what's
present but hidden without asking to be shown hidden stuff or
whatever.
Just consolidating some junk and working towards every nested
module setup going through the same machinery, and always being
able to access the builtins.
|
