The old `GUI::Window` resizing behavior created a new backing store for
each resize event (i.e. every visible window size). This caused a lot of
trashing and on my machine, caused up to 25% of CPU time spent in
creating new backing stores.
The new behavior is a bit more sensible:
* If the window size is shrinking, the backing store is already large
enough to contain the entire window - so we don't create a new one.
* If the window size is growing, as soon as the backing store can no
longer contain the window, it is inflated with a large margin (of an
arbitrary chosen 64 pixels) in both directions to accommodate some
leeway in resizing before an even larger backing store is required.
* When the user stops resizing the window, the backing store is
resized to the exact dimensions of the window.
For me, this brings the CPU time for creating backing stores down to 0%.
This patch adds a visibility state to GUI::Action. All actions default
to being visible. When invisible, they do not show up in toolbars on
menus (and importantly, they don't occupy any space).
This can be used to hide/show context-sensitive actions dynamically
without rebuilding menus and toolbars.
Thanks to Tim Slater for assuming that action visibility was a thing,
which gave me a reason to implement it! :^)
Before this commit it was a bit ambiguous which buttons the function
name were referring to; this instead now makes it clear that it's
related to mouse input. Additionally, this also fixes incorrect getter
naming leftover from yesteryear.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
The hot-spots for resizing a window by dragging its corner are now
limited to a small area around the actual corner instead of an area with
1/3rd the length or width of the window.
The hot-spots to resize a window while holding a modifier key and the
right mouse button are unchanged.
Instead of letting buttons determine the relative position
of their menus, a workaround only used by Statusbar segments,
open them all uniformly for a nice, consistent UI.
Passing a rect to popup() now routes to open_button_menu(), an
analog to open_menubar_menu(), which adjusts the menu's popup
position in the same way. Fixes button menus obscuring the buttons
which spawn them and jutting out at odd corners depending on screen
position.
with the CaptureInput WindowMode. This mode will serve the same
function as accessories: redirecting input while allowing parent
windows to remain active.
Previously, Windows only understood blocking modality: Windows were
either modal, i.e., in a blocking state, or not. Windows could also
be set as Accessories or ToolWindows, attributes which technically
applied modes to their parents but were implemented ad hoc. This patch
redefines these modal effects as WindowModes and sets up some helpers.
This will let us simplify a lot of modal logic in the upcoming patches
and make it easier to build new modal effects in the future.
Windows can now set 1 of 5 modes before reification:
-Modeless: No modal effect; begins a new modal chain
-Passive: Window joins its modal chain but has no effect
-RenderAbove: Window renders above its parent
-CaptureInput: Window captures the active input role from its parent
-Blocking: Window blocks all interaction with its modal chain
States like fullscreen and tiling are dynamic and don't alter behavior
in modal chains, so they aren't included.
SystemEffects are sent to the WindowManager through
set_system_effects() and broadcast to Desktop clients with
update_system_effects(). WindowManager is reponsible for saving,
loading and rebroadcasting effects from WindowServer.ini on
config changes.
Previously we would wait for a separate message confirming that a
wallpaper got set instead of just calling a synchronous api.
I'm guessing that this was a limitation of the IPC system when
WindowServer got ported to using it.
This patch removes the SetWallpaperFinished message and updates the
set_wallpaper api to synchronously return a success boolean.
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
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.
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.
The WindowServer _really_ does not need to know the filesystem path to
it's wallpaper, and allows setting arbitrary wallpapers (those outside
of `/res/wallpapers`).
The GUI::Desktop will keep track of the path to the wallpaper (if any),
and save it to config if desired (to be persisted).
This avoids the need to `unveil` paths to the wallpaper, fixing #11158
Briefly flash the menubar menu containing the keyboard shortcut action
to give the user immediate visual feedback on their interaction with the
system.
Add option to reverse primary and secondary buttons in Mouse Settings.
- WindowServer.ini: add default entry
- switch-mouse-buttons.png: new icon for settings entry
- Mouse.gml/MouseWidget.*: new settings dialog
- ClientConnection/WindowManager/Server: window message for settings
- EventLoop.cpp: swap buttons 1 and 2 if settings are on
This allows any client to ask the WindowServer to give it the color
of the screen bitmap under the cursor.
There's currently no way to get the screen bitmap *without* the
cursor already drawn on it, so for now we just take a pixel
beside the actual cursor position to avoid just getting the cursors
color.
This feature was problematic for several reasons:
- Tracking *all* the user activity seems like a privacy nightmare.
- LibGUI actually only supports one globally tracking widget per window,
even if no window is necessary, or if multiple callbacks are desired.
- Widgets can easily get confused whether an event is actually directed
at it, or is actually just the result of global tracking.
The third item caused an issue where right-clicking CatDog opened two
context menus instead of one.
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.
This implements window stealing in WindowServer, which allows clients
to mark a window they own as 'stealable' by another client. Indicating
that the other client may use it for any purpose.
This also updates set_window_parent_from_id so that the client must
first mark its window as stealable before allowing other clients to
use it as a parent.
The only remaining sync call from client to server is now the call
that switches a window's backing store. That one actually relies on
the synchronization to hand over ownership of the backing stores,
so it has to stay synchronous for now.
This also adds the ability to query how many virtual desktops are
set up, and for the Taskbar to be notified when the active virtual
desktop has changed.
The launch_origin_rect parameter to create_window() specifies where on
screen the window was launched from. It's optional, but if you provide
it, the new window will have a short wireframe animation from the origin
to the initial window frame rect.
GUI::Window looks for the "__libgui_launch_origin_rect" environment
variable. Put your launch origin rect in there with the format
"<x>,<y>,<width>,<height>" and the first GUI::Window shown by the app
will use that as the launch origin rect.
Also it looks pretty neat, although I'm sure we can improve it. :^)
An Overlay is similar to a transparent window, but has less overhead
and does not get rendered within the window stack. Basically, the area
that an Overlay occupies forces transparency rendering for any window
underneath, which allows us to render them flicker-free.
This also adds a new API that allows displaying the screen numbers,
e.g. while the user configures the screen layout in DisplaySettings
Because other things like drag&drop or the window-size label are not
yet converted to use this new mechanism, they will be drawn over the
screen-number currently.
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.
