- HighlightWindow text and strip colors now dark blue.
- MovingWindowShadow color made lighter, so that it's more visible.
- RubberBand now has silver colors.
Also removes mrsh from the list of ports missing descriptions. I tried
to be descriptive about the patches, but as I picked this port up from
someone else, I'm not 100% sure how to best explain the patches.
Using a Vector<Value> is unsafe as GC cannot see the stored values.
This is then vended to outside users of ConsoleClient, e.g. LibWeb and
WebContent, which is then outside of LibJS's control.
An example issue is if the client stores it for later use and forgets
to visit the stored values, meaning they can be destroyed at any time.
We can save the client from this by vending a MarkedVector<Value> to
them.
Physical hardware doesn't care about scale factors as this is a concept
being related to WindowServer and userland applications. To ensure we
provide the correct display resolution details to HardwareScreenBackend
objects, we must keep a separate Gfx::IntRect object that reserve the
correct details.
There was an awful lot of JS::Value <-> double conversion going on, even
through these AOs only work with number values anyway.
They don't need a global object either as they won't allocate or throw,
that was simply to pass it to infallible calls of ToIntegerOrInfinity.
In many cases we already know a certain value is a number, or don't have
JS values at all and would need to wrap doubles in a value. To optimize
these cases and avoid having to pass a global object into functions that
won't ever allocate or throw, add a standalone implementation of this
function that takes and returns doubles directly.
This fixes a weird bug that when sometimes a user tried to switch to
console mode, the screen was frozen on graphics mode. After a hour of
debugging this, it became apparent that the problem was that we left the
y offset of the bochs graphics device in an invalid state, so it was not
zero because the WindowServer changed it, and the framebuffer console
code is not aware of horizontal and vertical offsets of the framebuffer
screen, leading to the problem that the framebuffer console updates the
first framebuffer (y offset = 0), but hardware was indicated to show the
second framebuffer (y offset = first framebuffer height).
Therefore, when doing a switch between these modes, always set the y
offset to be zero.
This hack is not necessary anymore, because WindowServer will try
constantly to write the framebuffer contents to the display connector
devices. After a switch from console mode to graphical mode, the write
syscall on these devices will not be silently ignored but will actually
write to the framebuffer screen.
This let us test the VMWare SVGA adapter easily. We already use the std
vga (which is compatible with bochs-display that only lacks VGA support)
on the i440FX QEMU machine so we keep testing it there too, and on the
Q35 machine we use a bochs-display device as secondary display.
Since the layout_box of a SVGGraphicsPaintable is already casted to the
right type, the underlying dom_node was also always of the right type.
This triggers a warning on Lagom builds.
This was changed a while ago so the generated files are placed in the
Build directory. Let's remove the gitignore file so any old version of
the files stop conflicting with the new generated versions.
As the framebuffer devices are gone by now, searching for them makes no
sense, so instead, let's remove this check now. If the user requested to
boot into text mode, he probably knows what he is doing and we should
not try to warn him about this.
This implements the "close modified" icon on the terminal,
as well as several close warnings:
- A warning there is a foreground process running
- If there is a background process running
- Or if there are multiple background processes running
Fixes#13751
This exposes the child processes for a process as a directory
of symlinks to the respective /proc entries for each child.
This makes for an easier and possibly more efficient way
to find and count a process's children. Previously the only
method was to parse the entire /proc/all JSON file.
Instead of just printing 'ECMAScriptFunctionObject' (and leaking an
implementation detail in the process - this is not a public facing name)
let's instead print a different type string for each function kind, and
only keep the old class_name() printing for other JS::FunctionObject
subclasses.