All DisplayConnectors should support the mmap interface and it should
provide better performance now, so let's just use it and drop support
for the DisplayConnector's write interface from the WindowServer side.
This function is added to separate the desktop toggling functionality
from the "Show Desktop" button in the taskbar and to enable calling this
behaviour via a keyboard shortcut in a later commit.
Previously when setting an action's icon we would only change the bitmap
stored by the action. This patch adds logic to propagate that change to
toolbar buttons as well as window menus.
This fixes an issue in SoundPlayer that would cause the play button not
to reflect the play state.
Resetting the interface just based on the fact that it already has an IP
assigned doesn't make much sense, considering that we frequently end up
here after having configured an interface via DHCP already.
Instead, just keep the part that prevents us from sending DHCP
discoveries to interfaces that shouldn't be using DHCP.
While we are at it, place some of the logging behind a debug flag, as
this function is apparently meant to be run frequently.
This partially reverts commit e14d4482a1.
When the user executes chres to change to a new resolution, the
WindowManager removes for each window its intersections with the
screens (window.screens()) and recalculates its rect. Finally, a
Window::set_rect call sets the window's new rectangle. The set_rect
call also triggers a call to Compositor::invalidate_occlusions which
fills for each window the intersections with the screens again in
window.screens().
In case chres switches to an already present resolution the set_rect
call exits prematurely as it checks if the window's rect really
changed. This means that nobody calls invalidate_occlusions
resulting in a rendering issue for each window.
Moving the call to Compositor::screen_resolution_changed after the
clearing of window.screens() and recalc of the window rect for each
window resolves the rendering issue as screen_resolution_changed
calls invalidate_occlusions.
This commit adds an IPv4Gateway to Network.ini. If that option is set to
value other than 0.0.0.0, the NetworkServer adds a default route (e.g.
with address 0.0.0.0/0) with the specified destination.
This service is responsible for loading network configuration from a
/etc/Network.ini config file. It sets up static IP address + mask or
starts DHCPClient depending on configuration.
Now, the caller needs to give interface names in command-line arguments.
The DHCPClient will perform DHCP discovery only on these adapters. The
service now immediately closes when no interfaces were given.
We don't check if interface has already IP address assigned; we just
reset it to zero so that DHCP resolution will not fail.
This became apparent when using the VirtIO graphics device, because the
HardwareScreenBackend object needs to allow flushing of the framebuffer
constantly, and due to incorrect if-else flow, even a non-error response
from the ioctl was leading to a debug spam.
This makes the wrapper more like the rest in LibCore, and also
removes the annoying limitation of not supporting arguments.
There are three overloads one for String, char const *, and StringView
argument lists. As long as there are <= 10 arguments the argv list
will be allocated inline, otherwise on the heap.
Previously, the device wasn't being created.
The new numbers correspond to those in the FullDevice (which is also
a Linux's full device number).
Also, I've tweaked the permissions to give everyone read-write access
to it.
This fixes a crash where if you switched to a theme that has hover
icons for title buttons, then back to a theme that does not. Then
when you next hover over the title buttons the window server would
crash.
This was due to the hover_bitmap multi-scale bitmap pointer being
non-null, but not containing any bitmaps, so hitting an assertion
when painting.
This is the final component that required LibProtocol as a dependency
of LibWeb. With this, we can now remove the dependency, and LibWeb no
longer requires IPC to work :^)
Much like the ImageDecoder change, this moves the underlying connection
of the Web::WebSockets class from LibWeb to LibWebView, removing the
need for LibProtocol in LibWeb for this specific use-case.
After this change, LibWeb now expects Web::ImageDecoding::Decoder to be
pre-initialized with a concrete implementation before using the webpage.
The previous implementation, based on the ImageDecoder service, has been
provided directly through an adapter in LibWebClient, and is now used as
the default value by WebContent.
Also moves WebContentClient and the references to the generated IPC
descriptions, since they are all components of OutOfProcessWebView.
This patch has no functional changes.
The compiler would complain about `__builtin_memcpy` in ByteBuffer::copy
writing out of bounds, as it isn't able to deduce the invariant that the
inline buffer is only used when the requested size is smaller than the
inline capacity.
The other change is more bizarre. If the destructor's declaration
exists, gcc complains about a `delete` operation causing an
out-of-bounds array access.
error: array subscript 'DHCPv4Client::__as_base [0]' is partly outside
array bounds of 'unsigned char [8]' [-Werror=array-bounds]
14 | ~DHCPv4Client() = default;
| ^
This looks like a compiler bug, and I'll report it if I find a suitable
reduced reproducer.
When user code requests the current cursor theme name with
`GUI::ConnectionToWindowServer::the().get_cursor_theme()`, that reads
the name from the config file. If we don't write that out when it's
changed, then users get given an outdated cursor theme instead of the
current one.
In particular, changing the theme in MouseSettings, saving and closing
it, then reopening MouseSettings, would show the wrong theme selected.
So, that's fixed now. :^)
Now, when windows flash, the "active" color of the window title frame's
flash is the highlight color instead of the standard window color. The
"inactive" color of the flash is still the disabled color as before.
Reasoning behind this change in aesthetics: There are four [1] window
title frame colors with specific UI purposes:
1. "Active" for the normal active window, obvious purpose.
2. "Moving" for the window that is being dragged or resized by the user.
Responsible for acting as a visual click feedback as a kind of
subdued button.
3. "Inactive" for any inactive windows, obvious purpose.
4. "Highlight".
The purpose of "Highlight" is in the name, though it's non-obvious what
that exactly entails. Before, only alt-tab selecting windows would use
the highlight color for showing the current target window. In my opinion
this points to the purpose of "highlight" being to move the user's focus
to another window when the simple active state is not enough. Then it
makes sense to have the window flashing use the highlight color. The
entire purpose of window flashing is to shift the user's focus to a
dialog window that might not be close to the window they just clicked.
Using the highlight color enables an even stronger emphasis than before.
It enables a cleaner separation between the purpose of the two frame
colors, as well as making the "Highlight" frame more common.
[1] Technically there are eight, as the title frame has a gradient by
default. We can count the gradient as one color for this purpose.
Multiply the cursor position by the current scaling mode multiplier when
getting the color under the cursor. Also multiply the screen rectangle
before checking if the cursor is within bounds.
Color picker would not account for scaling when getting the color under
the cursor.
Fixes#13906.
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.
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.
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.
Unconditionally adding the item height offset to the adjusted vertical
position of a menu leads to an incorrect position if we previously
clamped the translation offset so the menu doesn't go off-screen.
Also add some comments to this coordinate math. Always add comments to
coordinate math.
This ioctl is more appropriate when the hardware supports flushing of
the entire framebuffer, so we use that instead of the previous default
FB_IOCTL_FLUSH_HEAD_BUFFERS ioctl.
Such mechanism will be used by the Intel Graphics driver, because we
lack support of changing the resolution on this driver currently, so,
when WindowServer will try to mode-set the display then it will fail,
and will use the safe mode-setting call instead to be able to show
something on screen.
The file is now renamed to Queue.h, and the Resampler APIs with
LegacyBuffer are also removed. These changes look large because nobody
actually needs Buffer.h (or Queue.h). It was mostly transitive
dependencies on the massive list of includes in that header, which are
now almost all gone. Instead, we include common things like Sample.h
directly, which should give faster compile times as very few files
actually need Queue.h.
This allows adding "-hover.png" variants of the title button icons.
This can be useful for themes which use the TitleButtonsIconOnly
flag, which otherwise don't have a way of showing the hover state.
This will allow using the console tty and WindowServer regardless of
your kernel command line. Also this fixes a bug where, when booting in
text mode, the console was in graphical mode, and would not accept
input.
