But do allow them to remain minimizable by a parent. This is a nice
ergonomics fix to allow a parent window to quickly minimize and
restore all its modal children.
with the CaptureInput WindowMode. This mode will serve the same
function as accessories: redirecting input while allowing parent
windows to remain active.
with the RenderAbove WindowMode. This mode will ensure child
windows always draw above their parents, even when focus is lost.
RenderAbove modals are automatically themed the same as the old
ToolWindows. Fixes ToolWindows rendering above ALL normal windows,
regardless of parent. We can't rely on WindowType to create these
sort of effects because of WindowManager's strict display hierarchy.
Menu and Window animations can now be disabled and the geometry
overlay made conditional. Shadow options are dependent on the
current theme actually supplying bitmaps, but they provide a fast
way to toggle those that do without having to edit theme files.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
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>
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.
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.
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).
We need to set Window::m_invalidated_frame to true when invalidating
the title, otherwise we may miss re-rendering the frame if nothing
else triggers it.
Calculating tiled and miximized window frame have a lot in common. In
fact, we can look at maximized window state as a special case of the
tile type. It simplifies the code since there is a lot of cases when
we take an action only if the window is maximized or tiled.
VerticallyMaximized tiling replaces set_vertically_maximized() to
take advantage of tiling ergonomics.
Middle-clicking a window's maximize button now tiles vertically;
secondary-clicking tiles horizontally.
Adds Super+Alt+Arrow shortcuts for both. Super+Left/Right tiling
shortcuts now let windows shift between tile types directly.
Briefly flash the menubar menu containing the keyboard shortcut action
to give the user immediate visual feedback on their interaction with the
system.
Render the window switcher with the same background and shadow as other
WindowServer overlays.
Note that we don't actually render it as a WindowServer::Overlay, as the
window switcher uses mouse and keyboard events, and there's currently
no way for an overlay to receive events.
Currently, if there are not titlebar buttons, we fail to paint the title
because we treat the leftmost titlebar button as the empty rect. We will
now use the rightmost edge of the titlebar when there are no buttons.
Currently, any number of menubars can be plugged in and out of a window.
This is unnecessary complexity, since we only need one menubar on a
window. This commit removes most of the logic for dynamically attaching
and detaching menubars and makes one menubar always available. The
menubar is only considered existent if it has at least a single menu in
it (in other words, an empty menubar will not be shown).
This commit additionally fixes a bug wherein menus added after a menubar
has been attached would not have their rects properly setup, and would
therefore appear glitched out on the top left corner of the menubar.
Before this change, invalidating any rect in a WindowFrame would cause
the entire window (including frame & drop shadow) to get invalidated,
leading to copious amounts of overdraw when mousing over menubars,
titlebars, and window buttons.
We now simply allow the partial frame invalidations through to the
window's dirty rects collection and the compositor takes care of it.
Because window states and various flags can affect the windows'
rendered areas it's safer to use the last computed occlusion rectangles
to invalidate areas on the screen that may have to be re-rendered due
to e.g. a window size change.
Fixes#6723
The menus always thought they were being outside of the main screen,
which caused them to be left and/or top aligned. This also fixes the
calculation of the available space by using the screen rectangle where
it will be displayed.
Since MultiScaleBitmaps only loads icons for the scales in use, we need
to unconditionally reload them so that we pick up the correct bitmaps
for a scale that hasn't been previously used.
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.
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.
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 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.
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.
