Merely moving a window shouldn't require re-rendering the window
frame anymore now that we cache the rendered frame in bitmaps. This
reduces CPU usage significantly when moving windows.
Text <input> fields will now generate a basic shadow DOM and attach it
to the input element.
The shadow DOM contains a <div> with some inline style, and an always-
editable text node inside it. Accessing the "value" attribute on such
an input element will get/set the value from that text node.
This is really cool, although not super stable since HTML editing is
not super stable. But it's a start! :^)
Elements with shadow roots will now recurse into those shadow trees
while building the layout tree.
This is the first step towards basic Shadow DOM support. :^)
The approach of attaching sub-widgets to the web view widget was only
ever going to work in single-process mode, and that's not what we're
about anymore, so let's just get rid of WidgetBox so we don't have the
dead-end architecture hanging over us.
The next step here is to re-implement <input type=text> using LibWeb
primitives.
We'll want to remove the LibGUI dependency from the WebContent process.
This is the first basic step of removing unnecessary LibGUI includes
and swapping out GUI::Painter for Gfx::Painter.
We weren't properly handling switching between having a shadow and
not having a shadow when switching themes. This allows an empty string
in the theme configuration for a shadow path, meaning no shadow should
be rendered.
There's no point in using different, seemingly randomly sized buffers as
the required size for storing an IPv4 address representation is well
known (16 bytes).
The WebContent process was redoing page layout every time you scrolled
the page. This was a huge CPU hog for no reason. Fix this by only doing
a relayout when the viewport is resized, not when it moves around.
Button now can handle middle and right clicks.
Added 2 new handlers in button class: on_right_click for Right mouse
button and on_middle_click for middle mouse button.
Added functionality to vertically maximize window with middle mouse
click on the maximize window button.
Also added a way to vertically maximize window by resizing window
height-wise lower than the maximum window height.
Since theme changes may change geometrics, which are also affected by
window shadows, we need to recompute occlusions as well as re-render
window frames.
Also stop exposing the DOM cursor as a mutable reference on Frame,
since event handling code was using that to mess with the text offset
directly. Setting the cursor now always goes through the Frame where
we can reset the blink cycle appropriately.
This makes cursor movement look a lot more natural. :^)
gimp claimed that the rightmost white pixel was actually transparent.
It didn't look transparent in Serenity, but I painted it white like
the other inner pixels anyways.
I upsampled them in gimp using the "None" filter and manually cleaned up
the outline. The drop shadow is just upsampled using "None" and looks a
bit rough -- someone who knows how to do this either has to re-create
the shadow on the 2x bitmaps, or we need to remove the shadow from the
resource and render it in code at some point. Still, looks a lot better
than with the upsampled 1x bitmaps.
sys$fork() already takes care of children inheriting the parent's root
directory, so there was no need to do the same thing when creating a
new user process.
We only really need to re-render the simple window shadow when
the size of the frame changes. So, for all other cases only re-render
the window frame without rendering the shadow.
This implements simple window shadows around most windows, including
tooltips. Because this method uses a bitmap for the shadow bits,
it is limited to rectangular window frames. For non-rectangular
window frames we'll need to implement a more sophisticated algorithm.
... and performs preprocessing on the source code before parsing.
To support this, we are now able to keep track of multiple
files in the autocomplete engine. We re-parse a file whenever it is
edited.
FileDB wraps the access to the contents of project files.
When asked to fetch a file, FileDB will either return its in-memory
model of the file if it has been "opened" by the language-server
protocol, or otherwise fetch it from the filesystem.
Previously, the cpp language server did not pledge "rpath" and got
access to the contents of files whenever they were opened by the
language client.
However, features like inspection of header files require the language
server to get the content of files that were not opened by the client.
The language server now pledges rpath but makes sure to only unveil
the project's directory and /usr/include.