The "Window" classes in LibGUI and WindowServer now store the PID of the
process that created the window. LibGUI's Window obtains the PID in the
constructor via getpid(), and passes it in Window::show() to
WindowServer via the create_window() IPC route. WindowServer then saves
it in its own Window class.
This allows us to find the process that created a window in order to add
process-specific actions to the window.
Previously, exiting a fullscreen application when
`save_size_and_position_on_close()` was used would lead to the
application having an unexpectedly large size when it was reopened.
Exiting a maximized application would lead to the restore button not
working as expected when the application was reopened.
Since Core::Object properties are really only used by GML now that the
Inspector is long gone, there's no need for these to pollute
Core::Object.
This patch adds a new GUI::Object class to hold properties, and makes
it the new base class of GUI::Window, GUI::Widget and GUI::Layout.
The "instantiate an object by name" mechanism that GML uses is also
hoisted into GUI::Object as well.
From what I can tell, this facility was added to WSWindow/GWindow in
2019 in 9b71307. I only found a single place in the codebase still using
this facility: `WindowServer::Menu::start_activation_animation()`. A
subtle fade-out animation that happens when a menu item is selected, and
the menu disappears.
I think our compositing facilities have improved enough to make this
facility redundant. The remaining use mentioned above was ported to just
directly blit the fade-out animation instead of requesting it from
WindowServer.
Previously Windows automatically grew to accomodate layout changes
when obeying minimum widget size but would not automatically shrink
if so desired. Setting auto shrink true now automatically resizes
windows to their effective_min_size() every time their minimum size
updates. This will be useful for making fixed size windows responsive
to layout and font changes in the future.
First, this patch renames the function
`propagate_shortcuts_up_to_application` to `propagate_shortcuts`.
Handling those levels, will allow us to differentiate shortcuts at
`Window` level and `Application` level. Which will be convenient to
handle dialog-specific shortcuts.
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%.
Rip that bandaid off!
This does the following, in one big, awkward jump:
- Replace all uses of `set_main_widget<Foo>()` with the `try` version.
- Remove `set_main_widget<Foo>()`.
- Rename the `try` version to just be `set_main_widget` because it's now
the only one.
The majority of places that call `set_main_widget<Foo>()` are inside
constructors, so this unfortunately gives us a big batch of new
`release_value_but_fixme_should_propagate_errors()` calls.
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 :^)
and the CaptureInput mode. They are a source of unneeded complexity
in WindowServer and have proven prone to regressions, so this patch
replaces them with a simple input preemption scheme using Popups.
Popup windows now have ergonomics similar to menus: When open,
a popup preempts all mouse and key events for the entire window
stack; however, they are fragile and will close after WindowServer
swallows the first event outside them. This is similar to how combo
box windows and popups work in the classic Windows DE and has the
added benefit of letting the user click anywhere to dismiss a popup
without having to worry about unwanted interactions with other
widgets.
with WindowInput{Preempted,Restored} Events and allow Widgets to save
the state of their focus preemption. As of now, only Popups will
preempt input and trigger these events.
Since the logic to open the command palette is now in the form of an
action, its keybinding is only bound when the window active. Thus, when
a combo box or the emoji input dialog is active, the window isn't, and
the command palette doesn't show up, without requiring special checks.
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 having to negate every focusable widget or textbox, let
windows override all their widgets. These two Dialogs now block
themselves and each other.
This patch fixes an issue for applications that contain actions without
a modifier (e.g. PixelPaint). Previously when pressing any key bound to
an action while the CommandPalette was visible the action was forwarded
to the parent instead of the CommandPalette.
Previously Menus set themselves as active input solely to make
sure CaptureInput modals would close, but this is a functional
half-truth. Menus don't actually use the active input role; they
preempt normal Windows during event handling instead.
Now the active input window is notified on preemption and Menus
can remain outside the active input concept. This lets us make
more granular choices about modal behavior. For now, the only
thing clients care about is menu preemption on popup.
Fixes windows which close on changes to active input closing
on their own context menus.
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.
And remove unnecessary workarounds to the old limit of {50, 50} and
the cautious but arbitrary limit of {1, 1} for other WindowTypes.
Null rects are already the default when calculating minimum window
size and are the least restrictive but valid value.
Also returns early during minimum size calculations for frameless
windows, and verifies against negative minimum sizes and failure to
disable widget min size before setting a minimum window size. Layout
automatically overrides this setting each relayout otherwise.
Instead of having widget/window/application create a shortcut from a
KeyEvent within their find methods, we'll just pass them a Shortcut
so that the "where to search" logic doesn't need to be duplicated
for different Shortcut types.
It also lets us handle invalid Shortcut rejection at a higher level,
with most things letting the caller be responsible for not searching
for actions with an invalid shortcut.
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.
Briefly flash the menubar menu containing the keyboard shortcut action
to give the user immediate visual feedback on their interaction with the
system.
In most situations, Widget::update() is preferable, since that allows us
to coalesce repaints and avoid redundant work, reducing system load.
However, there are some cases where you really want a paint to happen
right away, to make sure that the user has a chance to see a short-lived
visual state.
