This allows us to make sure that those operations are performed
in the right order. Affected functions are:
- add_window_stealing_for_client
- set_window_parent_from_client
- remove_window_stealing_for_client
- remove_window_stealing
Adds some logic to reposition menus that would appear off the right or
bottom edge of the screen so they appear completely on screen.
Co-authored-by: Sam Atkins <atkinssj@gmail.com>
Rather than enabling/disabling cursor highlighting by going into mouse
settings, you can now instead toggle it any time with Super+H. Mouse
settings now is only for customising the look of the highlighting.
Simply setting m_current_cursor in current_cursor_was_reloaded() does
not setup the cursor animation, that has to be done in change_cursor().
This also fixes the cursor disappearing after switching from an animated
cursor back to a normal one (which was due to it trying to draw a cursor
frame that did not exist).
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.
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.
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 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 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.
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.
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.
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.
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.
With this flag set to true only the icon of the title button is painted.
This is useful for themes with a more non-serenity look such as
Coffee and Cupertino (that currently try to hide the button).
This screen backend is just memory-backed and doesn't connect to any
screen hardware. That way, we can boot Serenity without video hardware
but in full graphical mode :^)
To create a virtual screen, put something like this in your
WindowServer.ini. There's no way yet to do this through Display
Settings, though an existing virtual screen's settings can be changed
there.
```ini
[Screen0]
Mode=Virtual
Left=1024
Top=0
Width=1920
Height=1080
ScaleFactor=1
```
This will allow us to change between a couple of properties, for now
it's only Device and Virtual. (How about Remote :^) ) These get handled
by a different screen backend in the Screen.
The ScreenBackend is a thin wrapper around the actual screen hardware
connection. It contains all the variables specific to that hardware and
abstracts away operations that deal with controlling the hardware. The
standard ScreenBackend implementor is HardwareScreenBackend, which
contains all the existing frame buffer & ioctl handling code of Screen.
I took this opportunity to introduce ErrorOr wherever sensible.
This was very badly named. All that the "FBData" struct contains is the
currently to-be-flushed rectangles plus a fullness flag, so it should
better be called FlushRectData. This rename is similarly applied to all
variable names.
Previously, GUI::Window::is_maximized() had to make a synchronous IPC
request to WindowServer in order to find out if the window was indeed
maximized.
This patch removes the need for synchronous IPC by instead pushing the
maximization state to clients when it changes.
The motivation for this change was that GUI::Statusbar was checking
if the containing window was maximized in its resize_event(), causing
all windows with a statusbar to block on sync IPC *during* resize.
Browser would typically block for ~15 milliseconds here every time
on my machine, continuously during live resize.
With this change you can now set the theme and background color at the
same time in the Display Settings. Before if both were changed
before hitting 'apply' the theme background color would overwrite
the custom background.
This is useful, for instance, in games in which you can switch held
items using the scroll wheel. In order to implement this, they
previously would have to either add a hard-coded division by 4, or look
up your mouse settings to adjust correctly.
This commit adds an MouseEvent.wheel_raw_delta_x() and
MouseEvent.wheel_raw_delta_y().
If an Animation's on_stop handler cleared itself inside the on_stop
event handler, it would remove itself from the animation map that was
still being iterated, leading to a crash.
To solve this, we'll iterate over the animations using the
remove_all_matching function, which enables us to delete it by simply
returning true when the animation finished. In the event that the
Animation is kept alive elsewhere and the on_stop event clears its own
reference, we need to temporarily bump the reference count. Another
advantage is that we only need to bump the reference count when an
animation is finished, whereas before this we bumped it
unconditionally.
`static const` variables can be computed and initialized at run-time
during initialization or the first time a function is called. Change
them to `static constexpr` to ensure they are computed at
compile-time.
This allows some removal of `strlen` because the length of the
`StringView` can be used which is pre-computed at compile-time.
The ARGB32 typedef is used for 32-bit #AARRGGBB quadruplets. As such,
the name RGBA32 was misleading, so let's call it ARGB32 instead.
Since endianness is a thing, let's not encode any assumptions about byte
order in the name of this type. ARGB32 is basically a "machine word"
of color.
