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.
d0fb511d75 set the maximized window value
in the File Manager before a window was created, which resulted in crash
everytime you tried to open the program that was closed while it was
maximized. ugh
Here we do more-or-less what GUI::Window::set_rect() does, except we
don't add it to the WindowServer::create_window() IPC call.
That's because the Window Server knows nothing about menus at this
point and just assumes they don't need to be visible.
So if we try to maximize the window then, it could be slightly taller
and a titlebar could be hidden.
So even though it looks how it looks like, it does work and it doesn't
show in the startup size, as described in the mentioned commit (the call
is put a few lines before the initial update()). :^)
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.
Applets and windows would like to be able to know when the applet
area has been resized. For example, this happens asynchronously after
an applet has been resized, so we cannot then rely on the applet area
position synchronously after resizing. This adds a new message
applet_area_rect_changed and associated Event AppletAreaRectChange,
and the appropriate virtual functions.
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.
Applications previously had to create a GUI::Menubar object, add menus
to it, and then call GUI::Window::set_menubar().
This patch introduces GUI::Window::add_menu() which creates the menubar
automatically and adds items to it. Application code becomes slightly
simpler as a result. :^)
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.
When setting a Widget->set_visible(false), if that Widget->has_focus()
it will continue to have focus, even though it's not visible to the user
anymore.
Now calling Widget->set_visible(false) will remove focus from the Widget
if it had focus, and the Window will give focus back to the Widget
that had it previously, if there was one.
Previously <AK/Function.h> also included <AK/OwnPtr.h>. That's about to
change though. This patch fixes a few build problems that will occur
when that change happens.
This state lives in WindowServer and has no local copy in the client
process for now. This may turn out to be a performance issue, and if
it does we can easily cache it.
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 *
With this patch the window manager related functionality is split out
onto a new endpoint pair named WindowManagerServer/Client. This allows
window manager functionality to be potentially privilege separated in
the future. To this end, a new client named WMConnectionClient
is used to maintain a window manager connection. When a process
connects to the endpoint and greets the WindowServer as a window manager
(via Window::make_window_manager(int)), they're subscribed to the events
they requested via the WM event mask.
This patch also removes the hardcoding of the Taskbar WindowType to
receive WM events automatically. However, being a window manager still
requires having an active window, at the moment.
I hereby declare these to be full nouns that we don't split,
neither by space, nor by underscore:
- Breadcrumbbar
- Coolbar
- Menubar
- Progressbar
- Scrollbar
- Statusbar
- Taskbar
- Toolbar
This patch makes everything consistent by replacing every other variant
of these with the proper one. :^)
Having to rely on GUI::Desktop's on_rect_change is quite limiting and a
bit awkward (continuing to use it would mean having to setup the
callback in every application using a webview) - we need a better way of
letting widgets know of a screen rect change automatically.
The specific use case will be IPWV/OOPWV which need to keep track of the
screen rect and notify the WebContent service of any change (which on
its own deliberately can't interact with WindowServer at all).
It'll also be useful for notification windows and the taskbar, which
currently both rely on the GUI::Desktop callback but will now be able to
listen and react to the event themselves.
Since applet windows live in the applet area window, the AppletManager
has to keep track of which applet is hovered and send the appropriate
enter/leave events to the applet windows.
This makes applet tooltips work again. :^)
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.
Minimum window size can now be customised and set at runtime via the
SetWindowMinimumSize WindowServer message and the set_minimum_size
LibGUI::Window method. The default minimum size remains at 50x50.
Some behind-the-scenes mechanics had to be added to LibGUI::Window to
ensure that the minimum size is remembered if set before the window is
shown. WindowServer sends a resize event to the client if it requests a
size on create that's smaller than it's minimum size.
The WM_* IPC messages are intended for "outsider" window management,
not for a client's own windows. Make a separate StartWindowResize
message for this.
This was the only reason that every IPC client had to know its server
side client ID.
