| Age | Commit message (Collapse) | Author |
|---|
|
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 don't reset windowless rects on resize events. Fixes child
windows reappearing at [0,0] and with the wrong dimensions after
being hidden.
|
|
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.
|
|
Until the tracking stops, we want to keep displaying the same cursor.
|
|
Scrolling can now be set Coarse or Smooth system-wide, Splitter
knurls and Tab accents toggled on and off, and Menu flashing
disabled.
|
|
This commit moves the length calculations out to be directly on the
StringView users. This is an important step towards the goal of removing
StringView(char const*), as it moves the responsibility of calculating
the size of the string to the user of the StringView (which will prevent
naive uses causing OOB access).
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
This is useful, for instance, in games in which you can switch held
items using the scroll wheel. In order to implement this, they
previously would have to either add a hard-coded division by 4, or look
up your mouse settings to adjust correctly.
This commit adds an MouseEvent.wheel_raw_delta_x() and
MouseEvent.wheel_raw_delta_y().
|
|
This was done with CLion's automatic rename feature.
|
|
Rename WindowManagerServerConnection=>ConnectionToWindowManagerServer.
This was done with CLion's automatic rename feature.
|
|
The default return key widget takes precendence when dispatching
return key events with the exception of focused buttons.
|
|
|
|
Briefly flash the menubar menu containing the keyboard shortcut action
to give the user immediate visual feedback on their interaction with the
system.
|
|
This is a fallible variant of add_menu() that returns ErrorOr.
|
|
Another one that was used in a fajillion places.
|
|
|
|
|
|
This makes teardown faster since we don't have to wait for responses to
each destroy_window request. It also avoids doing IPC during teardown,
which is a general source of problems.
|
|
|
|
This patch removes a hack that forced any pending repaints to happen
immediately whenever you moved the mouse over a window.
The purpose of that mechanism was to ensure that quick button presses
still show up visually, and since that is now accomplished via
Widget::repaint(), we no longer need this.
|
|
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.
|
|
This allows windows to be closed only programatically, and not from e.g.
the user clicking the X button on the window frame.
|
|
d0fb511d75762e9d97fa80a01585381843b90a0a 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 condition rejected almost every bitmap cursor change.
|
|
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.
|
|
Only one place used this argument and it was to hold on to a strong ref
for the object. Since we already do that now, there's no need to keep
this argument around since this can be easily captured.
This commit contains no changes.
|
|
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.
|
|
|
|
This patchs adds a way for widgets exclude themselves from being a focus
candidate in Window::focus_a_widget_if_possible().
This is to allow the URL box to not get auto-focused when the browser
is loaded.
|
|
|
|
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 reverts commit cfc9ee6f16b9c4d2b246bb2832dd436637cbeaad.
This change was wrong: The parent *does* lose hover when the mouse
cursor enters a child widget. Hover is not hierarchical, there is only a
hovered window and a hovered widget within that window.
This fixes an issue with GUI::TabWidget buttons appearing hovered
despite the mouse cursor not being over the buttons.
|
|
You can now see the outline of GUI widgets when hovering them.
For example:
$ export GUI_HOVER_DEBUG=1
$ FileManager
Then move the mouse around in the file manager. :^)
|
|
Without this change, when the mouse starts hovering over a child widget,
the parent would receive a Leave event despite the parent widget not
losing mouse hover.
|
|
These can be useful if an application wants to react to the cursor
entering the window at any point, rather than just on a widget.
|
|
Instead of crashing when we can't make the back buffer non-volatile,
we now transition the window into single-buffered mode instead
(assuming it was originally in double-buffered mode.)
This reduces GUI fidelity a bit (by potentially making windows flicker
during repaint) but since it's only triggered in low-memory conditions,
it seems like a reasonable thing to sacrifice in order for the system
to carry on.
This patch also stops us from allocating entirely new backing stores
after the old ones were purged. If they were purged but reallocated
just fine, there's no need to allocate new memory again. We already
have fresh zero-filled pages in the existing bitmap at this point.
|
|
Making a bitmap non-volatile after being volatile may fail to allocate
physical pages after the kernel stole the old pages in a purge.
This is different from the pages being purged, but reallocated. In that
case, they are simply replaced with zero-fill-on-demand pages as if
they were freshly allocated.
|
|
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. :^)
|
|
Also mark them as [[nodiscard]].
|
|
|
|
Window::set_maximized requires non-zero window id to be a valid call,
i.e. calling Window::show beforehand. A verify statement before the
server call can help developers by hinting correct usage.
|
|
(#8515)"
This reverts commit 1c06d772628a0191289fe30edcc143e29ba2ca32.
This was squashed by mistake, the rebased version will follow.
|
