Hipe : The DOM on the desktop
How Hipe Works  |  Installation  |  Running hiped  |  Hipe API

How Hipe Works

There are two sides to a Hipe session. On the server side, you have the Hipe display server (hiped); a single process which starts when the user's session does.

On the client side, you have applications like word processors, web browsers and calculator utilities. They are called clients because they use the services of the Hipe display server. The Hipe server provides each client application with its own frame. Each client app is allowed to display graphical user content only within its own frame.

One Hipe display server instance can have multiple client applications using it at any one time.

A framing manager is a special kind of client application whose job is to manage the placement of other client applications' frames on the screen. It is analogous to the various 'window managers' used in X windowing environments. Framing managers can be nested; for example, a particular suite of related applications can be provided within its own desktop environment. Alternatively, instances of certain remote applications can be sandboxed within a common environment.

Client applications communicate with Hipe by exchanging instructions over a local socket connection. For example, a client might send an instruction to manipulate the contents of a particular tag element, or may receive an event instruction in response to the user clicking a particular tag element.

Where Hipe fits

Connecting to hiped

To connect to the Hipe display server, a client application needs two pieces of information. The location of the Hipe display server's open socket (nominally placed in a standard/reproducible default location unique to each user), and a host key which is a character string that applications use to prove they have permission to be granted a frame at a specific level.

Hipe does not dictate a single mechanism for framing managers to share host keys with client applications (although a default lookup policy for client applications is built into the API), but for top-level applications (which cover the whole screen and are not governed by framing managers), hiped maintains a key-file in a standard location which is updated every time a client claims a top-level key. The key-file can be placed in a different location with restricted permissions to satisfy case requirements where it is not appropriate to allow applications to create frames at the top level. In this case, only the framing manager bundled with the system distribution would be able to access the key-file for creating a single top-level frame which would then contain all the frames of client applications.

Implementation stack

The Hipe display server is implemented as a Qt/Webkit application. Although Hipe (and Hipe applications) doesn't use or depend on X or any other display manager directly, Webkit's implementation does depend on X (or other Qt-compatible display server). This means that at this stage, Hipe runs on top of X.

You can think of Hipe as a 'high level' display server. It does stuff like rendering, layout and frame management, but it doesn't interact with hardware or device drivers directly. For the latter, we use a bare-minimal X session as a 'low-level' base environment.

Hipe can run on top of a bare X session (without requiring any X-based window management or desktop environment), in which case a framing manager can create a top-level frame and manage all other client applications from there. In this form, Hipe has the appearance and functionality of a standalone display environment.

Alternatively, hiped can be started within an existing X-based desktop environment. In this case, client applications can be started as top-level Hipe applications, and they will be managed by the X window manager of the host environment. In this mode, we say that Hipe is running in a rootless mode, since it doesn't take over the whole desktop. Applications will start maximised, because Hipe doesn't allow applications to dictate their own frame sizes.

There are other alternatives to X, such as the leaner Wayland, which may be considered as a preferred base for Hipe in the future. For now, X is used as a base display server for Hipe, since it is stable and has good hardware support.