This enables the shot utility to capture all screens or just one, and
enables the Magnifier application to track the mouse cursor across
multiple screens.
This enables rendering of mixed-scale screen layouts with e.g. high
resolution cursors and window button icons on high-dpi screens while
using lower resolution bitmaps on regular screens.
This sets the stage so that DisplaySettings can configure the screen
layout and set various screen resolutions in one go. It also allows
for an easy "atomic" revert of the previous settings.
If there are any screens that are detached from other screens it would
not be possible to get to them using the mouse pointer. Also make sure
that none of the screens are overlapping.
We were calculating the old window rectangle after changing window
states that may affect these calculations, which sometimes resulted
in artifacts left on the screen, particularily when tiling a window
as this now also constrains rendering to one screen.
Instead, just calculate the new rectangle and use the window's
occlusion information to figure out what areas need to be invalidated.
When a window is maximized or tiled then we want to constrain rendering
that window to the screen it's on. This prevents "bleeding" of the
window frame and shadow onto the adjacent screen(s).
This allows WindowServer to use multiple framebuffer devices and
compose the desktop with any arbitrary layout. Currently, it is assumed
that it is configured contiguous and non-overlapping, but this should
eventually be enforced.
To make rendering efficient, each window now also tracks on which
screens it needs to be rendered. This way we don't have to iterate all
the windows for each screen but instead use the same rendering loop and
then only render to the screen (or screens) that the window actually
uses.
Some paths of the mouse event processing code will upgrade the event
from a regular MouseDown to a MouseDoubleClick. That's why we were
passing `MouseEvent&` everywhere.
For the paths that don't need to do this, passing `MouseEvent const&`
reduces the cognitive burden a bit, so let's do that.
Instead of plumbing a Window* through the entire mouse event processing
logic, just do a hit test and say that the window under the cursor is
the hovered window.
It's funny how much easier this is now that we have a way to hit test
the entire window stack with one call.
Move the logic for processing a mouse event that hits a specific window
into its own function.
If the window is blocked by a modal child, we now get that out of the
way first, so we don't have to think about it later.
Even if a window is in fullscreen mode, we still want hit testing to
walk the window stack. Otherwise child windows of the fullscreen
window will not receive mouse events.
The button widgets internally rendered by WindowServer are only used
in titlebars, and require a bit of mouse event handling. Instead of
mixing it with the window-oriented mouse event handling, get the
button event stuff out of the way first.
We were forgetting to preserve the m_drag and m_mime_data members of
WindowServer::MouseEvent when making a translated copy.
This didn't affect any reachable code paths before this change.
If a window is currently actively tracking input events (because
sent it a MouseDown and haven't sent it a MouseUp yet), we now simply
send mouse events to that window right away before doing any other
event processing.
This makes it much easier to reason about mouse events.
Instead of just answering hit/no-hit when hit testing windows, we now
return a HitTestResult object which tells you which window was hit,
where it was hit, and whether you hit the frame or the content.
This feature had been there since early on and was not actually useful
for anything. I just added it because it was fun. In retrospect, it's
not a very good feature and I only ever activated it by accident.
This patch moves the window stack out of WindowManager and into its own
WindowStack class.
A WindowStack is an ordered list of windows with an optional highlight
window. The highlight window mechanism is used during Super+Tab window
switching to temporarily bring a window to the front.
This is mostly mechanical, just moving the code to its own class.
Remove the confusingly-named inflate_for_shadow() function and inline
its logic into render_to_cache(). And remove the m_shadow_offset
member variable since it was only needed locally in one place.
Also improve some variable names to make it more understandable what
is going on.
Let clients manage their own window ID's. If you try to create a new
window with an existing ID, WindowServer will simply disconnect you
for misbehaving.
This removes the need for window creation to be synchronous, which
means that most GUI applications can now batch their entire GUI
initialization sequence without having to block waiting for responses.
This patch moves the magnifier rect computation over to the server side
to ensure that the mouse cursor position and the screen image never get
out of sync.
By moving the logic to determine what window areas (shadow, frame,
content) into WindowFrame::opaque/transparent_render_rects we can
simplify the occlusion calculation and properly handle more
arbitrary opaque/transparent areas.
This also solves the problem where we would render the entire
window frame as transparency only because the frame had a window
shadow.
This replaces ctype.h with CharacterType.h everywhere I could find
issues with narrowing conversions. While using it will probably make
sense almost everywhere in the future, the most critical places should
have been addressed.
Previous to this commit, if a `Window` wanted to set its width or height
greater than `INT16_MAX` (32768), both the application owning the Window
and the WindowServer would crash.
The root of this issue is that `size_would_overflow` check in `Bitmap`
has checks for `INT16_MAX`, and `Window.cpp:786` that is called by
`Gfx::Bitmap::create_with_anonymous_buffer` would get null back, then
causing a chain of events resulting in crashes.
Crashes can still occur but with `VERIFY` and `did_misbehave` the
causes of the crash can be more readily identified.
Use the configured desktop background color, if defined, otherwise
default to the current theme's background color. If a user chooses
a background color via "desktop settings", then this new color
will always be used.
Switching themes will delete the user-defined background color, so
the background color resets to the theme's defined color.
Instead of using a low-level, proprietary API inside LibGfx, let's use
Core::AnonymousBuffer which already abstracts anon_fd and offers a
higher-level API too.