We only need to fire these callbacks when we want to change the palette.
So, when setting widget values to match a palette that has just been
loaded, or to show the value of the role selected in a ComboBox, we can
skip the callbacks. This saves some work, and means we can reliably use
on_palette_change to know when the palette has actually been modified.
There are two different things in ThemeEditor that want to know when a
palette changes:
1. The PreviewWidget subclass, so it can update its preview.
2. The ThemeEditor itself, so we know that the palette is modified.
Using a protected virtual function for 1 means that we can do 2 without
them fighting over the same on_palette_change callback.
The `TextEditor::on_change` callback now only fires if the user types in
the box, or `set_text()` is called with `AllowCallback::Yes`.
Previously that callback was what set `m_color`, so I've rearranged
things a little so that the color still updates regardless of what
source the color came from.
This will allow using the console tty and WindowServer regardless of
your kernel command line. Also this fixes a bug where, when booting in
text mode, the console was in graphical mode, and would not accept
input.
...and change how the two parsing steps fit together.
The two steps were previously quite muddled. Both worked with the
TokenStream directly, and both were responsible for rewinding that
stream if there was an error. This is both confusing and also made it
impossible to replace the rewinding with StateTransactions.
This commit more clearly divides the work between the two functions: One
parses ComponentValues and produces a string, and the other parses that
string to produce the UnicodeRange. It also replaces manual rewinding
in the former with StateTransactions.
This should be a bit easier to follow.
parse_media_query() no longer rewinds if the media query is invalid,
because it then interprets all the tokens as a "not all" query.
This is modeled after the one in ISO8601Parser. It rolls back the
TokenStream state automatically at the end of scope unless told to
commit the changes. This should be less error-prone than remembering to
manually call `rewind_to_position()` at the correct time.
For convenience, a StateTransaction can have "child" transactions. When
a transaction is committed, it automatically commits its parents too.
This is useful in situations where you have several nested and don't
want to have to remember to manually `commit()` them all.
`a` and `b` had to be declared at the top of the function before since
they were used by the `make_return_value()` lambda. But now that
doesn't exist, we can move them to where they are used - or eliminate
them entirely.
parse_a_n_plus_b_pattern()'s job is to parse as much of the TokenStream
as it can as a An+B, and then stop. The caller can then deal with any
trailing tokens as it wishes.
...using a ParseErrorOr type alias.
This lets us replace a bunch of manual error-checking with TRY. :^)
I also replaced the ParsingResult::Done value with returning an
Optional. I wasn't happy with treating "Done" as an error when I first
wrote this, and this makes a clear distinction between the two.
Using ~~text~~ syntax will strike out the text between the two tildes.
Only missing portion is the terminal rendering of strike through text.
The ansi escape codes for strike through text are \e[9m and \e[29m but
it appears the terminal does not support these. Please correct me if I
am wrong.
I tested that the render_to_terminal function was being called by giving
it bold ANSI escape codes, and that did work so the function is being
called correctly.
That code used the old AK::Result container, which leads to overly
complicated initialization flow when trying to figure out the correct
partition table type. Instead, when using the ErrorOr container the code
is much simpler and more understandable.
Previously the system had no concept of assigning different routes for
different destination addresses as the default gateway IP address was
directly assigned to a network adapter. This default gateway was
statically assigned and any update would remove the previously existing
route.
This patch is a beginning step towards implementing #180. It implements
a simple global routing table that is referenced during the routing
process. With this implementation it is now possible for a user or
service (i.e. DHCP) to dynamically add routes to the table.
The routing table will select the most specific route when possible. It
will select any direct match between the destination and routing entry
addresses. If the destination address overlaps between multiple entries,
the Kernel will use the longest prefix match, or the longest number of
matching bits between the destination address and the routing address.
In the event that there is no entries found for a specific destination
address, this implementation supports entries for a default route to be
set for any specified interface.
This is a small first step towards enhancing the system's routing
capabilities. Future enhancements would include referencing a
configuration file at boot to load pre-defined static routes.
