Struct Looper

pub struct Looper<A>
where
    A: Send + 'static,
{ /* private fields */ }

A system that receives and processes messages in a separate thread

Loopers are a core Haiku concept. Haiku embraces the multithreaded application model, where the functionality of the application is split up over different threads with a specific job. The best example of the use of a looper is in that every Window is its own Looper.

Haiku’s design consists of an Application with one or more Loopers. Each Looper then functions as an independent message queue, which receives messages from other parts of the application, or from external applications, and then dispatches these to Handlers. In this implementation of the API, any object may be a Handler, as long as it implements the Handler trait. A Looper has at least one Handler, which is referred to as the InitialState.

To create a new Looper, you call the Application::create_looper() method. This method takes as an argument a Box, which is a required instance of a type that that you define and use. The only requirement is that this State implements the Handler trait, so that it may receive and process messages. The State becomes the preferred Handler by default.

After creating a Looper, you can add additional Handlers to it, with the add_handler() method. After you add the Handler, the Looper takes ownership, this means that you can no longer manipulate the object yourself. It is possible to mark a Handler as the preferred Handler by using the add_preferred_handler() method. This will override any previously selected preferred Handler.

Once the Looper and its Handlers are set up, you can start the message queue by using the run() method. Calling this method will transfer ownership of the Looper object to the new Looper thread. Any interaction you may want with that thread, should be done through the messaging system.

A Looper will continue to run until the it gets a request to quit. This can be done by sending the B_QUIT_REQUESTED message. Additionally, a Looper will quit when the Application is quitting.

Implementations

impl<A> Looper<A>

where A: Send + 'static,

pub fn name(&self) -> &str

Get the name for this Looper

pub fn get_messenger(&self) -> Messenger

Get a Messenger for this looper

This Messenger by default points to the preferred Handler.

pub fn run(self) -> Result<()>

Start the message loop

When you use this method, the Looper ownership of the Looper object will be transferred to the Looper’s thread. The message processing will start, until the Looper is requested to quit.

pub fn add_handler(&mut self, handler: Box<dyn Handler<A> + Send>)

Add a Handler to the message queue

The handler may be any object that implements the Handler trait. The object should be created on the heap (as a Box).

pub fn add_preferred_handler(&mut self, handler: Box<dyn Handler<A> + Send>)

Add a preferred Handler to the message queue

Like the add_handler() method, this method takes ownership of any Handler. In addition, this method will also set the Handler as the preferred Handler of this Looper. This will overwrite the previously set preferred Handler.