ply_utf8_character_get_size currently has this odd argument at
the end that is often just set to PLY_UTF8_MAX_CHARACTER_SIZE
and also the function returns magic values for cases where it
can't figure out the size because the byte isn't a leading
byte or is otherwise not valid UTF-8.
That means that API has a nuance to it that makes the code hard
to follow at a light read.
This commit attempts to improve the situation by dropping the
extra argument, and adds a way to get the type separate from the
size for clarity.
At the same time, this commit updates all the callers to use the
new API. There are two cases where the callers are trying to
remove the last character from a UTF-8 string, so this commit
adds a new function to consolidate that logic as well.
This commit adds a few functions for getting at and
using the size, bytes, and capacity of a buffer.
This will make it easier to modify the string on the side and
and update the size afterward.
At the moment injecting data into a console viewer involves calling
ply_console_viewer_parse_lines.
This name isn't optimal, since the data getting injected might not
be a full line at all.
This commit renames it to ply_console_viewer_write, and also adds
a ply_console_viewer_print that adds a printf like function for
convenience.
Some commands really do need to know how wide the terminal is to operate correctly. Without
it long lines don't wrap right and other badness can happen.
This commit addresses the problem by changing the terminal to take both a `number_of_rows`
and `number_of_columns` argument at construct time instead of just a `maximum_line_count`.
In order to properly implement that change, this commit also adds new api to `ply_rich_text_t`
to specify which parts of a run of rich text is read-only and which parts of the run can be
modified.
Changes in this commit were made with assistance from Ray Strode
At the moment, holding down the shift key sends
key repeat events that lead to the output not
getting properly shifted.
This commit avoids updating modifier state when
the modifer key is held down.
Right now we don't have a lot of debugging information when processing
keyboard events. I mean we don't want passwords to show up in logs
after all.
Still, it would be useful to have a way to turn the valve on to the
firehose.
This commit adds a plymouth.debug-input-devices kernel option.
If the kernel falls behind a stream of input events, we currently
drop them on the floor.
It seems unlikely that this could ever happen theorhetically since we only
process keyboard events (versus, say, a high frequency stream of pointer
events, or a complex stylus device with inter-related events coming in,
in batches). Nonetheless, there is a report that suggests key events
may be getting dropped.
This commit adds support for handling the backlogged event case, and
hopefully address the bug report.
There are a few files missing #include <config.h>.
That is bad since it means those files don't get debug tracing.
This commit eliminates the pitfall by making sure the file is
included implicitly
rand() and srand() are we use now and it's not working out too well
because we're seeding correctly in a number of places.
This commit adds one function to do it better.
Problem spotted by @emperor06
Support for displaying logs from /dev/kmsg and the console on the screen, instead of relying on the text on the VT
See merge request plymouth/plymouth!224
We need to know two things:
1. What log level threshold to follow when showing kernel messages to
the console
2. What log level to use if a message comes in without a log level
This commit adds a new function `ply_get_kmsg_log_levels` that
returns those two values.
Now that the ply-label interface supports rich text, we need to
implement it in the plugins.
This commit changes the freetype plugin to process
rich text in a rudimentary way that picks up colors, but not other
style attributes.
Based on initial work from nerdopolis
The plugin currently assumes all characters are 7 byte ascii.
This commit just adds a mbrtowc call around the text to
handle UTF-8 text somewhat better.
