| Age | Commit message (Collapse) | Author |
|---|
|
Preparatory commit for settings hierarchies.
|
|
This adds a mandatory label string to til_setttings_new() and
updates call sites accordingly.
For now the root-level settings created by main.c are simply
named "module" and "video" respectively. Any nested settings
creations on behalf of modules will be labeled using the module's
name the settings are being created for use with.
This might evolve with time, for now it's just a minimum churn
kind of decision. I can see it changing such that the top-level
settings also become labeled by the module/video driver name
rather than the obtuse "module" "video" strings.
How these will be leveraged is unclear presently. At the least
it'll be nice to have a label for debugging til_settings_t
heirarchies once recursive settings support lands. In a sense
this is a preparatory commit for that work. But I could see the
labels ending up in serialization contents as markup/syntactic
sugar just to self-document things as well.
There might also be a need to address til_settings_t instances in
the settings heirarchy, which may be something like a
"label/label/label/label" path style thing - though there'd be a
need to deal with name collisions in that approach.
I'm just thinking a bit about how knobs will become addressed
when those become a real thing. The settings label heirarchy
might be the convenient place to name everything in a tree, which
knobs could then inherit their parent paths from under which
their respective knob labels will reside. For the whole name
collision issue there could just be some builtin settings keys
for overriding the automatic module name labeling, something
like:
--module=compose,layers=checkers\,label=first\,fill_module=shapes:checkers\,label=second\,fill_module=shapes
would result in:
/module/first/shapes
/module/second/shapes
or in a world where the root settings weren't just named "module"
and "video":
/compose/first/shapes
/compose/second/shapes
then if there were knobs under checkers and shapes, say checkers
had a "foo" knob and checkers had a "bar" knob, they'd be under
.knobs in each directory:
/compose/first/.knobs/foo
/compose/first/shapes/.knobs/bar
/compose/second/.knobs/foo
/compose/second/shapes/.knobs/bar
something along those lines, and of course if compose had knobs
they'd be under /compose/.knobs
This is just a brain dump and will surely all change before
implemented.
|
|
This is a step towards properly handling nested settings, so we
can do stuff like:
--module=rtv,channels=compose\,layers=checkers\\\,fill_module=shapes\\\,size=64\,texture=plasma
and have rtv actually cycle through just compose with
checkers+plasma layers but holding the specified checkers
settings to shapes filler with a size of 64, randomizing the
rest.
There's more work to do before that can actually happen, but
first thing is to just support escaping the settings values.
|
|
Until now the fb init has been receiving a til_settings_t to
access its setup. Now that there's a til_setup_t for
representing the fully baked setup, let's bring the fb stuff
up to speed so their init() behaves more like
til_module_t.create_context() WRT settings/setup.
This involves some reworking of how settings are handled in
{drm,sdl}_fb.c but nothing majorly different.
The only real funcitonal change that happened in the course of
this work is I made it possible now to actually instruct SDL to
do a more legacy SDL_WINDOW_FULLSCREEN vs.
SDL_WINDOW_FULLSCREEN_DESKTOP where SDL will attempt to switch
the video mode.
This is triggered by specifying both a size=WxH and fullscreen=on
for video=sdl. Be careful though, I've observed some broken
display states when specifying goofy sizes, which look like Xorg
bugs.
|
|
I don't think rototiller is an appropriate place for being so
uncooperative, if someone gets the case wrong anywhere just make
it work. We should avoid making different things so subtly
different that case alone is the distinction anyways, so I don't
see this creating any future namespace collision problems.
|
|
The til_settings_get_and_describe_value() helper (and the calling
setup methods in the modules) can be useful in independently
spitting out a baked setup instance from a fully resolved
til_settings_t which has already gone through the whole
rigamarole of getting populated and described.
Normally when this all happens in one place with the setup
instance then either immediately fed to create_context(), or
stowed somewhere for future use, it's not a problem to always
require the res_desc,res_setting parameters.
But especially in GUI scenarios (glimmer) the whole populate and
describe phase of til_settings_t can very easily be done in a
separate place from the convenient place to produce a setup out
of it. So when the caller /knows/ the setup is finished and a
subsequent call with the same til_settings_t would produce a
res_setup immediately, the caller should be able to omit
res_setting and res_desc as they're of no use now.
This is all kind of crufty, but it's nice to have all this
happening in a single setup method to help keep the res_setup
phase from diverging/becoming out of sync with the
populate+describe phase. Will live with it for now. Frontends
get written far less than modules, so the API cruft from the
frontend perspective is relatively benign. It's still relatively
sane and ergonomic from the module writer's perspective.
|
|
Previously if you supplied an empty setting value like so:
"--module=compose,layers="
The interactive setup would get itself into an infinite loop
because the layers setting is already present, but has a NULL
value. This wasn't a NULL value, it was a "" value.
The parser should just fallthrough to the value state from the
equal state after recording the value's start pointer. This will
result in a "" value getting allocated and assigned to the value
before the loop breaks out on the '\0' immediately following the
'='.
There are probably other edge cases which need better handling
here.
|
|
Commit 7ff8ef included some fast and dirty fixups to
til_settings_apply_desc_generators(), but left an inappropriate
return path out of the iterator resulting in the caller accessing
a NULL res_desc.
The practical result of this was segfaulting in rototiller when
configuring anything utilizing desc generators, like drm_fb.
|
|
Particularly in implementing a stateful/"retained" GUI it can be
desirable to embed something like a widget pointer in a
til_setting_t once described and shown to the user.
Management of this pointer is largely nonexistant from the
libtil perspective. It's simply initialized to NULL when a new
setting is added, and never accessed again. 100% the caller's
responsibility.
This works fine since libtil/til_settings_t only accumulates
til_setting_t entries and never removes them except when
discarding an entire til_settings_t wholesale.
|
|
Now that til_setting_t.desc is not only a thing, but a thing that
is intended to be refreshed regularly in the course of things
like GUI interactive settings construction, it's not really
appropriate to try even act like this these are const anymore.
|
|
This is helpful for forcing underlying setup methods to
redescribe their settings, regardless of what a til_settings_t's
internal state is.
|
|
The existing iterative *_setup() interface only described
settings not found, quietly accepting usable settings already
present in the til_settings_t.
This worked fine for the existing interactive text setup thing,
but it's especially problematic for providing a GUI setup
frontend.
This commit makes it so the *_setup() methods always describe
undescribed settings they recognize, leaving the setup frontend
loop calling into the *_setup() methods to both apply the
description validation if wanted and actually tie the description
to respective setting returned by the _setup() methods as being
related to the returned description.
A new helper called til_settings_get_and_describe_value() has
been introduced primarily for use of module setup methods to
simplify this nonsense, replacing the til_settings_get_value()
calls and surrounding logic, but retaining the til_setting_desc_t
definitions largely verbatim.
This also results in discarding of some ad-hoc
til_setting_desc_check() calls, now that there's a centralized
place where settings become "described" (setup_interactively in
the case of rototiller).
Now a GUI frontend (like glimmer) would just provide its own
setup_interactively() equivalent for constructing its widgets for
a given *_setup() method's chain of returned descs. Whereas in
the past this wasn't really feasible unless there was never going
to be pre-supplied settings.
I suspect the til_setting_desc_check() integration into
setup_interactively() needs more work, but I think this is good
enough for now and I'm out of spare time for the moment.
|
|
Largely mechanical rename of librototiller -> libtil, but
introducing a til_ prefix to all librototiller (now libtil)
functions and types where a rototiller prefix was absent.
This is just a step towards a more libized librototiller, and til
is just a nicer to type/read prefix than rototiller_.
|
