Problem is that the main application actually does not create a pty and
instead uses the current one (for better compatability for ssh based
hosting).
The current problem is the fact that the child process should not
take over (and never give back too) the input / output handling of the
current pts. Such that both applications can receive inputs accordingly
(in best case actually controlled by the main application).
Negative paddings use the current size to calculate the padding from
the opposite orientation. For a given dimension (horizontal or vertical)
if the size is `30` a padding of `5` would be equivalent to a padding
of `-25`. This enables to describe the size of the container using
the padding property of the `Layout` and gives users more freedom to
describe different layouts.
There are now comptime checks in place an the corresponding triggered
event will be automatically converted to the correct type to support
simple ascii strings (`[]u8`) or utf-8 strings (`[]u21`).
Moved implementation from example/input as a standalone `Element`
implementation, which is directly used by the example instead.
The provided argument is the `App.Event`'s event that should be
triggered on acceptance for the contents of the Input `Element`.
Currently only `[]u21` strings are supported, but in the future also
`[]u8` strings shall be supported and automatically converted when
pushed as an `App.Event` into the app's queue.
The other examples did rendering based on events, which this renderer
does not. This makes these applications potentially not that efficient,
but allows for consistent frame times that make animations, etc.
possible. This example serves to show that you can use `zterm` for both
types of render scheduling and even change between them without much
efford.
You can now align a `Container` using the Alignment `Element` similar to
how you make a `Container` scrollable. For usage details please see the
example and the corresponding tests.
Configuration to enable scrollbar rendering for scrollable `Element`s.
Currently only the fg `Color` of the scrollbar can be configured while
the background uses the same fg `Color` but adds the emphasis `.dim` to
make it obvious what the is the actual scrollbar. In the future it might
be necessary to provide the user with more options to configure the
representation of the scrollbar.
Tests have been added to test the scrollbar rendering and placement
accordingly.
Renamed `Container.contents` to `Container.content` to be in line with
the corresponding `Element` function name. This has also been done for
the properties structs used by the `Container`.
This could also be done through the `resize` function interface of the
`Element` or the corresponding `Container` from the outside (as done in
this example - as the size is know at compile-time).
