DBus

A method call is a request to run some procedure exported by the remote process. Procedures are identified by an (object_path, interface_name, method_name) tuple.

Construct a new MethodCall for the given object, interface, and method.

Use fields such as methodCallDestination and methodCallBody to populate a MethodCall.

{-# LANGUAGE OverloadedStrings #-}

methodCall "/" "org.example.Math" "Add"
    { methodCallDestination = Just "org.example.Calculator"
    , methodCallBody = [toVariant (1 :: Int32), toVariant (2 :: Int32)]
    }
 

The object path of the method call. Conceptually, object paths act like a procedural language's pointers. Each object referenced by a path is a collection of procedures.

The interface of the method call. Each object may implement any number of interfaces. Each method is part of at least one interface.

In certain cases, this may be Nothing, but most users should set it to a value.

The method name of the method call. Method names are unique within an interface, but might not be unique within an object.

The name of the application that sent this call.

Most users will just leave this empty, because the bus overwrites the sender for security reasons. Setting the sender manually is used for peer-peer connections.

Defaults to Nothing.

The name of the application to send the call to.

Most users should set this. If a message with no destination is sent to the bus, the bus will behave as if the destination was set to org.freedesktop.DBus. For peer-peer connections, the destination can be empty because there is only one peer.

Defaults to Nothing.

Set whether the bus should auto-start the remote

Defaults to True.

Set whether a reply is expected. This can save network and cpu resources by inhibiting unnecessary replies.

Defaults to True.

The arguments to the method call. See toVariant.

Defaults to [].

A method return is a reply to a method call, indicating that the call succeeded.

Construct a new MethodReturn, in reply to a method call with the given serial.

Use fields such as methodReturnBody to populate a MethodReturn.

The serial of the original method call. This lets the original caller match up this reply to the pending call.

The name of the application that is returning from a call.

Most users will just leave this empty, because the bus overwrites the sender for security reasons. Setting the sender manually is used for peer-peer connections.

Defaults to Nothing.

The name of the application that initiated the call.

Most users should set this. If a message with no destination is sent to the bus, the bus will behave as if the destination was set to org.freedesktop.DBus. For peer-peer connections, the destination can be empty because there is only one peer.

Defaults to Nothing.

Values returned from the method call. See toVariant.

Defaults to [].

A method error is a reply to a method call, indicating that the call received an error and did not succeed.

Construct a new MethodError, in reply to a method call with the given serial.

Use fields such as methodErrorBody to populate a MethodError.

The name of the error type. Names are used so clients can handle certain classes of error differently from others.

The serial of the original method call. This lets the original caller match up this reply to the pending call.

The name of the application that is returning from a call.

Most users will just leave this empty, because the bus overwrites the sender for security reasons. Setting the sender manually is used for peer-peer connections.

Defaults to Nothing.

The name of the application that initiated the call.

Most users should set this. If a message with no destination is sent to the bus, the bus will behave as if the destination was set to org.freedesktop.DBus. For peer-peer connections, the destination can be empty because there is only one peer.

Defaults to Nothing.

Additional information about the error. By convention, if the error body contains any items, the first item should be a string describing the error.

Get a human-readable description of the error, by returning the first item in the error body if it's a string.

Signals are broadcast by applications to notify other clients of some event.

Construct a new Signal for the given object, interface, and signal name.

Use fields such as signalBody to populate a Signal.

The path of the object that emitted this signal.

The name of this signal.

The interface that this signal belongs to.

The name of the application that emitted this signal.

Most users will just leave this empty, because the bus overwrites the sender for security reasons. Setting the sender manually is used for peer-peer connections.

Defaults to Nothing.

The name of the application to emit the signal to. If Nothing, the signal is sent to any application that has registered an appropriate match rule.

Defaults to Nothing.

Additional information about the signal, such as the new value or the time.

Defaults to [].

Not an actual message type, but a wrapper around messages received from the bus. Each value contains the message's Serial.

If casing against these constructors, always include a default case to handle messages of an unknown type. New message types may be added to the D-Bus specification, and applications should handle them gracefully by either ignoring or logging them.

No matter what sort of message was received, get its serial.

No matter what sort of message was received, get its sender (if provided).

No matter what sort of message was received, get its body (if provided).

Interfaces are used to group a set of methods and signals within an exported object. Interface names consist of alphanumeric characters separated by periods.

See http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names-interface for details.

Member names are used to identify a single method or signal within an interface. Method names consist of alphanumeric characters.

See http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names-member for details.

Error names are used to identify which type of error was returned from a method call. Error names consist of alphanumeric characters separated by periods.

See http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names-error for details.

Bus names are used to identify particular clients on the message bus. A bus name may be either unique or well-known, where unique names start with a colon. Bus names consist of alphanumeric characters separated by periods.

See http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names-bus for details.

A D-Bus Structure is a container type similar to Haskell tuples, storing values of any type that is convertable to IsVariant. A Structure may contain up to 255 values.

Most users can use the IsVariant instance for tuples to extract the values of a structure. This type is for very large structures, which may be awkward to work with as tuples.

A D-Bus Array is a container type similar to Haskell lists, storing zero or more values of a single D-Bus type.

Most users can use the IsVariant instance for lists or vectors to extract the values of an array. This type is for advanced use cases, where the user wants to convert array values to Haskell types that are not instances of IsValue.

A D-Bus Dictionary is a container type similar to Haskell maps, storing zero or more associations between keys and values.

Most users can use the IsVariant instance for maps to extract the values of a dictionary. This type is for advanced use cases, where the user wants to convert dictionary items to Haskell types that are not instances of IsValue.

Convert a Message into a ByteString. Although unusual, it is possible for marshaling to fail; if this occurs, an error will be returned instead.

Convert a Message into a ByteString along with all Fd values mentioned in the message (the marshaled bytes will contain indices into this list). Although unusual, it is possible for marshaling to fail; if this occurs, an error will be returned instead.

Parse a ByteString into a ReceivedMessage. The result can be inspected to see what type of message was parsed. Unknown message types can still be parsed successfully, as long as they otherwise conform to the D-Bus standard.

Unmarshaling will fail if the message contains file descriptors. If you need file descriptor support then use unmarshalWithFds instead.

Parse a ByteString into a ReceivedMessage. The Fd values are needed because the marshaled message contains indices into the Fd list rather then Fd values directly. The result can be inspected to see what type of message was parsed. Unknown message types can still be parsed successfully, as long as they otherwise conform to the D-Bus standard.

A value used to uniquely identify a particular message within a session. Serials are 32-bit unsigned integers, and eventually wrap.

Get the first serial in the sequence.

Get the next serial in the sequence. This may wrap around to firstSerial.