XHB

WARNING: XHB is a work-in-progress, and this page is a WIP, too.

What is XHB?

XHB is short for X Haskell Binding. XHB serves the purpose of XCB [1] for Haskell programs.

XHB is deemed to be used for all sorts of X11 application programming. Why not use traditional Xlib?

Xlib bindings are incomplete, and seem to be hard to get right
Xlib has it's share of sharp edges which XCB tries to smooth out [2]

Getting started

NOTE: this tutorial is based on [3]

Introduction

The X Window System employs a client-server model for all its interactions, thus X applications are event-driven clients of an X server, which manages some system-wide resources (windows, input devices, etc.) and sends event notifications to clients.

Every client (X application) can basically perform two things:

send requests (e.g., generate events, etc.)
receive replies (e.g., event notifications, etc.)

An example

A client may connect to the server, request that it draws a window (or several windows), and ask the server to send it any input the user sends to these windows. Thus, several clients may connect to a single X server (one might be running mail software, one running a WWW browser, etc.). When input is sent by the user to some window, the server sends a message to the client controlling this window for processing. The client decides what to do with this input, and sends the server requests for drawing in the window.

The X protocol

The whole session is carried out using the X message protocol. This protocol was originally carried over the TCP/IP protocol suite, allowing the client to run on any machine connected to the same network that the server is. Later on, the X servers were extended to allow clients running on the local machine with more optimized access to the server (note that an X protocol message may be several hundreds of KB in size), such as using shared memory, or using Unix domain sockets (a method for creating a logical channel on a Unix system between two processes).

The GUI programming model

A GUI program mostly sits idle, waiting for events sent by the X server, and then acts upon these events. An event may say "The user pressed the 1st button mouse in spot (x,y)", or "The window you control needs to be redrawn". In order for the program to be responsive to the user input, as well as to refresh requests, it needs to handle each event in a rather short period of time (e.g. less that 200 milliseconds, as a rule of thumb)

This also implies that the program may not perform operations that might take a long time while handling an event (such as opening a network connection to some remote server, or connecting to a database server, or even performing a long file copy operation). Instead, it needs to perform all these operations in an asynchronous manner. This may be done by using various asynchronous models to perform the longish operations, or by performing them in a different process or thread.

So the way a GUI program looks is something like that:

  1. Perform initialization routines.
  2. Connect to the X server.
  3. Perform X-related initialization.
  4. While not finished:
        1. Receive the next event from the X server.
        2. Handle the event, possibly sending various drawing requests to the X server.
        3. If the event was a quit message, exit the loop.
        4. Close down the connection to the X server.
        5. Perform cleanup operations.

Basic XHB notions

XHB has been created to eliminate the need for programs to actually implement the X protocol layer. This library gives a program a very low-level access to any X server. Since the protocol is standardized, a client using any implementation of XHB may talk with any X server (the same occurs for Xlib, of course). We now give a brief description of the basic XHB notions. They will be detailed later.

the X server connection
requests and replies
the graphics context
events

TODO: really introduce connections, events, etc.

Obtaining XHB

As of this writing, XHB is still not cabalized. This is being worked on.

XHB

Contents