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

The Hipe API
Including libhipe
libhipe functions
C++ extensions
Multithreading considerations
Hipe instructions
Interprocess communication
HIPE_OP_ADD_FONT
HIPE_OP_ADD_STYLE_RULE
HIPE_OP_ADD_STYLE_RULE_SRC
HIPE_OP_APPEND_TAG
HIPE_OP_APPEND_TEXT
HIPE_OP_ATTRIBUTE_RETURN
HIPE_OP_AUDIOVIDEO_STATE
HIPE_OP_CANVAS_ACTION
HIPE_OP_CANVAS_SET_PROPERTY
HIPE_OP_CARAT_POSITION
HIPE_OP_CLEAR
HIPE_OP_EDIT_ACTION
HIPE_OP_CONTAINER_GRANT
HIPE_OP_CONTENT_RETURN
HIPE_OP_DELETE
HIPE_OP_DIALOG
HIPE_OP_DIALOG_INPUT
HIPE_OP_DIALOG_RETURN
HIPE_OP_EVENT
HIPE_OP_EVENT_CANCEL
HIPE_OP_EVENT_REQUEST
HIPE_OP_FIFO_ADD_ABILITY
HIPE_OP_FIFO_CLOSE
HIPE_OP_FIFO_DROP_PEER
HIPE_OP_FIFO_GET_PEER
HIPE_OP_FIFO_OPEN
HIPE_OP_FIFO_REMOVE_ABILITY
HIPE_OP_FIFO_RESPONSE
HIPE_OP_FILE_RETURN
HIPE_OP_FIND_TEXT
HIPE_OP_FRAME_CLOSE
HIPE_OP_FRAME_EVENT
HIPE_OP_FREE_LOCATION
HIPE_OP_GEOMETRY_RETURN
HIPE_OP_GET_ATTRIBUTE
HIPE_OP_GET_AUDIOVIDEO_STATE
HIPE_OP_GET_BY_ID
HIPE_OP_GET_CARAT_POSITION
HIPE_OP_GET_CONTENT
HIPE_OP_GET_FIRST_CHILD
HIPE_OP_GET_FRAME_KEY
HIPE_OP_GET_GEOMETRY
HIPE_OP_GET_LAST_CHILD
HIPE_OP_GET_NEXT_SIBLING
HIPE_OP_GET_PREV_SIBLING
HIPE_OP_GET_SCROLL_GEOMETRY
HIPE_OP_GET_SELECTION
HIPE_OP_KEY_RETURN
HIPE_OP_LOCATION_RETURN
HIPE_OP_MESSAGE
HIPE_OP_OPEN_LINK
HIPE_OP_REMOVE_ATTRIBUTE
HIPE_OP_REQUEST_CONTAINER
HIPE_OP_SCROLL_BY
HIPE_OP_SCROLL_TO
HIPE_OP_SERVER_DENIED
HIPE_OP_SET_ATTRIBUTE
HIPE_OP_SET_FOCUS
HIPE_OP_SET_ICON
HIPE_OP_SET_SRC
HIPE_OP_SET_STYLE
HIPE_OP_SET_STYLE_SRC
HIPE_OP_SET_TEXT
HIPE_OP_SET_TITLE
HIPE_OP_TAKE_SNAPSHOT
HIPE_OP_TOGGLE_CLASS
HIPE_OP_USE_CANVAS

Instruction set reference

HIPE_OP_FIFO_GET_PEER

Requests (or handles a request) for a program to begin communications with a FIFO peer that has the required ability. This leads to the creation of a FIFO resource between the two applications.

There is a one-to-many relationship between a supported ability and the number of peers that may be making use of that ability.

FIFO access modes

The following specifiers can be used to control how data is read or written to the FIFO stream. The direction of transfer is specified from the client's point of view.

Typically, a host should not be expected to implement all of these access modes. For example, it might not be appropriate to save a document to a scanner or to load a file from a printer, but reading a scanned page from a scanner and sending it to a printer is more reasonable. Likewise, for some sources of data, it is only sensible (or technically feasible) to transfer the data sequentially from beginning to end, while a database system might allow random access from any position within a file.

SpecifierDescription
rRead sequentially from the beginning of the data. Data to be read should already exist at the host.
RRead data from a specified position, rather than from the start of the file. Data to be read should already exist at the host.
wWrite new data sequentially from the beginning, discarding all existing data held by the host.
WWrite data from a specified position, overwriting a section of existing data held by the host.
aWrite data by appending it to the end of the existing data held by the host. Existing data is preserved. If there is no pre-existing data in the resource, data will be written from the beginning.

Notes on access modes

Order of access modes

The order of access mode specifiers is significant: where appropriate, the expected initial access mode should be specified first. For example, "rw" means that data will initially be read, and may be written back to later, while "wr" means that fresh data will be written from the start. An initial access mode of r or R means that the host acts (initially at least) as a source of data rather than a destination.

An example of "read then write" ordering would be a file which is opened for editing. First the editor must read the file to load its contents. Later the user may save changes back into the file.

Minimal vs desired access modes

An application might be able to deal with a multitude of access modes (such as file seeking, reading and writing) but may also be able to make do with a minimal set of access modes. For example, a text editor might be capable of opening a file for reading and writing. However, in the worst case, loading a file read-only may be supported too. In this case, arg[1] might be specified as: "r rw"

Notes

In certain cases a peer relationship needs to be set up to transfer a group of files that are not physically located in a particular named directory. For this case, request a peer using a blank filename in arg[0] and the directory type (/) specified via arg[2]. The treatment of a group of files is the same as a directory of files except that the lack of a filename tells the peer that they should not be copied into a new directory but should be placed within a given location.

FIFO functionality in Hipe is under development and this instruction and documentation may be subject to change as we figure out the best approach.