RGBCube/serenity
1
Fork 0
mirror of https://github.com/RGBCube/serenity synced 2025-05-14 09:24:57 +00:00
Code Issues Activity Actions

Userland: Rename Core::Object to Core::EventReceiver

Browse source 
This is a more precise description of what this class actually does.
This commit is contained in:
Andreas Kling 2023-08-06 18:09:39 +02:00 • committed by Jelle Raaijmakers
parent bdf696e488
commit ddbe6bd7b4
128 changed files with 399 additions and 401 deletions
Download patch file Download diff file Expand all files Collapse all files

2
Documentation/EventLoop.md
View file

@ -29,7 +29,7 @@ The **event loop stack** is mainly used for nesting GUI windows. Each window add
An event loop handles several kinds of events:
- POSIX signals can be registered with `EventLoop::register_signal()`. This means that the event loop of the calling thread registers the specified POSIX signal and callback with the kernel, and you can be sure that the signal handler will run as a normal event without the weirdness that comes with POSIX signal handlers (such as unspecified thread).
- EventLoop::post_event() allows calling code to fire an event targeting a specific Core::Object the next time the event loop is pumped.
- EventLoop::post_event() allows calling code to fire an event targeting a specific Core::EventReceiver the next time the event loop is pumped.
- Similarly, an arbitrary callback can be called on the next event loop iteration with `EventLoop::deferred_invoke()`.
- Timer events, i.e. events that fire after a certain timeout, possibly repeatedly, can be created with `EventLoop::register_timer` and `Object::start_timer()`. A more user-friendly version is the `Core::Timer` utility class which does the same thing and allows you to attach any callback to the timer.
- For when a "file" becomes readable or writeable, the utility class `Core::Notifier` interfaces with the event loop system to handle exactly that.