This patch adds GUI::FocusEvent which has a GUI::FocusSource.
The focus source is one of three things:
- Programmatic
- Mouse
- Keyboard
This allows receivers of focus events to implement different behaviors
depending on how they receive/lose focus.
Using a command-line argument for this clashed with ArgsParser so let's
use an environment variable instead. I feel like Sergey told me to do
this at some point anyway. :^)
You can now cycle through focusable elements (currently only hyperlinks
are focusable) with the Tab key.
The focus outline is rendered in a new FocusOutline paint phase.
Decorated Interpreter::call() with [[nodiscard]] to provoke thinking
about the returned value at each call site. This is definitely not
perfect and we should really start thinking about slimming down the
public-facing LibJS interpreter API.
Fixes#3136.
This now descibes how to get the regular `make run` workflow to work
under Windows using native QEMU. It describes how to override the QEMU
binary path, as well as overriding the SerenityOS disk image file
location with a native Windows path.
Also fixes some minor spelling and punctuation issues.
Introduces a SERENITY_QEMU_CPU environment variable that allows
overriding of the qemu -cpu command line parameter. If not specified,
the argument defaults to "max".
The primary motivation behind this is to be able to enable or disable
specific features for the vCPU in order to workaround QEMU issues with
certain hardware accelerators. For example, QEMU on Windows with WPHX
sometimes fails to start unless Virtual Machine eXtensions are
disabled. This can now be done with:
export SERENITY_QEMU_CPU="max,vmx=off"
This is being used in match_identifier_name(), for example when parsing
property keys - the list was incomplete, likely as some token types were
added later, leading to some unexpected syntax errors:
> var e = {};
undefined
> e.extends = "a";
e.extends = "a";
^
Uncaught exception: [SyntaxError]: Unexpected token Extends. Expected IdentifierName (line: 1, column: 3)
Fixes#3128.
This finally makes tooltips on menu applets the same as everywhere else!
Here's what went wrong:
WindowManager::process_mouse_event() receives a Window*&, determines the
hovered window and sets it accordingly. However there's a branch that
tests for menubar_rect().contains(event.position()) and returns early -
which resulted in hovered_window never being set to any MenuApplet
window, even hovered ones.
The hovered_window result is being used in WindowManager::event() and
passed to WindowManager::set_hovered_window(), which is responsible for
creating WindowLeft and WindowEntered events when the hovered window
changes, as a result of the mentioned chain of events this also never
happens for MenuApplet windows.
The WindowLeft event would the cause Window::handle_left_event() in
LibGUI to be called, which unsets the window's hovered widget, which
is necessary for the widget to receive a subsequent Enter event -
again, all of this never happened.
Now it's working as expected though, so we can start using tooltips on
menu applets :^)
This was using window()->position(), which is unset for windows with
WindowType::MenuApplet. Now it checks the window type and then uses
rect_in_menubar() for MenuApplet windows and rect() for everything else.
This makes tooltips show up for MenuApplet windows, previously they were
positioned off-screen :^)
Cuts time needed for `disasm /bin/id` from 2.5s to 1s -- identical
to the time it needs when not doing the random adjustment at all.
The downside is that it's now very easy to get the random offsets
with out-of-bounds reads, so it does make this mitigation less
effective.
If the space cannot be allocated, the original memory block shall remain
unchanged and the function should return nullptr.
Also add a function attribute and some null checks.
This change aims to add support for obscure IPv4 address notations, such as 1.1 (which should be equal to 1.0.0.1), or the hypothetical address 1 (which is equal to 0.0.0.1). This is supported on other platforms as well, such as Linux, Windows, *BSD, and even Haiku.
Previously the ColorPicker would get the custom color directly from the
window, this was changed in d7d5788469 to
get the color from the underlying bitmap instead - without taking the
bitmap's scaling into effect though, so resulting colors were off by
quite a bit.
Fixes#3113.
Subtracting 128 from the desktop rect's height was far to much and
and leading to weird rendering issues - now it's calculated exactly from
taskbar and menubar heights as well as a little additional offset to
make it fit perfectly.
Fixes#3115.
