I encountered a WindowServer crash due to null-pointer dereference in
this function, so let's protect against it by simply skipping over
nulled-out WeakPtrs.
I added a FIXME about how we ideally wouldn't be in this situation in
the first place, but that will require some more investigation.
This encapsulates what our multi-client IPC servers typically do on
startup:
1. Create a Core::LocalServer
2. Take over a listening socket file descriptor from SystemServer
3. Set up an accept handler for incoming connections
IPC::MultiServer does all this for you! All you have to do is provide
the relevant client connection type as a template argument.
These ones all manage their storage internally, whereas the WebContent
and ImageDecoder ones require the caller to manage their lifetime. This
distinction is not obvious to the user without looking through the code,
so an API that makes this clearer would be nice.
Everyone used this hook in the same way: immediately accept() on the
socket and then do something with the newly accepted fd.
This patch simplifies the hook by having LocalServer do the accepting
automatically.
235f39e449 secretly added an if check that ignores all the files that
couldn't be loaded into bitmaps. Unfortunately, we send an empty path
as a way to unset the wallpaper, which meant that we couldn't go back
to the default background color anymore.
With this change, System::foo() becomes Core::System::foo().
Since LibCore builds on other systems than SerenityOS, we now have to
make sure that wrappers work with just a standard C library underneath.
Render the window switcher with the same background and shadow as other
WindowServer overlays.
Note that we don't actually render it as a WindowServer::Overlay, as the
window switcher uses mouse and keyboard events, and there's currently
no way for an overlay to receive events.
This fixes an issue with menus not being immediately "usable" with the
the right mouse button after opening a context menu.
The bug was that we were clearing a local pointer to the active input
tracking window instead of the pointer in WindowStack.
We need to make sure the menu was pushed to the open menu stack before
calling set_visible, as this may trigger cursor re-evaluation, which
in turn expects the menu to be considered open.
Fixes#10836
This reverts commit 239520ae54.
The call to set_visible() is not redundant. Removing the call leads
to the "start" button in the taskbar not being painted as "pressed" even
when it is.
We've already returned early if the menu is open, so there's no need to
verify that it isn't present in the stack of open menus before pushing
it onto said stack.
WindowServer returns {} on non-existing screen index,
however shot program hangs instead of retriving an empty
ShareableBitmap. With this change, the function returns an empty
ShareableBitmap and shot exits gracefully.
This makes the cursor update properly if it was above the window
switcher while it was visible, and something underneath it wants to use
something other than the default arrow cursor.
...to reevaluate_hover_state_for_window(). This name is not super great
either, but at least it doesn't sound like the window is necessarily
currently being hovered.
In 2e6bb987a3 the "did_construct" API in
Core::Object was removed, since it had only one user. For a replacement,
the Window would manually call the frame's "frame_was_constructed"
method. However, WindowServer::Window has two constructors, and only one
of them called this method. This caused windows to spawn without
buttons and various other breakage that spawned from this.
Derivatives of Core::Object should be constructed through
ClassName::construct(), to avoid handling ref-counted objects with
refcount zero. Fixing the visibility means that misuses like this are
more difficult.
This commit is separate from the other Servives changes because it
required additional adaption of the code. Note that the old code did
precisely what these changes try to prevent: Create and handle a
ref-counted object with a refcount of zero.
Derivatives of Core::Object should be constructed through
ClassName::construct(), to avoid handling ref-counted objects with
refcount zero. Fixing the visibility means that misuses like this are
more difficult.
There is also make_ref_counted(), which does not call did_construct(),
so the method was not guaranteed to be run. Since there is only a single
user, and `WindowServer::Window` is a final class anyway (so there is no
need to separate the constructor and post-constructor phases), let's get
rid of this concept.
(The following commits reduce the opportunities to call
make_ref_counted, but still.)
