Splitters were slightly oversized to work around the fact that we
were ignoring 2px on both sides of them. Now that the whole splitter
can be interacted with, we can lose 1px of fat and look great! :^)
A GUI::Widget can now set an optional content margin (4x0 by default.)
Pixels in the content margin will be ignored for hit testing purposes.
Use this to allow frame-like widgets (like GUI::Frame!) to ignore any
mouse events in the frame area, and instead let those go to parent.
This allows GUI::Splitter to react "sooner" to mouse events that were
previously swallowed by the child widgets instead of ending up in the
splitter. The net effect is that 2 more pixels on each side of a
splitter handle are now interactive and usable for splitting! :^)
Instead of only looking in the focused widget, we now also look in the
ancestor chain of that widget for any ancestor with a registered action
for the given shortcut.
This makes it possible for parent widgets to capture action activations
while one of their children is focused.
This is required for template literals - we're not quite there yet, but at
least the parser can now tell us when this token is encountered -
currently this yields "Unexpected token Invalid". Not really helpful.
The character is a "backtick", but as we already have
TokenType::{StringLiteral,RegexLiteral} this seemed like a fitting name.
This also enables syntax highlighting for template literals in the js
REPL and LibGUI's JSSyntaxHighlighter.
`read_bool_entry()` can now interpret both integers (1 or 0) and
Boolean strings ("true" or "false") in configuration files.
All values other than "1" or "true" are considered false.
- Let undefined variables throw a ReferenceError by using
Identifier::execute() rather than doing variable lookup manually and
ASSERT()ing
- Coerce value to number rather than ASSERT()ing
- Make code DRY
- Add tests
The original implementation only sent out notifications when there was
something being drawn on screen. If nothing was going on, we'd get too
lazy and just not notify display links.
This obviously break requestAnimationFrame(), so now we just drive the
DisplayLinks at 60 fps no matter what. :^)
