When selecting the start of a multi-line line, a selection rect was
displayed for the whole line but the text wasn't rendered properly.
This change prevents the selection rect from being drawn in virtual
lines with no selected characters.
We were letting the automatic scrolling timer drive all selection
updates to fix an unwanted acceleration that was happening. However,
if a mousemove occurs *within* the editor widget, we should just
handle it right then and there.
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.
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. :^)
This patch adds GUI::Action::create_checkable() helpers that work just
like the existing create() helpers, but the actions become checkable(!)
Clients are no longer required to manage the checked state of their
actions manually, but instead they will be checked/unchecked as needed
by GUI::Action itself before the activation hook is fired.
This little tweak fixes the issue where the scrolling speeds up
significantly if the user wiggles their cursor. Just something obvious
I spotted while watching the video :^)
Previously, TextEditor processed the Select all command directly on the
keydown event handler. For this reason, WindowManager would not process
it as an action for the focused control and an action with the same
keyboard shortcut from the parent could override the TextEditor's one
even when it is focused.
For instance, when pressing Ctrl+A on the FileManager's path bar, all
files were selected instead, which is not the expected behavior.
Now the Select all command is an actual action on TextEditor, so that
WindowManager can process it correctly before any other actions. I also
added an icon for it!
If you select some text and drag the cursor outside the widget on the
left hand side, we would previously suddenly snap the selection cursor
to the end of the line instead of keeping it at the start of the line
as you would expect. This patch fixes that. :^)
If you start selecting text and move the cursor outside the TextEditor
widget area without letting go of the mouse button, we will now keep
scrolling a little bit every 100ms.
Previously, drag and drop would only work when dragging between node
items on a DirectoryView. This commit makes it possible to drag files to
the empty area of the DirectoryView and copy files more easily between
windows.
This API is used to open a URL in whatever way the desktop system feels
is best. If you give it a file:// URL, it will try to work out a good
application to open the URL with. For all other protocols, it will open
a Browser instance. :^)
For some reason this was trying to access the Palette of the parent
widget which is obviously not going to work if the ItemView itself is
the main widget in its window.
If the area or size_in_bytes calculation for a Gfx::Bitmap would
overflow, we now refuse to create such a bitmap and return nullptr.
Thanks to @itamar8910 for finding this! :^)
