Since 'Enter' is also a submit button and another style gets applied,
both seem to overlap. Not very important on a desktop, but might be
easier to navigate on mobile screen
(plus, move settings backup buttons back at the top, accidentally moved
those to the bottom in the previous commit)
On the DEBUG page as well, trying to fix the scrolling behaviour when the
logging stream just started and will only jump after it spends some time at
the top row. Watching the element state to pause the autoscroll when we
manually move the slider, and resume it once the slider touches the bottom
of the textarea. Entering the command will reset the state and enable
the autoscrolling immediately
Separate variables that are used just for the internal loop,
and the ones that are supposed to go into the client as args
Clean up logging and the terminal output, certain things are
now visible through the settings query and there's no need to
dump the build value
Resolve the issue with the UnixHostDuino not really being compatible
with the esp8266 Core String (...and the rest of the Core, as well)
Port the CMakeLists.txt from the rpnlib and update it use FetchContent
instead of either manually fetching dependencies or using PIO artifacts
Caching is *expected* to work, but might need slight adjustments
Make more use of control-groups instead of adding a manual alignment
class to each element. Surprisingly, this is slightly larger than the
previous .gz.html output, but not enough to not consider the readability.
Status page updated to take the lengthy hostnames and version strings
into an account, remove those from the sidebar.
Clean-up terminal module. Use the same style for both input and output,
move the terminal handler and debug handler into an appropriate .cpp
Generate explicit events. Don't have a separate group observer that
tracks deletion, but handle it immediately from the 'button' event
Replace kv array with a direct key updates. While the backed part still
must optimize for size, from this side we should operate on keys directly
Settling on naming 'options' for enumerations (...possibly, everything
else in the future, would that make sense to store for 'setting' object)
Update terminal commands that were reporting status to also report a
full list of 'indexed' settings for the specific entity
Also updates the WebUI outputs which are (hopefuly) are already handled
as-is through the .js processing pipeline and the .html properties
receiving certain special string values
More namespacing and save ~2KiB of RAM by reducing the amount of loaded keys strings
However, ROM side of things may suffer b/c of template specializations for the
generic conversion functions when there are many different types involved.
Make sure we seamlessly handle 'convert' for the number and the string version.
And since it is a two-way map, update 'serialize' to use it as well instead of
either a simple static_cast<int> or duplicating the same strings used in 'convert'
Only string literals or static vars can be used in constexpr context,
but those can still be shoved into the flash region via PROGMEM.
Notably, PSTR(...) inside of a lambda is not a constexpr.
Some quirks to work out
- we don't 'enumerate' things through compiler, enum values may go
missing since it is not a switch-case
- 'get' default value via query still requires us to know the settings
key in the first place. and it still needs an explicit call to
'serialize'
- sensor units are stringified as their display value.
but, this also avoids two different 'string' versions of those
- EnumOptions struct instance may also be in PROGMEM, but one needs
to be very careful to only allow aligned access to it's members
(which currently means we can't use 8bit or 16bit 'enum class'es)
Don't introduce our callback to the type system, continue to bind the
ticker instance as the timer's arg and just use the lambda to pass the
argument to the reset function
```
libraries/Ticker/src/Ticker.h:136:41: warning: cast between incompatible function types from 'void (*)(CustomResetReason)' to 'Ticker::callback_with_arg_t' {aka 'void (*)(void*)'} [-Wcast-function-type]
136 | _attach_ms(milliseconds, false, reinterpret_cast<callback_with_arg_t>(callback), reinterpret_cast<void*>(arg));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Attempt to either parse with newer syntax, or fallback to the floating
point seconds as default. Settings also return a 'result' instead of the
default zero, fallback to build value otherwise (which is still floating point, though)
Update /pulse API endpoint to report the actual pulse timer value that
is active right now, not just the value attached via the setting