| Age | Commit message (Collapse) | Author |
|---|
|
There is no reason for callers to mutate the shadow bitmaps returned by
this function.
|
|
Specifically, this is to make it accessible to ThemeEditor, but there's
nothing about it that is especially window-specific.
|
|
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.
|
|
Clean up a FIXME about overly aggressive invalidation.
|
|
If the shadow bitmap contains portions of the frame then we need to
slightly tweak the logic dealing with very small width and/or height.
|
|
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.
|
|
Break this function into a couple of smaller functions, one for each
of these areas:
- The titlebar
- The titlebar icon
- The menubar
- The border
|
|
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.
|
|
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.
|
|
We were not substituting the window modified marker ("[*]") in the
title strings we were sending to WM clients. This caused the Taskbar
to show pre-substitution window titles for the Text Editor application.
This patch moves the window title resolution to Window::compute_title()
which is then used throughout.
|
|
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
|
|
|
|
This patch adds support for opening menus via keyboard shortcuts.
Use an ampersand in a menu name to automatically create a keyboard
shortcut (Alt + the character following the ampersand.)
Menus with an Alt shortcut have a small underline under the shortcut
character for discoverability.
|
|
This patch begins the transition away from the global menu towards
per-window menus instead.
The global menu looks neat, but has always felt clunky, and there
are a number of usability problems with it, especially in programs
with multiple windows.
You can now call GUI::Window::set_menubar() to add a menubar to
your window. It will be specific to that one window only.
|
|
Tool windows are secondary windows with a smaller title bar. The sit on
the layer above normal windows, and cannot be minimized.
These are intended for complex yet non-modal interactions with the
content of a primary window, such as find/replace windows, property
windows, etc.
|
|
This enables implementing non-rectangular window shapes, including
non-rectangular window frames.
|
|
This fixes some issues handling the alpha channel that may be present
in rendered window frames.
Fixes #5303
|
|
Also allow specifying different shadows for the task and menu bar.
|
|
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.
|
|
Also update the Redmond 2000 theme to drop shadows more Redmond-like.
|
|
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.
|
|
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.
|
|
This only renders the window frame once until the size of the window
changes, or some other event requires re-rendering. It is rendered
to a temporary bitmap, and then the top and bottom part is stored
in one bitmap as well as the left and right part. This also adds
an opacity setting, allowing it to be rendered with a different
opacity.
This makes it easier to enhance window themes and allows using
arbitrary bitmaps with e.g. alpha channels for e.g. shadows.
|
|
If a window frame has transparency, include these areas in the
transparency rendering area so that we can render them flicker-free.
|
|
|
