summaryrefslogtreecommitdiff
path: root/src/til_settings.c
AgeCommit message (Collapse)Author
2022-07-15til_fb: switch til_fb_ops_t.init() to use til_setup_tVito Caputo
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.
2022-05-25*: normalize on all case-insensitive comparisonsVito Caputo
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.
2022-04-01til_settings: make res_{desc,setting} optionalVito Caputo
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.
2022-03-30til_settings: fix empty values in til_settings_new()Vito Caputo
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.
2022-03-30til_settings: remove vestigial return missed by 7ff8efVito Caputo
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.
2022-03-28til_settings: provide a user_data pointer w/til_setting_tVito Caputo
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.
2022-03-19*: de-constify til_setting_t throughoutVito Caputo
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.
2022-03-19til_settings: introduce til_settings_reset_descs()Vito Caputo
This is helpful for forcing underlying setup methods to redescribe their settings, regardless of what a til_settings_t's internal state is.
2022-03-12til_settings: always describe relevant settingsVito Caputo
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.
2021-10-01*: librototiller->libtilVito Caputo
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_.
© All Rights Reserved